Re^3: Perl and Cookies

That's not a great way to do session IDs. There are a few reasonably reliable ways:

Take a hash of the username, IP address, and date/time of login. This should be unique as long as no one is cheating. ;-)
Use a *sequential* ID in your sessions table. Hash this with the info above and it *will* be unique.
Just use Data::GUID and store the Globally Unique ID (GUID) it generates as your session key. This is, actually, the simplest in my experience. It also guarantees uniquness and avoids the odd chance of hash collisions and such that the former two risk.

In either case, save only the session ID in a cookie (or, if you prefer {and are willing to do a little extra work}, you can pass it in the URL and not use cookies at all). In the sessions table, store an expiration time; each time you check for a valid session, you can update the expiration (unless, of course, the session has already expired).

This seems to be the best approach short of implementing some kind of full-featured auth scheme on the server side.

<-radiant.matrix->
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Comment on Re^3: Perl and Cookies

Replies are listed 'Best First'.
Re^4: Perl and Cookies by blogical (Pilgrim) on Mar 06, 2006 at 22:20 UTC
You'll re-compile the session id to check validity each time, right? You'd need 3 things: username, IP (granted), and login time(granted if stored for use as salt). IP and a request-incremented value are good additions- salt to taste. But if you only send the session ID, where is the username coming from?	[reply]
Re^4: Perl and Cookies by pajout (Curate) on Mar 07, 2006 at 09:27 UTC
ad 1/ Can the user establish two sessions at the same time? ad 2/ Yes, I'v simplified my table - it has sequential primary key (aka ID) and the session identifier, I named it "token". ad 3/ I prefer simple solutions, and when I am able to fully satisfy the requirement with 50 rows of code, I am not using the modules, having thousands rows, potentially with bugs. You wrote that my way is not the great, but you did not write why :>)) In any case, thanks for sharing experience...	[reply]
Re^5: Perl and Cookies by radiantmatrix (Parson) on Mar 07, 2006 at 14:57 UTC
Can the user establish two sessions at the same time? That's up to you. ;-) Nothing prevents it, though such things always take a bit of thought to do well. I prefer simple solutions, and when I am able to fully satisfy the requirement with 50 rows of code, I am not using the modules, having thousands rows, potentially with bugs. You're... not using modules? Because they might have bugs? I'm willing to bet that the mainstream modules suggested in this conversation have a better test suite than your code, and the advantage of hundreds or thousands of testers. Sorry to be blunt, but that's a really stupid reason to avoid CPAN. You wrote that my way is not the great, but you did not write why Because you were randomly generating data, then checking for collisions. The busier your site becomes under those conditions, the more likely a collision, meaning more re-checks. Your site becomes slower at a non-linear rate -- thus, bad idea. <-radiant.matrix-> A collection of thoughts and links from the minds of geeks The Code that can be seen is not the true Code I haven't found a problem yet that can't be solved by a well-placed trebuchet	[reply]
Re^6: Perl and Cookies by pajout (Curate) on Mar 07, 2006 at 16:03 UTC
No, that's up to you, when you construct sess_id from user name, time or such stuff... I'v never wrote that I don't use CPAN, and if you want, you can see my preference of short own code rather than some module stupid, I see the same as independancy. The probability of collisions when my id's are generated is, I know, but it is theoretical when more than 10 character length used. But if you check it against sessions in db when created, your action is the same as when checking the same session id given from the next request of the logged user. I cannot see relevant slowdown... I know that I am not perfect and my solutions really contains bugs, but somebody can be interested in.	[reply]