[Javascript] OT: Server-side Scripting / Maintaining state

[Chris T]

Ideally, we store information in encrypted cookies. And when I talk about
"we", I'm not talking about at EmailAJoke. That's my personal site. I'm
talking about the company I work for.

If some piddly state information is just needed to enhance the user
experience while on the site, then I will just store that in a cookie that
can be read by anybody.

Of course this means to users who have disabled cookies, they will either
not be able to use our site or they will have to enable cookies for our site
particularly. That might not work for everyone. Some organizations are much
more strict in how they cater (or pander) to users.

I personally don't like using the querystring for passing information along,
unless it's a search and the user wants to link to those search results. If
I need to receive information, I use post all the time.

If someone's going to a page where they edit info about their profile or
something specific to them, I validate who they are through cookies and
handle the page accordingly. So you won't see me using something like:
/editProfile.asp?profile_id=14208

As for sessions - sessions are not easily maintained in server clusters. You
will run into problems where users may go from one server to another
depending on a particular server's load. If you ever develop a large
application that will span multiple servers, you will need to keep that in
mind. So why fall into the bad habit of sessions if they can be avoided?

------------------
Why
would I trust information collected by the web server and intended to be
used only by the web
server to make a round trip to the client with every page?

   The only other way I can conceive of state maintenance that doesn't
expose the data to the
client, and doesn't use Session requires the use of a database engine -
which is probably more
expensive overhead than the session object.
------------------

1) Even when using Sessions, you need cookie access so it can find out your
particular session ID. Try it out with disabled cookies. You should register
as a new session each time. Seeing as a session won't expire right away, you
could run into memory problems on a high traffic site.

2) I always use a DB - SQL Server. Very little information about the user is
stored in my cookies. I find out the user's properties server-side for the
most part.  I just have to trust that the user hasn't been able to decrypt
my cookies and spoof themselves as another user. But then again, if
someone's that clever, they're probably going to find a way to hijack your
sessions too.

Chris Tifer
http://emailajoke.com <-- This is my personal page and it's over 2 years
old. If you see some of the things I say I DON'T do, then that's because I
haven't gotten around to updating them.  Look. I still got ads up for
Valentine's day :)