There are some ways which I am considering of.
1. using the user PK, the cookie value: {id}:{md5(id+salt)}
2. using the user email, the cookie value: {email}:{md5(email+salt)}
3. way 1 or 2 plus the password, like {id}:{md5(id+pass+salt)}, but this way will make a db select every time (select the password).
Is there any other good way of cookie based auth?
What you really want is:
id:[some_int],
session_token:[some_hash]
The session token is created only on the server, and is just a lookup key... importantly, paired with the user_id. It gets stored in a database, with an expiration date. Once that expiration is hit, you require a new login. You can set the timeout at any time... change the way you generate the keys, etc. You can also hav different classifications of auth tokens with different timeouts, etc.
On page load, you use the id and session token as queries into your session table, typically with a date rage selection (depending on your login business rules). If everything matches up, you're good. For extra obfuscation, you could use part of the user-agent.
How you generate the token doesn't matter in this case... an MD5(mktime()) is just as good as anything else.
The only time you need to worry about prebuilt formats is for auth_tokens, which could be used to bridge API gaps between applications & your Web service (doesn't sound like you need to worry about this).
Example login detection flow:
<?php
session_start();
if (array_key_exists('auth_user', $_SESSION))
{
// user already has a session.
}
elseif (array_key_exists('session_token', $_COOKIE))
{
$sql = 'SELECT *
FROM sessions
LEFT JOIN users USING (user_id)
WHERE sessions.user_id = %d
AND sessions.token = \'%s\'
AND [ some date argument ]
LIMIT 1';
// execute SQL. If you get a user back, great. Set up a session.
if (!empty($user))
{
$_SESSION['auth_user'] = $user;
}
}
else
{
// Not logged in. Do what you want here (like show a login UI).
}
Your Auth code should create the token, drop it into the DB, and set the cookie.
