Thanks, I needed that!

I've done a lot of programming, some quite advanced,
and likely for longer than 99% of the HN audience.
But this is my first effort with a Web site, HTML,
CSS, etc. So, I believe I can write good code
and think through design issues well enough, but
I am missing some information about mobile devices
and browsers.

My little session state store code is working
great. It was fast, fun, and easy to write,
and it's been working flawlessly as I use it
while developing more code.

My main alternative was to use what Microsoft's
ASP.NET offered. First they offered storing
session state in the same application (whatever
that is, maybe just an address space). That
alternative would give problems once my site
is busy enough to need more than one Web server
unless I had some front end box, maybe from
Cisco, implement something like session
affinity. The second alternative was
using SQL Server. I'm trying
to keep down the use of SQL Server, especially
for something as light as a session state
store where relational database, with
ACID, etc. is gross overkill.

Thanks for the information on cookies:
I don't want to assume or ask that
a user's Web browser accept cookies.

When my site goes live, there will be
no reason for users to have a user ID
or password or log in -- later there
will be. So, when I have some users
log in, there is some question just how
to handle that in a way both secure enough
and also really easy for the users.
If the user lets their Web browser
store the user ID and password
(not in a cookie) and a user wants to
use that facility, so far fine with me --
that browser functionality is an industry
standard and, thus, not to be too
embarrassed about. Maybe I can get
some actual documentation of that
browser feature in pages for
programmers at Web sites of the
Web browsers -- Firefox, IE,
Chrome, etc.

For using a GUID as a random key,
I don't see what's wrong. I just
ask for a new GUID whenever I need
one. I use GUIDs for so many things
inside my server code that no user
can see a sequence of GUIDs from
one of my servers. So, all a user could
see would be just a few GUID values and
should have one heck of a time
guessing GUID values for other users.
But, a well regarded generator of
random strings would be easy to use
also. I'm familiar with high quality
random number generation, mostly would
want assembler code for the arithmetic,
don't want to try to write Intel
x86 assembler to be called from Microsoft's
Visual Basic .NET, would not want to
use such a random number generator for
session ID, and am not thrilled about
writing my own random string generator.
That's why for now I used GUIDs for
session IDs. But I could ask ASP.NET
to encrypt the GUIDs. Then a user could
grab the encrypted string
and maybe reuse it
but would have to decrypt to see a GUID
to guess the GUID sequence and
extrapolate to a GUID of another
connected user and then encrypt!
Seems a bit much!
Besides, they'd
also have to guess the IP address
of the other connected user and
fake the IP/TCP/HTTP or whatever
headers that report IP address.
Maybe the NSA, some guys in a
big basement in China, or some
brilliant, bored wacko in
Belarus wouldn't have anything
better to do!

For what is stored in session state,
I add to that right along as I
write the rest of my Web pages. So I have a class,
marked as

<Serializable()>

and add properties to it
as I want
something persistent
during the user's logical session.

I read somewhere that Web browsers
on smart phones don't support cookies.
Good to learn that this is not correct.

Since cookies are now a privacy concern,
I'm still reluctant to ask my users
to have cookies enabled for my site.
For persistence a session ID, I don't need
a cookie and can use just a GUID
(or a random string)
in a hidden field. For persistence
for user ID and password, my site
doesn't use those yet!

Thanks for the answers!