I have LoadBalanced WebServers in .Net. When a user logs in into the website, we are not sure if his next request goes to the same webserver. So will storing asp.net session in SqlServer DB solve the issue of recognizing the user when request switches between servers .
As per below link, OutProc session is suitable for Load balanced servers.
https://www.c-sharpcorner.com/forums/inproc-session-state-out-proc-session-state-in-asp-net
Related
Every aspnet web application I try to run locally just doesn't keep sessions anymore.
Somehow, this happens on both VS 2013 & 2015 with different projects. I haven't touched anything, one morning I found out that after a redirect every session data is lost.
These applications are still working on production and dev environments.
A proxy server or firewall on the web server side is stripping out the
cookie. It may be that the user is correctly storing and sending the
session cookie, but that the hardware on the web server's side is
stripping out the cookie before it can be read by the ASP or ASP.NET
engine, causing the server to generate a new SessionID and a new
cookie for the user on each request.
I have an ASP.NET Application which runs an multiple Web Servers in Azure (these are all virtual machines and not Azure Websites).
If a user logs himself in (currently forms authentication) everything is fine but if he clicks on a link he might get redirected to another server in the server group where the session cookie is not set.
How could that be solved in azure so that a user is logged in on all machines or is there a way to "bind" a user to a specific server so that he won't jump between the servers?
Thanks for your help!
metabolic
You have to change the session state to be saved in an external persistence solution, like SQL Server or Redis, instead of InProc (which means in memory) which is the setting you have now. The steps to do that are described here for SQL Server. Then if someone ends up in a different server, he'll still be authenticated as the session will be loaded from the persistence solution.
Greetings,
What do I have to consider when you are coding an ASP .Net website in regards to if the application will run in a environment where there is a load balancer for the IIS?
All user sessions are running by them self with no shared data between sessions. Single connections to MSSQL. Images and files for download will be hosted on one single server.
Windows Server 2008's, C# and .Net 4.0.
The most obvious item is session state. If you are load balancing, multiple requests from the same user may move between servers. The default session provider for ASP.NET (in-proc) doesn't support this (the user would get a new session each time they moved). The easiest solutions are to move to a ASP.NET state server or SQL Server sessions.
FYI: Both of these solutions require that everything that you put into Session be [Serializable]. The in-proc provider doesn't have this requirement, so you may see some runtime errors and need to modify your code when you change providers.
You're going to need to move your session state into the session state service. Avoid keeping objects in session...if you must keep an object in session, make sure it's marked with the Serializable attribute (this is how it is stored, by serialization).
In general, avoid using Sessions. Keep in mind that ASP.Net Session != FormAuthentication. Chances are that your database will be a bottleneck long before the web server, depending on the nature of the application.
What should I do If I want to maintain session between HTTP and HTTPS.. In my site's public area some pages are HTTP and some are HTTPS but I want to keep common session for both..
Once your user's have authenticated they will continue to have the same session cookie until it expires whether they are accessing pages with HTTP or HTTPS. Make sure that you are using encryption on your session cookie to make it more difficult to crack if you are passing it over an insecure protocol. You might want to look at the wikipedia article on session hijacking for more information.
There are a number of session state modes in ASP.NET you can use (which can be configured in web.config) apart from the default "In Proc":
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
See ASP.NET Session-State Modes on MSDN. I haven't tested this for HTTPS, but hopefully StateServer or SQLServer should facilitate this.
One session is maintained per application per user. So if you have one application which has some pages served over https and some over http, you do not have to worry about a new session being created when moving from https to http and vice-versa.
How can i preserve session between domains? They all belong to the same asp.net-application.
I don't think you can do this without a custom implementation. Your session id is stored in a cookie in the browser and it is sent back to the server with each request. That's how the server knows who you are and which session object is yours. When you switch domains, the browser no longer sends this cookie (cookies are sent per domain, so the server will never see the original session cookie and therefore generate a new session cookie for the new domain).
I don't know the architecture of your app related to when the user goes from one domain to the other, but you may just be able to send a common cookie to the browser each time the user accesses each domain for the first time and use this to correlate an in-memory object on the server.
On the assumption that you have the multiple domains specified in the host header for the website that is hosting the application and the application resides in an application pool that is not using any form of web garden it will be served by a single worker process w3wp.exe. As long as your web.config has not specified the session to be stored outproc rather than inproc then session data will be available to all code residing within your application.