Hi i have been looking at my own remember me that i did awhile back and wanting to improve on it because it quite honestly does not work as well as i want it to.
I know the way i did it was to just increase the time on the expire of the session so that it does not log them out. My question is i have seen it done in different ways. So i thought i would ask, how it is suppose to be done.
I say mine does not work as well as i want, what i mean is that there are times that im chatting and not moving from page to page and all of a sudden im logged out so i know i could do a better job.
So what is the industry standard i guess is what im asking?
So what is the industry standard i guess is what im asking?
There isn't one
Yahoo are terrible despite all of their years of experience. Every 24 hours, they'll ask you to confirm your password. Now, you can be in the middle of typing an email, hit send, get to the password confirmation page, enter your password and be redirected to a lovely new (and blank) compose email page. Your email text has vanished, you can't go back because yahoo's nasty JS automatically puts you back on the password page and you find that your lovely big email you spent 40 minutes writing has gone! I've emailed them loads of times over the years and asked them to fix it, sent them screenshots, told them how to fix it etc, they're not interested. This is yahoo.. one of the webs earliest web presences who keep grumbling about loosing users
Other sites (like mine) will ask you to confirm your password and save everything from $_GET and $_POST into the session (which uses the DB not files to avoid garbage clearance). When the user enters their password, the $_GET and $_POST data is automatically pulled back out and acted upon. If you'll forgive me for being lazy and not accounting for the $_FILES array, it's a flawless system IMO. The only way I found that was easy to implement this however was to have everything go through one main script - index.php. In that script I have the login / session checking code at the top and then if its valid it just continues to do whatever. If the session is old then the users prompted to login again and the script exits after printing the form. Once the password is confirmed the script continues and pulls out the two arrays from the session which were stored when the login form was printed. It then proceeds down past the login code and runs the rest of the php with the two arrays in place as normal - the rest of the code just see's the original data and runs whatever code / module needed with the originally submitted data / forms.
Thats not quite the same as what you're talking about but it borders on it. You want the 'remember me' thing whilst I have a 'password confirmation' every hour (I hate using cookies hence I don't use the 'remember me' thing and instead just act on valid sessions). The only real difference is the way the sessions survive the browser being closed - i just set the session up for a year so it should be valid for a while in my browser
Thanks tango, appreciate that bud. And i hear you bud, thats why if i have a long email or post thread i always copy it and paste it to notepad or prog notepad before even thinking of pressing send.. I have had to retype way too many excellent emails and try to remember my thoughts again and at my age thats not an easy task.
Now for some sarcasm (not related to your post bud, but just in general) cause im feeling naughty today lol
What no standards!, did the industry not learn from the html days before W3C? I fully understand that php as well as other lanuages are fairly open to interpretation and fairly free in style as far as execution process (more that one way to skin a cat) but maybe we should have some kind of standards or at least a play book.
Or is that what php.net was originally designed for?
There is no standard really because its down to each website owner / webmaster how they want their system to work. If there was a standard login system and remember me system then you'd be able to download it off google and everyone would be using the same thing. The truth is there are so many ways to handle login forms, remember me options and password reminders that many webmasters either go to something like hotscripts or write their own. Which ever route you choose you're still at peril if you don't make it cover all aspects.
I designed mine to save all the submitted data (post and get) and process it after a successful login. For me, it works very well other than I don't save the $_FILES array (I got lazy and couldn't be bothered). Other webmasters don't think the submitted data is worth saving and don't bother (as I explained with yahoo). Ultimately they are the ones who will wind up their users and loose them - as yahoo have.
PHP.net is an API. This isn't an issue with the PHP language; PHP is quite capable of establishing indefinite connections with clients if so desired. This is a limitation of HTTP as its a stateless protocol.
There is no standard for relogging in as there was no standard for logging in the first place. Since the idea wasn't to provide anything but static pages, there was no reason to incorporate a concept of a non-stateless protocol. As languages were integrated into into creating dynamic data (like perl), browsers were also implementing ways of remembering configurations with cookies.
Now the net has evolved and many sites use dynamic content and require login authentication. Users don't like constantly filling in forms to login, so methods have been made for a "remember me" idea. Since HTTP doesn't support the ability to retain login credentials, and we languages are not responsible for indefinitely logging in users (built on the http model), there is therefore no standard to be made for a remember me concept.
There are many ways to perform this task.
I follow a model similar to tango's. I don't allow indefinite sessions though, as I use memory tables for my sessions. So I use a secondary.
No matter what the case you use, remember me is far more open for attack than sessions. Sessions you can run quite a number of verifications and regenerations on, so you can say that the request is reasonable with the credentials applied. Cookies on the other hand are far more difficult as many of these may change between reads of the cookie. No matter what you do, you cannot reasonably say that a user providing a cookie is the same user that generated it.
For example if I enable remember me from both home and work, now I have two distinct cookies in two distinct locations. How do I stop one from forcing a login all the time? Storing user information like the browser or ip is useless since these would differ between the two locations. This is (sadly) why one of the most common solutions is to provide a userid and a hashed password as cookie values, since now it doesn't matter where the login from. If cookies are compromised, then that exact data can be used to compromise the site authentication.
So how do you get around that? That's the real key. The easiest solution for that is to control what can be done by requiring a password. And you need to find the right balance. At minimum, I'd suggest that both changing of a password and email address should be blocked by a password, so if you want to change either you need to provide a password. Even if a compromised cookie uses as hashed password, that is useless as it cannot be used in verifying of a password.
So as a developer, remember me is the worst thing to implement in a site. As a user, it is convenient. Since the desire of the user overrides my desire as the developer, you simply need to make compromise as to what needs to be done to fulfill that. So long as the site isn't requiring high levels of security (ie: banking, payments, anything with money, government, buying, etc), then a compromised authentication is not the end of the world. So the rule of thumb I'd suggest is simply: if you need to implement remember me, do so on http, but never do so on anything requiring tls.