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?
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.
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.
Related
We have several web applications using the same identity provider (which we also manage), most of them (including identity provider) are using .NET core.
Requirement is that if user is logged in in two or more applications at the same time (in one browser), and is actively using one app, it automatically extends the session lifetime in all of the applications.
So while he's using at least one application, he doesn't get logged out of neither of them. Which is another requirement: auto-logout after certain time of inactivity (this part is easy of course)
I thought of using Redis server to manage this shared session lifetime, using SessionId that each app would receive from identity server via claims. So each time user does some action, backend contacts Redis and check if user's session is still active and extend the session lifetime if it is. Logout user if it's not.
Problem is, applications are not allowed to access this Redis server directly (security reasons). So I thought of adding a separate web service for these apps to contact using standard HTTP endpoint. So basically just a middleman between Redis and web app.
Is there any better way to do it? Not sure how common of a requirement is this.
Redis usually belongs in the Distributed cache, which means that it is located on another server farm. Therefore, your application has restrictions because it is not allowed to access an external server.
If your application is under development or if it is still in the growth phase my recommendation is to use InMemory cache or consider response caching middleware.
Also, these are very small amounts of data, and if you are going to store only that in the cache for a start you would definitely consider InMemory.
Of course, I understand your need for a Redis and that is it:
Is coherent (consistent) across requests to multiple servers.
Survives server restarts and app deployments. And that's because
your cache is usually in a different location (e.g. Azure)
Doesn't use local memory.
Is scalable
etc.
For larger applications Consider replacing InMemory cache with the Distributed memory cache. It is mostly similar to the InMemory cache because both the InMemory and the Distributed cache are located on the server farm where the application was run. Only the InMemory cache requires a sticky session, and the Distributed memory cache does not.
My server needs to log-in to another server (for accessing payment API). Result of successful log-in operation is a session token that is valid for 25 minutes.
Where can I store this session token so that it is available across multiple requests and multiple users? (i.e. user session is not an acceptable solution).
I need some sort of an application state or cache storage.
Just to demonstrate the problem - a file could be used to store this value, but I don't want to deal with concurrency, and security implications this solution comes with. I would prefer an in-memory solution.
You could use either the core JSession or JCache framework objects.
http://docs.joomla.org/JFactory/getSession
http://docs.joomla.org/Using_caching_to_speed_up_your_code
http://docs.joomla.org/Cache
I am hosting an on-premises website which I want to migrate to Windows Azure Virtual machine.I will be using multiple instances of Azure VMs. Currently I am using IN-Proc session management technique. Do I really need to change this session mode to migrate the website to cloud. Why??
If you want to have more than 1 Web Role Instance (for load balancing/scalability/redundancy purposes) then Yes you do need to change it. Just a reminder, but you need a minimum of 2 roles in order to be eligible for the 99.9% SLA.
InProc means that the session information is stored in that web roles process. a second web role instance, has no knowledge of that data contained in process in the first web role.
So if your first web request goes to WEBROLE_1 it has your session information.
If your second request goes to WEBROLE_2, it won't know that you already have some session data stored in the other role.
There are a number of other options for storing your session info including using TableStorage, SQL Azure or App Fabric Cache.
I've had 2 sysadmins from 2 large hosting organizations tell me that Varnish will handle session sharing between web servers. I can find nothing online to support this and in fact found this where the guy specifically says it does not. I cannot tell if the guy is a Varnish employee or just a contributor or what.
Just looking for more verification on this point.
A session allows you to store many things (shopping carts, logged in user, etc), and is commonly identified by a cookie (e.g. sessionid). A web server knows how to get a session using this sessionid (and can access/update your shopping cart), but varnish only handles cookies. Varnish can do load-balanced lookups to backends, regardless of the cookie values or based on some rules (you need to write you own varnish config).
However, a challenge in session sharing between web servers is whether a web server can access sessions created/updated by another web server. In many Java Web Containers, sessions are by default stored in memory (of only one web server), with load balancers implementing some kind of 'sticky session' mechanism (sending a user with a session to a specific back-end all the time, can be easily setup with varnish). Another option is to store the (serialized) session values in a shared database, so they can be retrieved by any backend (and will keep working if a web server goes down). A third option is to completely serialize the session into a cookie and stop using sessionids, but this is complex (limited size, bandwidth, security requires some signing mechanism, but scaling is great).
All approaches have advantages and disadvantages. You have to choose, varnish supports any option but will not 'automagically' do what you want, so prepare to write a bit of varnish configuration...
If you would describe how you want to load balance, or what you try to achieve, you could get a more specific answer.
If I'm hosting a site in windows azure with an out of proc session provider and perform a VIP swap, will the session persist through the VIP swap since the session is being provided out of process?
I will come back and answer the question after I perform a test but I'm pretty sure someone will have the answer here asap and azure deployments take a while.
I see no reason why it shouldn't work.
It should be no different than hitting different instances that are part of the same deploy.
If you use the Azure Cache for your session, it should not. The browser is using the same domain, so the same cookie would be sent, and a VIP swap does not affect the cache server.
If you are not using Azure Cache for session I recommend it, they even have a NuGet package.