I want to save some data to the session state. I need to save this data off when a user first logs in via forms authentication. I need this session state variable to have the same lifetime as the forms authentication ticket expiration. Is there some way to ensure that these two stay synchronized?
Is there some way to ensure that these two stay synchronized?
Both have a timeout value in web.config that you can set to the same value. Now this being said here's where your problems might start. A forms authentication cookie might have a sliding expiration setup whereas a session not. So make sure you disable this sliding expiration for the authentication cookie if you want the two timeout values to match. And that's just the beginning. For the session you can choose where to store it: Off, InProc, StateServer, SqlServer.
When you use Off (personally what I use) ASP.NET session is disabled and you basically don't have any session.
When you set it to InProc (which is the default value) the session is stored in memory. Except that IIS could decide to recycle the AppDomain under different circumstances: a period of inactivity, certain CPU/memory threshold is reached, ... This basically means that if the session is stored in memory and the AppDomain is unloaded by the web server you loose everything stored in this session whereas, obviously, the authentication cookie continues to be valid.
StateServer and SQLServer are 2 different modes of out of process session storage where the information is no longer stored in the memory of the web server and can survive AppDomain being recycled.
So basically to sum up it is very difficult to synchronize in a reliable manner the ASP.NET session lifecycle and the ASP.NET forms authentication cookie lifecycle. I solve this problem by not using ASP.NET session at all.
Related
We constantly deploy updates to our application
However each deploy terminates all user sessions.
I want to implement a session system that doesnt have this issue using cookies or similar.
What is the best approach?
There are basically four ways of handling session (from MSDN):
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.
You are, most likely, using In Process session (the first one listed) which is causing the session drops during the deployment process.
Moving to any of the others would meet your requirement, but none are instance and they all have upsides and downsides, so you'd need to pick the one that meets your (and your organizations) needs.
If the session is stored in proc
The user logs in, closes the browser directly and reopens it after an hour. Would he need to log in again?
If the web application uses cookies and cookies are enabled on the users browser...
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the web application uses cookies and cookies are disabled on the users browser...
If the web application uses persistent cookies and cookies are disabled on the users browser...
If session is stored in state server and situations are the same, then what would happen?
When a session is created (assuming it is a normal session), a cookie is sent to the browser that looks something like this:
SESSION_ID=437b930db84b8079c2dd804a71936b5f
Sessions can be used without cookies if the session identifier (in the example above, 437b930db84b8079c2dd804a71936b5f) is passed around as request parameter instead of a cookie; however, this is rather uncommon and it is generally considered bad practice.
All session information is stored server-side, and the session identifier is used behind-the-scenes to decide which set of information should be recalled (if any) for each request. Thus we get to your questions.
If the web application uses cookies and cookies are enabled on the users browser...
If the web app uses cookies and cookies are enabled on the browser, then there should not be a problem. With a standard session implementation, the cookies will be non-persistent, though, so the user will need to login again if he/she completely closes all instances of the browser.
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the session-id is stored in a persistent cookie and user's browser respects that by persisting the session identifier cookie to the disk, then the session identifier will be sent even if the browser is fully closed and restarted. However, please be aware that most web frameworks have a garbage-collector-like system that deletes data for sessions that have showed any activity over a certain amount of time. So, for example, let's say my website requires activity at least once every 4 hours to keep a session active. If I login, receive a persistent cookie with my session ID, close my browser, and come back 5 hours later, then I will need to login again because my session information would have been cleared from the server even though my session ID cookie was persistent.
If the web application uses cookies and cookies are disabled on the users browser...
Bad news bears. You will either need to find a way to use a cookieless session (passing an identifier as a parameter for each request), or you will need to ask the user to enable cookies. There is no way around this.
If the web application uses persistent cookies and cookies are disabled on the users browser...
Same situation as #3. If the user has cookies disabled, you are out of luck. Either they need to enable cookies (at least for your site), or you need to find another way to pass around information between requests.
Session is stored in server memory (unless a state server or persistant store is used) but relies on a cookie to identify the session. If cookies aren't available then session won't work since there is no way to identify the user. Cookieless sessions can be used to get around this. Cookieless sessions aren't recommended as they can be hijacked with the session identifier in the url.
If an expiration isn't set on the cookie then it will be lost once the user closes all browser instances (they share memory) and not just the one visited through the website.
If the user has cookies disabled, then cookies aren't available for use by the application. People aren't as worried about cookies now as they were in the late 90's (lots of "security" people raised warnings that cookies could be used to store all sorts of things on your computer, even viruses).
I'm using the InProc session-state mode in my web application.
In order to test the client's behavior on a session loss I restarted the web server, first just iis, then the entire machine. Both actions did not lead to a session loss.
This puzzles me: The session is stored on memory, right? How can the session be retained after the machine restarted? Does IIS dump the sessions on disk on a restart? If so, where is this documented and how do I flush the sessions for testing purposes?
I'm using IIS 8 on Windows Server 2012.
EDIT: I don't know whether I actually lose the session - what I know is that my cookie is still accepted. (I don't actually use any "session", I just need to authenticate the user.) It could be that the authentication ticket is usable even after the actual session is lost, as is suggested here.
EDIT: Also look here for more information about the forms authentication cookie and what's in it.
Contrary to what I assumed, the authentication entry in the cookie isn't merely an opaque identifier of a session, but actually a encrypted username with an expiry time. It is not directly related to a session at all, and its validity is independent of the validity of any sessions.
That means that the expiry of authentication and the loss of the session are two distinct events that usually occur at different times.
Look at this and this link for more information.
Here I want to know different types of Session in ASP.NET and not Session States. That was the question asked in an interview.
Session-State modes are 5 type:
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.
Check the detail. https://msdn.microsoft.com/en-us/library/ms178586.aspx
Typical sessions are based on a cookie. The server gives you one, you send it to the server upon every request. However, Asp.net allows you a different type of sessions as well - cookieless sessions. The session id is then "stored" in the URL address. This technique is very dangerous if used improperly.
Would definitely need more clarification from the OP. I feel the terms are being used inter-changeably.
By nature web is state-less. To overcome this ASP.Net provides several state management options like viewstate, controlstate etc. Session State is one of these options.
ASP.NET session state supports several storage options for session variables. Each option is identified as a session-state mode type. There are four mode types or just modes. In-Process mode, State Server mode, SQL Server mode, Custom mode and Off mode. These are modes. In-Process mode uses memory as session storage. State Server mode uses state-server as session storage. And so on. Besides, when a mode is specified by way of web.config, some additional parameters are also required like connectionstring, timeout etc. One of these parameters is "cookieless" for which the default value is "AutoDetect". If specified as "true", it will embed the ID in url. (As explained by #naivists). Cookieless option can be used with any mode.
This is all what there is to ASP.Net Session. I feel there is just some confusion on terms state, mode, mode type, storage etc. being used interchangeably. Apart from that there should be no other separate thing as "session type".
There are three kinds of session, and they are listed as follows
Inprocess.
Outprocess.
Sql server session.
where they are stored.
inproc - default stored in web.config.
outproc - stored in server side.
Sql server - stored in database.
You have following types of session management in asp.net which you can define in your web.config file
Session mode="inproc"...means the session will be stored on the webserver within your application
session mode="outproc"....means session will be stored on the server outside your application
session mode="stateserver"...means session will be stored in a temporary memory in the database
session mode="sqlserver"...means session will be stored in the database permanently.
three types of session in asp.net.
inprocess session
out Process session
SQl-server session
I had a query on behavior of an ASP read only application using a custom Session State provider.
I assume, for a normal read-write application/web-page the session will be recreated after the expiry as long as the client has sent a session cookie. The runtime may opt to change the session identifier at this point, but it normally won't. What about Read-only applications? Do they follow the same behavior? If they are recreated, Can they update these sessions?
Thanks,
Alfan