User Management Design - Sessions
Moderator: General Moderators
Re: User Management Design - Sessions
well the core thing here seems like "store session in database in shared server"
Re: User Management Design - Sessions
the only 'flaw' I can see to Attilitus's method is that if user Y signs on using user X's credentials while user X is on the site, user X must now reauthenticate next page refresh.
Worst case scenario is that user Y and user X spend a frustrating hour or so logging in and logging each other out.
There are a lot of ways to defeat this, and most people have no reason for user Y to even have user X's credentials, but still.
so.. .yeah.
=D
Worst case scenario is that user Y and user X spend a frustrating hour or so logging in and logging each other out.
There are a lot of ways to defeat this, and most people have no reason for user Y to even have user X's credentials, but still.
so.. .yeah.
=D
Re: User Management Design - Sessions
That is an optional feature. You could just as easily NOT delete sessions on login. But the system I layed out is roughly the same as what sites like Facebook use.the only 'flaw' I can see to Attilitus's method is that if user Y signs on using user X's credentials while user X is on the site, user X must now reauthenticate next page refresh.
- VirtuosiMedia
- Forum Contributor
- Posts: 133
- Joined: Thu Jun 12, 2008 6:16 pm
Re: User Management Design - Sessions
Just curious, why do you prefer cookies over the session?Attilitus wrote:I don't like using sessions at all, I prefer using cookies.
Re: User Management Design - Sessions
Why reinvent the wheel?
session_set_save_handler can be used to have the sessions engine store data in your database directly.
All methods outlined still store an identifier in a cookie and will therefore be vulnerable to hijack. There are of course methods to minimize this.
Session regeneration on key events (such as auth level change or time limit) is a good move, as is storing and comparing user_agent.
Either way, I don't see much difference. A good session setup stores a single identifying value (randomly generated on session creation) and the best cookies setup I could imagine would do the same.
session_set_save_handler can be used to have the sessions engine store data in your database directly.
All methods outlined still store an identifier in a cookie and will therefore be vulnerable to hijack. There are of course methods to minimize this.
Session regeneration on key events (such as auth level change or time limit) is a good move, as is storing and comparing user_agent.
Either way, I don't see much difference. A good session setup stores a single identifying value (randomly generated on session creation) and the best cookies setup I could imagine would do the same.