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

[Peter Brunone]

Since we're continuing off course...

   ASP.NET actually has a solution to the webfarm/session problem (and they've made session use a lot less clumsy in terms of memory), and there's built-in support for cookie-less sessions as well.  You can even tell the process to use SQL Server to store session info...

 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.

   Of course their window is a lot smaller, since even if they find your sessionid cookie, they have to use it before the session expires!

   Granted, I still use straight cookies for user identification, but it's nice to know we're seeing more options.

Peter

Original Message:
>From: "Chris T" <christ at saeweb.com>

>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 :)
>