I was trying to create an asp.net application with session state as out proc. (State server). When following the steps given in this article it was mentioned as we require to set the sessionstate in our IIS and we need to start an asp.net state service in our service management. My question is, if i change in IIS will it not affect the session handling of other applications? what if i have 2 applications and i want only one application to have session mode as out proc and other as inproc.. in this case changing in iis will require other applications hosted in that iis to follow out proc mode of session handling?
Please let me understand this in detail. Please let me know if further information required on this if any.
Which version of IIS are you using? If it is on Windows Server 2008 R2 or greater Session state is configurable on a per application basis(the configuration is actually stored in the application's web.config file).
Rather than going to Session state at the root website node as they have done in your link expand out so you can see the application you want to change, select it and then select Session state and select the session storage you want the application to use.
The default Session setting is InProc for .Net applications so I suggest changing the one you want to use the State Server.
Related
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 an asp.net application in which i redirect from one page to another. I'm validating the SessionID in the second page to make sure both requests are of the same session. Now, my problem is the SessionID changes whenever a Postback is happened.
Now, I added the Session tag into my web.config
<sessionState mode="InProc" cookieless="true"/>
Now, the problem with the session was solved and a new issue started appearing. Whenever i make a call with Cookiless="true" in my web.config file, my URL shows a junk address
http://localhost:10766/(S(ojbcobj0aw0wiosttgpknwby))/registration.aspx
If I remove the Cookieless tag the session will be lost in the next page?
Do anyone know why is this coming and if any fix is there for this problem?
I went through lot of threads but i couldn't find a proper fix for this.
EDITED:
I Set my cookieless="false" and now its working fine.
.NET Framework has 05 (five) session state modes:
InProc mode, which stores session state in memory on the Web server. This is the default.
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.
Off mode, which disables session state.
Now i need to know exactly what does your application do to recommend the better solution:
Do you store something in Session?
Are you using multithreading?
How many servers your farm will have (when the application go live)
Does your app connect to database?
If you keep your original web.config, by default your application will use InProc mode and will store session id on cookie, unless your browser or local server denied it.
I'm waiting to the answers to complement my post.
Reference:
http://msdn.microsoft.com/en-us/library/ms178586.ASPX
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.
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.