Forum Moderators: coopster
So far, for my site, there's an option for users to be 'remembered' when they login, so they don't have to login again on a second visit to the page, etc. You've seen those before, they're on all the big websites..
The first version included storing the user's name and id in a cookie, which was checked for at the top of every page. If the cookie was found, its data was exploded and put into $_SESSION. This was a really, really bad way to do it (since a user could just edit the cookie on their browser, imagine what'd happen if I'd stored 'access level' with the data), but I was young and stupid at the time.
Next version used the same data, though it was encrypted. In fact, the cookie stored six encrypted strings (encrypted by a self-made algorithm). Three of these were just random stuff, the other two the encrypted name and id. The first string was actually where the name and id were held (in which of the other five strings). This was fairly decent, if a bit clunky.
The proposed version I'm about to try out stores a just a random number in a cookie, which is the id of a row in a database which has a serialised form of the session data (name, id).
Am I doing this the hard way? What d'you guys think? Is there a better way to use 'remember me' cookies?
But... I fear you might be working too hard creating custom encryption scripts! The built-in PHP encryption methods and MD5() work very well in a lot of situations. But I will admit I have encountered situations where I needed a home-grown obfuscator.
To store cookies for login, I send one cookie: it's an obfuscated version of the serialized UID+PWD.
(i.e. the data is not truly encrypted, but it uses a 2-way algorithm to make it unreadable. It uses a secret "key" to mod-translate the ascii values of each character in the string. I believe it was invented/published by Lewis Caroll in the late 19th century, though it has earlier mathematical roots)
good luck!