I have a website in C#/ASP.NET that is currently in development. When we are in production, I would like to do releases frequently over the course of the day, as we fix bugs and add features (like this: http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/).
If you upload a new version of the site or even change a single file, it kicks out the users that are currently logged in and makes them start over any forms and such. Is there a secret to being able to do deployments without interfering with users for .NET sites?
If you make a change to a config file, the contents of a bin folder of the app, or things like that, the ASP.NET worker process restarts along with your application.
This results in deleted sessions and kicked-out users.
The solution is to use other session storage methods other than the default InProc.
You can achieve this by setting the session state mode. The SqlServer and StateServer options provide very good remedy for your issue.
SqlServer mode is relatively easy to set up and get up and running. (Basically, it's just creating a database, running aspnet_regsql, and then specifying it to the config.) If you don't have MS SQL Server or don't want to use it, you can use StateServer, or create your own provider and use the Custom mode.
The only restriction is that you can only store serializable values with SqlServer and StateServer mode.
The reason you're seeing this is because you are resetting the application pool, thus resetting everyone's session.
The cleanest route would be to offload your session to a session state server, or minimize your use of session.
One way around this is if you can't offload your session is to always deploy to a new virtual directory. Your public facing URL then just redirects to your latest version. All users that are already logged in would continue to use the older version, but any new users would use the new version.
There are two alternatives to achieve that:
Do not use Session at all. (You may use cookies for authentication)
Use another Session-state mode. State server or SQLServer. http://msdn.microsoft.com/en-us/library/ms178586(v=VS.80).aspx
Either way you will also gain the flexibility to be able to run your application on multiple servers for performance or fail safe clustering.
Depending on what you store in the Session object, you may be able to reconstruct it in Global.asax's Session_Start handler. I used to do this in an internal application where we only really stored the user's identity in the Session, so we could just use their authorization cookie to recreate the session.
One thing to keep in mind if you do this: say a user loads up a form and then leaves for lunch, and you update that page while they are away. If they return to their desk and submit the form they'll be submitting the old version of the form to the new code-behind.
I suppose users are kicked because web-server application process is restarted. By default user sessions are stored in memory and session data is killed. Session provider is configurable option in web.config. May be choosing external (out-of-web-application-process) session provider is a step toward what you are expecting.
Related
I have an application that uses APS.NET as the middle tier. One of the features for administrators is to allow them to popup another browser window logged in as a non-admin user, so they can provide support.
I use a javascript function "openWindowWithPost." The application takes credentials from a DB and forces a login so the support staff does not need to know the user credentials. Unfortunately when it does that the original session is reused and hence all of their application variables are shared, causing havoc with the original Admin login.
What I would like the ability to do is to force a second browser window to popup and when it talks to IIS have it create a new session and keep the original one active. Is this possible? If so where can I find how to do this?
From your post, it looks like you are using the Session object in ASP.Net to store data.
By default the Session ID is stored by the browser in a cookie. See MSDN
for a description of how it works. You could setup your application to use query strings to store the session id, but that is really old fashion and can become messy and hard to deal with.
Your best bet is to find a solution at the browser level. For example, Firefox has an extension called Multifox that would do what you want. Other browsers have similar extensions.
I was using Session heavily for storing data of posted requests from client side on server. On research, various answers over stackoverflow pointing me , Not to use Session in ASP.NET MVC. Main reason is : Application Pool recycles frequently during life time of production server and this causes Session to recycle as well.
Thatswhy I am thinking to replace session objects with de-serialize able string "....".
My whole concern is : This singleton object containing this string (de-serialize able into Objects ) must not corrupt/recycle or re-initialize on app pool re-cycle.
So my final question would be : What happens on app pool-recycle? Only Session re-cycles ? Or the whole memory re-cycles and re-initializes?
My target web server : Microsoft ASP.NET with MVC
When the application recycles, the windows process the site is running in w3wp.exe ends and a new one is created. It's also possible a site has multiple worker processes for one application pool. In that case they all end and 1 spins up, and new worker processes will be created as they are needed.
When this happens, anything the website code was storing in memory is lost. This includes In Process Session information.
However .Net Session State can work in two modes, in process, or database. You can run the aspnet_regsql tool to create a database in sql server for storing session information. Then you can change the web.config to have session run in the database. You can use the same session apis, they work the same in both modes. But putting it in database mode causes it to persist everything to the database instead of in process memory. Then when AppPool recycles, you lose nothing.
RegSql Doc: https://msdn.microsoft.com/library/ms229862(v=vs.100).aspx
A well designed ASP.Net Site (be it MVC, Web Forms, WebApi(1/2)) etc. should be designed to be able to fully recover from any recycles. A site recycle should not break your web site.
Recycling the Application Pool will blow away your AppDomain and everything in it, including all static values.
This is why it loses session state in the first place.
You probably want a database.
SLaks pretty much answered your question. Here is the solution -
In ASP.Net MVC, we do not use Session State like Web Form.
However, you can still use Session State, but you want to use external Session State provider instead of default InProc mode - values and variables are stored in memory on the local Web server.
You have few options -
StateServer
SQLServer
Custom mode using Redis Cache like Azure.
Here is my scenario.
I publish my webforms or mvc application on iis 8 on windows server 2012.
Then my customer requests something else and I have to update codebehind.
For example a new input on form or a new column on db. And I am using session variables for membership or shop cart processes.
When I copy the new bin file in server,(when I publish my app), the session dies. How can I solve this update problem?
What shall I do to keep session alive? Because Visitors are losing their shopping carts.
Thanks for help.
A number of things will cause IIS to drop a session:
Lots of files update and ASP.NET proactively recompiles for you.
The session times out naturally
Updating the web.config which would cause it to
recycle
The site app pool recycles for another reason
It sounds like you are falling afoul of the first, and there's no way to prevent that behavior.
It sounds like you are using "In Process" Session, which is the default, which is why you are losing the baskets etc.
From MSDN:
InProc mode, which stores session state in memory on the Web server. This is the default.
The other options are:
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.
Switching session to any of these others would enable you to update, but migration isn't instant.
When I copy the new bin file in server,(when I publish my app), the
session dies. How can I solve this update problem? What shall I do to
keep session alive?
By default, Session-State Mode is InProc. You want to use either StateServer or SQLServer.
In Windows Azure, we use Custom mode and store in Redis Cache.
Because Visitors are losing their shopping carts.
Even then, Session State is not reliable.
I normally create a Shopping Cart table in database. Then save the Id of the shopping cart inside cookie on the client browser.
In addition, if user logins, I also save the UserId in the same table, so user can still view his/her shopping cart at any computer.
For example, amazon.com has similar approach.
I have two website consider it as website1 and website2.
In website2 there is a login page .When a user click on the login button it will call a HTTPhandler in website1 to authenticate user.On successful authentication user information will be stored in a Session variable from handler.
Then it will redirect to a page page1.aspx in website1.But the previously set session is not available in the page1.aspx .What will be the issue?
I checked the session id in first request(when calling handler in website 1 from webiste 2) and Second request( redirecting to the page1.aspx from the handler) the session id is different.
How can i retain the session data?
You need to store session data in another process shared to both web site.
You can do it intwo different ways:
Configure an SQL server
Configure SessionState service, a Windows service used to share informations.
In both cases you have to change both web.config files to support the new session mode.
I.e. to use SQL:
Prepare a database (from command prompt):
cd \Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regsql.exe -ssadd -E -S localhost\sqlexpress
Modify web config as following:
<sessionState mode="SQLServer"
sqlConnectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Initial Catalog=Test" allowCustomSqlDatabase="true"/>
You don't need to change your code.
Correct me if I an wrong, AFAIK different domains cannot share a single session. One way to handle this is to carry the data to the other site through cookie [encrypt the values for security], then copy this cookie value to the session in the other site receiving it and destroy the cookie.
And if the sites are in different servers you need to handle the "sticky session" so that servers share the session.
This situation sounds kind of similar to one I have experienced and worked on before, where one web application acts as the login page while another is the actual app where all your work is done. I can describe what I did in the hope that you find it useful.
Like you I had one web app which had the login page (so in your example this would be website2). When the login form submitted I then redirect to a fake Login.aspx page in website1 - this is where we differ I think as I'm not sure of your specific reason for using a HttpHandler.
In my case the website2 Login.aspx page is actually just the way into the web application; it has no markup, just code-behind which will authenticate the user, perform setup (e.g. set session variables) and then redirect to another page such as Homepage.aspx. This particular scenario has worked for me, so maybe your problem revolves around the use of a HttpHandler though I would not be able to tell you why.
In order to retain the same session date across two different servers running ASP.NET web applications you must configure your session state to be managed out of process. This means the actual session state data variables will be stored outside of worker process and in another process that is able to make the session data available to other machines.
To achieve this you can configure your application to use SQL Server to store session state and make it available to multiple servers in your farm. The TechNet article Configure a SQL Server to Maintain Session State (IIS 7) provides details on hor this is done in IIS 7.
If you are using IIS 6 then the steps to configure are somewhat different and I can provide further details on this if needed.
In order for this to work you do need to ensure that both servers are running applications within the same domain, e.g. myapp.com, otherwise the ASP.Net session cookie will not be passed between the two servers. ASP.Net uses the cookie to lookup the session state stored in SQL Server and will therefore not find any matching session if the cookie is not passed on requests between the two servers.
i think IRequiresSessionState will not help because context is different.
once we had the same problem but that was passing asp session varibles to .net. How ever you can do it here also.
on both website create a page setsession.aspx
now if you are on page say web1/page5.aspx and want to go to web2/page3.aspx
you redirect to web1/setsession.aspx?togo1=web2/page3.aspx
in both setsession.aspx logic in to extract sessiondata and place them in querystring
so the web1/setsession will redirect to web2/setsession.aspx?sess1=value1&sess2=value2&togo=page3.aspx
web2/setsession.aspx will check for togo querystring and if found will extract all querystring name and value will set them in session and will then redirect to togo value.
you need to differentiate togo1 and togo carefully.
Session sharing between websites is going to require hand-coding. You could hack the asp.net framework to get this working, but I feel that this is not a clean way of achieving what you set out.
If user authentication is all you are doing from website, is it possible to use alternative? Single Sign On mechanisms will help you out here.
Something like SAMLSSO could help you in this case.
You have two websites which are hosted on different servers, it means you have two different processes running on separate machines, so sessions will be definitely different. Same session can't be shared across processes because by default asp.net support in-memory session.
Here you would need to think about storing sessions information which can be shared between two processes (i.e. out of process). Ideal way to store sessions information in databases. For this you can consider Stefano Altieri code sample above.
I don't think you really want to share session information between two websites at all. From what I can gather from comments, what you're really trying to do is have a user authenticate in one website (give you a username and password which are validated) and then have that "logged in" state transferred to another website which doesn't handle authentication for itself.
What you are describing is the Delegated Authentication model.
In this model, your application hands-off authentication to other systems which it trusts to provide information about users.
There are two well-known protocols which provide this mechanism:
OpenID
This is intended to facilitate users logging in with their own identity providers (Google, Facebook, Microsoft Account). It's a very good choice if you're running a public-facing website, as most users will already have an account they can log in with.
WS-Federation
This is intended to facilitate users logging in with identity providers which are managed by known trusted parties, such as partner organisations.
From version 4.5, the .NET Framework has built-in support for WS-Federation via the Windows Identity Foundation component (and is also available for earlier versions as a separate download). This automates the task of delegating your authentication to an Identity Provider.
It also provides components for you to write your own Identity Provider, should you want to create your own, but you shouldn't have to; you can find various existing implementations to perform this job for you.
The problem you're trying to solve is a very difficult one, especially trying to make it secure enough to be reliable. The good news is that smarter people than you or I have spent years working out very clever ways of doing this. You should use what they have done and not try to cobble together something out of Session state.
In the long-run it's best to let the smarter men do the hard work for you.
My asp.net session objects are storing in SQL server.I am storing an ID in session. If client open another browser and storing different ID in session. I need to notify client is “are you sure you want both ID’s open?” in same based user logged user.
Application runs on logged in user (not anonymous)
How can we check this in asp.net?
Session is not linked to an authenticated user, and there is no way of accessing an other connection's Session without knowing its SessionID.
Usually this kind of problem can be solved using cache instead of session state. With cache you can create your own user-based keys to store data. Depending on whether you are planning to just run your web app on one server or in a web farm environment, you can either use asp.net in-process cache or one of numerous distributed cache solutions (like memcached which I'm using in my web projects with great success).
There are a couple ways to go about this:
Option #1, in your user table, add a value called "session id"
When a user logs in, check to see what their last session id was. Then test to see if it's still a valid session. If it is, ask them what they want to do. Store the latest session id in that table after each log in.
However, I'd go with option #2: Don't do this. If the user wants to open multiple browser windows to access your application then let them. There's probably a pretty good reason for it. Most (as in nearly all) users have no idea what "session state" even means and they really have no desire to know. All they care about is getting their job done.