Forum Moderators: open
If you feel you need to also do the password for them, then one IMPORTANT point is that the actual password is NOT in the password field (or at least it shouldn't be!). Just set the value to "AAAAAAAAAA" and it will display "**********" The cookie should be a unique value specific to that user and that machine. On the server then, you should check for a match between the cookie and the userid.
James.
>john_k
You've answered a question that was puzzling me, in that I can retrieve an ID (am using Coldfusion) and was wondering what to show in the actual field, because filling it with the password shows as asterisks in the browser field, but shows the actual password in 'View Source'!
So I guess I can retrieve the ID, fill the field with asterisks so the user knows its been retrieved and then not actually pass anything in the form that would be visible...just using checks at the server end before proceeding.
Actually, the HTML input type of password automatically substitutes asterisks for the characters typed into its input box.
Yes, but you can see what the real password is when you view source and the point was to prevent the passwords from being cached, which they would be if you fill in the actual password in the form.
Its best to throw garbage in the password field and then use the cookie when the password is requested.
Not if the field is filled dynamically through a script with a value retrieved from the cookie. Cookies, however, are not secure, unless their value is encrypted.
That depends on how the cookie is being retrieved. If the cookie is read by ASP, PHP, Perl, or another server-based scripting lanaguage you WILL be able to see the password by viewing the source. The password will appear in the "value=" portion of the password input box.
Only through Javascript will you be unable to see the password in the page source.