2

I'm using a hosting provider that uses scalable web servers, aka I can scale from 1..n at the click of a button.

What I would like to do with my app is identify a single session of a person browsing my website, and store their state in a database.

Now because the host doesn't use a sticky session, the Session Id which is what I would've used won't work, it may change from request to request.

What alternative identifier can I use that will identify a single user session and of course is secure?

(Just for clarity, I won't have a username or any data about the user.)

shenku
  • 11,969
  • 12
  • 64
  • 118
  • 1
    `Guid.NewGuid`? Question you are asking in the post probably does not match problem you have... I suspect you are interesting in making that ID survive multiple requests (AKA "how to set my own cookie") rather than "what to use to identify a user". Also "is secure" means nothing by itself (i.e. is `5` non-secure in you case?), so some explanation may be useful. – Alexei Levenkov Feb 14 '14 at 01:49
  • secure in the sence that I don't want anyone to be able to spoof a cookie or similar to try and gain access to someones session data. – shenku Feb 14 '14 at 02:33
  • 1
    A GUID should be sufficient in this respect, but check out a [related SO question](http://stackoverflow.com/q/22880/1810429) about preventing session hijacking with HTTPS and secure cookies since security seems to be your primary concern. – J0e3gan Feb 14 '14 at 02:59
  • As @J0e3gan commented guid is as good as you can get. There is nothing you can do to prevent someone to replay anonymous cookies (or hidden fields) if one gets access to them - so HTTPS is required. If it is local solution where you can use other authentication (like Windows auth) you may add additional layer to confirm identity. – Alexei Levenkov Feb 14 '14 at 03:02

1 Answers1

1

Typically one would use a database backend for this because database-maintained session info can be accessed by any web server without reliance on web-server stickiness.

On a visitor's initial visit to the site (without a cookie-provided session ID in the request), it could set a cookie with a session ID - e.g. a GUID - and add session info to the database with the session ID.

On subsequent visits to the site (with the session ID in requests if the cookie has not been cleared), any of the n web servers can identify the session by its cookie-provided ID and lookup related session info in the backend database.

Cookies can be used more extensively of course - beyond just a session ID; but they are a poor choice for typical, broader session info (i.e. often with sensitive information).

J0e3gan
  • 8,740
  • 10
  • 53
  • 80