-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 03 June 2003 18:59, Michael L. Artz wrote:
> I am trying to design/implement a fairly simple authentication scheme
> using cookies and such, but wanted to air my design questions before I
> run into too many issues.
>

It sounds like you are mixing HTTP-level authentication with application-level 
authentication.

While HTTP authentication is pretty cool, unfortunately it is user-unfriendly. 
You won't find hardly any big sites that use it for this reason.

Instead, they use application-level authentication. This is like Slashdot's 
login box, where everything is handled with cookies and HTML forms.

The idea here is that there is a hash attached to each user who browses the 
website. You store variables and information in that hash. When they come 
back, you restore the hash they used last time.

There are several ways to do this. The best practice is to give the user a 
cookie that is a number -- usually an MD5 of something like time, PID of the 
server process, and other random bits of data. The idea is you want a unique, 
unguessable session id.

Then, on your end, you create a table in a database or something like a 
database. You stoe the session id linked to the session data. But how to 
store a hash in a database? You serialize it with Data::Dumper.

The algorithm on each page is pretty simple. If the user is browsing a page 
where you might want to use session data, just check for the session id 
cookie value. If it is not there, you have a choice: do you set a cookie for 
all users when they fail to show a session id cookie, or do you set it only 
under special circumstances (like when logging in)? Either way, you'll want 
to check to see if the cookie was properly set, and at least warn the user 
that cookies need to be enabled. The way I like to do this is to set the 
cookie, then redirect them to a cookie check page. The cookie check page will 
see if the cookie was set. If not, it prints out a warning and explains your 
privacy policy. The idea is to convince the user to change his browser 
setting to accept your cookies. If the cookie was successfully set, you 
redirect back to where you came from.

Once you get the session id, you grab the session data, unserialize it, and 
begin using it. When you are done, remember to serialize the data, and store 
it in the database.

With a little thought, you can probably tweak the system so that it does 
exactly what you need. Don't be afraid of exploring MySQL or PostgreSQL for 
storing the session data. If you are only going to store session IDs, I would 
suggest you explore MySQL. If you may get serious about the database, and one 
day, design a huge database, you are better off starting off with PostgreSQL.

Enjoy!

- -- 
Jonathan Gardner <[EMAIL PROTECTED]>
(was [EMAIL PROTECTED])
Live Free, Use Linux!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+5eKLWgwF3QvpWNwRAoWdAKCc1HFa+jxbuiO5+lySY7ViKK7cBQCaA2m5
f7F/121dBpe7ULqyBszvxCI=
=T9Cv
-----END PGP SIGNATURE-----

Reply via email to