Page 2 of 2

Re: User Management Design - Sessions

Posted: Mon Jun 09, 2008 7:49 am
by rami
well the core thing here seems like "store session in database in shared server"

Re: User Management Design - Sessions

Posted: Fri Jun 13, 2008 2:05 pm
by w35z0r
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

Re: User Management Design - Sessions

Posted: Fri Jun 13, 2008 5:17 pm
by Attilitus
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.
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.

Re: User Management Design - Sessions

Posted: Mon Jun 16, 2008 12:19 am
by VirtuosiMedia
Attilitus wrote:I don't like using sessions at all, I prefer using cookies.
Just curious, why do you prefer cookies over the session?

Re: User Management Design - Sessions

Posted: Tue Jun 24, 2008 1:48 am
by Stryks
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.