2

We have Windows Server 2008 R2 with IIS on in a web farm environment. I initiate a Classic ASP session and every so often, when refreshing the page, it doesn't show but then comes back again.

I go to http://mainurl.com but have two boxes called http://devbox1.com and http://devbox2.com

I put the files onto one of the DEV boxes which replicates to the other one.

After some reading, I guess this is down to a "common" issue with sharing sessions across a web farm instance.

Could someone please help me how to resolve this please?

user692942
  • 16,398
  • 7
  • 76
  • 175
pee2pee
  • 3,619
  • 7
  • 52
  • 133
  • Store your session into a database and use that to build your session. – user692942 Apr 23 '14 at 14:46
  • What if I create a session on devbox1.com and populate the DB with that and I then hop onto devbox2.com? – pee2pee Apr 24 '14 at 09:10
  • 1
    I would store a cookie with the session id from database when session is first created then check for that and return the session from the database accordingly. Which box the client then connects to does not matter. – user692942 Apr 24 '14 at 09:43
  • Ok thanks - I've done it a slightly different way which seems to work but thanks for the push to a DB solution – pee2pee Apr 24 '14 at 11:35
  • No problem, but could I encourage you to post the solution as an answer so that others can be helped in future. If you are concerned about answering your own question, don't be as SO encourage it. See [Can I answer my own question?](http://stackoverflow.com/help/self-answer). – user692942 Apr 24 '14 at 12:11
  • @pee2pee DB solution could also compromise security of you system in that case. You will have to do lot of work around to prevent someone from outside getting access to your web farm by impersonating your active user session. And this is on top of simple things like security on IIS may not even recognize your saved session from DB when you got switched to other node. I would go with sticky sessions in your case. – All Blond Apr 28 '14 at 13:55
  • 1
    Thanks @Lankymart - will do. From what I've read, this is actually the more secure setup. They would literally need to be using the computer in question at the same time to hack in. – pee2pee Apr 28 '14 at 14:47
  • @pee2pee Exactly but it's not impenetrable and using SSL as an added layer of protection is advisable if your data is sensitive. – user692942 Apr 28 '14 at 14:49
  • @Lankymart This isn't working 100% as expected. Using `<%=Session.SessionID%>` means it changes depending on what node the farm connects to – pee2pee May 12 '14 at 09:36
  • @pee2pee I already told you not to use `SessionID` as this will change (explained it [here](http://stackoverflow.com/questions/23243284/share-sessions-in-iis-web-farm?noredirect=1#comment35751357_23324357)). The `id` you store when creating the cookie should be unrelated to the `SessionID` and it is this id you should use to retrieve the session data and recreate the `Session` object. – user692942 May 12 '14 at 09:41
  • @pee2pee I've updated my answer to make this point clearer. – user692942 May 12 '14 at 09:50

2 Answers2

2

Update:

As it's not clear in my post. Do not use the Session.SessionID as the identifier for the cookie as this will change across environments (Microsoft recommend never to store the SessionID in a database).

Quote from MSDN Library - Session.SessionID

You should not use the SessionID property to generate primary key values for a database application. This is because if the Web server is restarted, some SessionID values may be the same as those generated before the server was stopped. Instead, you should use an auto-increment column data type, such as IDENTITY with Microsoft® SQL Server™ or COUNTER with Microsoft Access.

Instead use a self generated id value that you then store in your cookie and the database. This way your Session object can be re-created.

There seems to be some discussion about solution using a database. Just to clarify Classic ASP uses Session object stored in memory this means the minute you switch machines load balanced or otherwise you still lose the session.

Interesting article on the IIS.net forums about this topic - iis 7 Load balancing

Quote from Bill Staples (who at the time was Product Unit Manager, IIS)

One thing to consider, however, is what to do with any application / session state. Classic ASP stores session state in memory that only one process can access. As soon as you scale the sites onto more than one machine, you can no longer guarantee that each incoming request for a particular user session is landing on the same machine, which means the client may suddenly 'lose state' between requests. This is why we recommend that you not use the built-in session support in ASP for these kinds of scenario. Instead we recommend you use SQL or another database to store this kind of data.

My recommendation would be to store the Session in a database create a cookie on the client machine then use this cookie to identify the session from the database.

Cookies can be changed so I would still recommend you use secure cookies across an SSL secured website, especially if data is of a sensitive nature.

Community
  • 1
  • 1
user692942
  • 16,398
  • 7
  • 76
  • 175
  • 1
    I hope to one server, then the other and then back onto the main server. The sessions are then collected on the way and populated into the DB – pee2pee May 01 '14 at 10:32
  • Thanks - maybe it's the combination of a Monday and overthinking everything but I'm still stuck. Let's say I come to a server and log into my system - this happens on WEB1. The page then chucks me into the admins session but this throws me on WEB2. If I create a GUID on WEB1 and store that in a cookie and DB then what's stopping someone stealing that cookie and impersonating that user? The site is all SSL based. – pee2pee May 12 '14 at 09:59
  • 1
    @pee2pee Your right in what you say and to be honest the only thing stopping someone hijacking the cookie is SSL. I would also suggest using the [`secure` flag](http://stackoverflow.com/a/13730187/692942) to stop your cookie being hijacked over HTTP. – user692942 May 12 '14 at 10:03
  • So something along the lines of `Response.Cookies("lastname").Secure = True` – pee2pee May 12 '14 at 10:05
  • 1
    @pee2pee Exactly, there is a good article on the subject here - [Cookie Monster: Using Cookies in ASP](http://www.4guysfromrolla.com/webtech/051099-1.shtml). – user692942 May 12 '14 at 10:10
  • Cheers - seems that ultimately this will be the way to go. – pee2pee May 12 '14 at 10:20
  • Seems setting the client affinity on the web farm means the user will stick to one server so in fact, this particular problem for me has been eradicated! – pee2pee May 21 '14 at 10:12
  • @pee2pee Kind of negates the point of a web-farm though surely? – user692942 May 21 '14 at 10:41
  • It still splits traffic as needed for new arrivals - it's not perfect and we'll revisit it when we're getting loads of traffic – pee2pee May 22 '14 at 13:16
-2

You should create sticky sessions while working with web farms because most likely you have load balanced system which under standard configuration will point traffic to the lowest loaded node. As result your users will loose session from time to time.

Ask your network admin team to look how to create sticky session for your particular load balancers and network configuration, they should know exactly what this means.Here is one of the examples what this is and how to configure it: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_StickySessions.html. But once again it is depend on what you are using.

**** solution with cookies or database entries not the best way to handle this situation because once again depend on your web farm configuration IIS may simple reject any attempt to overwrite session ID which you have stored in database or if security is tight enough even refuse to connect to page while connecting to other node.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
AlekseyF
  • 19
  • 7
  • Not at all @AlekseyF. If there is a better solution I'm all for it, I'm only sensitive when people do there best to downvote me out of spite or just want to act childish (you a friend of [All Blond](http://stackoverflow.com/users/529463/all-blond) by any chance?). Is sticky sessions supported in an IIS environment? – user692942 Apr 28 '14 at 14:54
  • As long as you don't try a force `Session.SessionID` anywhere in your code I'm not sure how this would happen. The id you store in the database should be completely unrelated then when checking the cookie and re-instantiating the session you would just create a new session based on the database values. – user692942 Apr 28 '14 at 15:49