Page 1 of 1

How do you deal with user authentication?

Posted: Fri Sep 24, 2004 3:37 am
by myleow
How do you handle user authentication on every page?

Do you save the username and password into session and on top of every page validate it against the username and password in the DB?

If you leave it in the session, its a potential security risk.

How do you do it?

Regards
Mian

Re: How do you deal with user authentication?

Posted: Fri Sep 24, 2004 4:13 am
by patrikG
myleow wrote:If you leave it in the session, its a potential security risk.
It isn't. The safety of session depends entirely on the server environment and setup. Generally, you can work under the assumption that session are safe. Most crucially, you will have to consider the best settings for session timeouts for your application.

Naturally, you won't want to leave a password in a session-variable. Why would you? All an application needs to know is whether the use is logged in or not. Create a unique user-id and have that in the session, otherwise you'll have to log the user in on every single page.

Have a look at the session tutorials at Zend.com, read up on session_set_save_handler in the php manual.

Posted: Fri Sep 24, 2004 2:55 pm
by Christopher
If you are concerned about someone accessing the session files, you don't need to save their password in the session to check if they are logged in (you don't need it anyway). Your access control can be as simple as:

Code: Select all

if ($_SESSION['userid']) {
// allow access
} else {
// access denied
}
When the user is authenticated you set $_SESSION['userid'], when they log-out your unset($_SESSION['userid'])

Posted: Fri Sep 24, 2004 3:59 pm
by feyd
if you follow arborint's advice and use [php_man]unset[/php_man], use [php_man]isset[/php_man] instead of running the 'if' straight.

Posted: Fri Sep 24, 2004 4:02 pm
by m3mn0n
arborint wrote:When the user is authenticated you set $_SESSION['userid'], when they log-out your unset($_SESSION['userid'])
Yep. That's pretty much the standard way I do it also.

Some applications do store the username, and some other mumbo jumbo in a SESSION/COOKIE var, but in a low security (non-SSL) application, it's not needed, and some would consider it bad design.

Posted: Fri Sep 24, 2004 8:59 pm
by jason
This is assuming the user is already logged in successfully:

Check integrity of the information via hashing method. This includes user-agent checking.

Check status of user in DB. If the user's status get's set from active to banned, or something else while logged in, I want to know about it.

Check to see if the user has any pending actions to perform. We can set actions at any time, and these actions are a queue (FIFO). Sample actions are: re-enter password, agree to terms and conditions, fill in needed information.

We use sessions, and are behind SSL all the way. =)