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

1. Take a hash of the username, IP address, and date/time of login. This should be unique as long as no one is cheating. ;-)
2. Use a *sequential* ID in your sessions table. Hash this with the info above and it *will* be unique.
3. 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.

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?

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...

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