Just a few points.

It's no longer necessary to seed the RNG with srand, that has been automatic for the last few versions of Perl.

The @Chars array can be initialized with the list range operator:

my @Chars = '0'..'9', 'A'..'Z', 'a'..'z';
[download]

I'd rename $l so it doesn't look like the first captured match builtin, $1. It could also be generated by

$l = join '', map {$Chars[rand @Chars]} 1..7*($ARGV[0] ||= 1);
[download]

After Compline,
Zaxo

my @Chars = '0'..'9', 'A'..'Z', 'a'..'z';

That won't work as you might expect. You'll actually need:

my @Chars = ('0'..'9', 'A'..'Z', 'a'..'z');
[download]

Those parens aren't optional. Here's a demonstration:

$ perl -le 'my @one="0".."9","a".."z"; my @two=("0".."9","a".."z"); pr
+int @one; print @two'
0123456789
0123456789abcdefghijklmnopqrstuvwxyz
[download]

-sauoq
"My two cents aren't worth a dime.";

Right you are. I'm trying to understand that in terms of operator precedence. I think my erroneous one parses as: ( my @Chars = '0' .. '9'), 'A' .. 'Z', 'a' .. 'z'; sauoq++ for the catch.

After Compline,
Zaxo

Thanks for pointing that out sauoq!
I would certainly never figured out the problem from the symptom!
jg
_____________________________________________________
"The man who grasps principles can successfully select his own methods.
The man who tries methods, ignoring principles, is sure to have trouble.
~ Ralph Waldo Emerson

Hi Zaxo!

A small glitch in this. The equivalent @Chars range would be:

                                  v
my @Chars = ('a'..'z', 'A'..'Z', '2'..'9');
                                  ^
[download]

Also, I think the $1 (one) you read, is actually a $l (ell)... ;)

So long,
Flexx

Update: Added parens, ++sauoq

Makeshifts last the longest.

If part of your session ID was the time() when the session started, perhaps encrypted and/or shuffled in a predetermined order, there's only so many sessions that could get started in that second. So if you now make sure the remainder of what your session ID string consists of, is unique for that starting second, then the session ID will be unique, period. And if that remainder is quite random and long enough to be very hard to guess, then hijacking a session seems very unlikely to me — but not impossible. I would think that recognizing attempts to break into a session, with repeated tries with various candidate session ID's, and taking appropriate action (whatever that may mean), would be the logical next step.

Of course you'll need md5.