Conversion error for b64encode

I assume you're referring to the rule from your previous post (Click here)?

 

 

If so, can you try logging the encrypted value you insert in the response and the encrypted value you parse from the request to make sure they match? Also, what version are you running? There is an issue with decoding encrypted strings

 

 

The issue was discussed here:

 

(Click here)

 

 

 

spark:

 

 

In fact, this is not resolved in 9.4.1. CR79907 is resolved in 9.4.2, as well as v9.3.1 and v9.3.0 HF3.

 

 

 

 

Aaron

We are running 9.4.2.

 

 

I think I see the problem, if anyone has any ideas how to get around it....

 

 

The encrypted values have special characters, while the extracted values have them replaced with HEX values. (i.e "/" becomes "2F")

 

 

Is there any way around this?

Can you post a longer sample of the before and after?

 

 

Thanks,

 

Aaron

Original Encrypted Value: rDTgkrSbSZ7002v4NOCStJtJnvTTc5TfCvAYBaXl6E587VHDQT2ynFakvgg==

 

Extracted Value: r2BDTgkrSbSZ7002v4NOCStJtJnvTTc5TfCvAYBaXl6E2B5872BVHDQT2ynFakvgg3D3D

I'm still missing the answer. Can you add log statements to log your key, and the user/pass pre- and post-encryption and then post the log output and your rule?

 

 

I'm guessing this might have something to do with the form that you get the user/pass from the HTTP payload in, but I'm not too sure. Anyone else have ideas?

 

 

Thanks,

 

Aaron

I believe you are correct. It looks like the form is messing it up. I will talk with our app guys.

 

 

Thanks for the help!

The issue appears to be the special characters inroduced by the encryption. Is there any way to encrypt without the introduction of special characters? Thanks

I have eliminated some of the issues with special characters and hex, but it is still giving the decoding error.

 

 

If I take a string, encrypt it, then decrypt it, it works fine. But my iRule encrypts the string then puts it back in the payload. In another event, those new values are extracted from the payload and decrpyted and this is where it fails. I have confirmed that the original encrypted/encoded string is identical to the extracted string. I have also confirmed that the key is the same in both situations. There is not much else that could be wrong here.

 

 

My thought is that there is a different data type than string needed to decrpyt it. Is that a possibility? Is there someway to typecast the string into a more "decryptable" type?

 

 

One other thing to mention is that it looks like it is an issue with the decoding specifically, not necessarily the decryption(Although maybe that is just because it never got past the decoding.)

Hi ormeb,

 

 

I think you're on the right track. When I wrote 'form' earlier I meant datatype--not the actual HTML form in the response.

 

 

Anyone have ideas on this?

 

 

Thanks,

 

Aaron

The solution is to use the following before the decryption process:

set decoded_data [URI::decode $encrypted_data]

This clears up the manipulation done by the browser, thanks to Support for helping with that solution.