Nice to meet you.
Nice to meet you.
greg stark wrote:Are you saying you cannot use google? What is wrong with the solution in the very first result that google returns?
lekurwale amol wrote:Pat, I repeat. I have to do what is said. Client is client.
Pat Farrell wrote:
lekurwale amol wrote:Pat, I repeat. I have to do what is said. Client is client.
Sorry, I missed that part of your post. Sorry that your client is an idiot. Sorry that they didn't listen to you, they are not adding any security to the system with their requirements. Sometimes its better to find better clients.
I wish you good luck. I expect that even if you get the code to work perfectly in your testing, there may be problems with the implementation in other browsers or other versions of the browsers.
lekurwale amol wrote:So, waiting for a solution.
Retired horse trader.
Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
lekurwale amol wrote:Can you provide me those java lines.
Unfortunately, I do not have time right now to read through the book you have mentioned.
lekurwale amol wrote:James,
Thanks for your solution. Can you provide me those java lines. Unfortunately, I do not have time right now to read through the book you have mentioned. Also, a few points to clarify : 1. I had tried using the PKCS7 encoding you have mentioned, and I had configured the java class accordingly. 2. The hex conversion seems to bring in extended ASCII validation, of whose conversion back code I could not write.
About the usage : I understand that it is useless in some sense. But again, our requirement is simple : Do not have plain text password in memory after form submit.
Regards,
Amol
Retired horse trader.
Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.