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).
Related
I am using an MVC app to manage authentication. The issue I have is with chrome because it never actually kills the session because it runs in the background after it closes by default. I do not want to enforce all the end users to change this setting because then it will kill hangouts etc.. So I am wondering if I can use any standard web.config setting to handle this or do I need to make an ajax polling interval to keep updating the cookie expiration?
The ASP.NET session consists of 2 components the client-side http session cookie and the server's session storage provider. Suppose user has SessionId 1. If you delete session 1 from the server, the user returns and a new session is created with SessionId 1. If the user deletes the session cookie, the server keeps running session 1.
What you're asking for is generally not possible. There's no way you can force a user to send a request to your server when they are exiting your site or the browser. There is the javascript beforeUnload event which in some situations would allow you to send a request to /sign-off in some situations. The obvious limiter is no network access = no message.
The standard resolution for orphaned sessions is for session scavenging policy to clean them up. Some developers choose to use persistent storage to eliminate scavenging altogether such that a shopping cart would never disappear.
The only reasonable solution (which is still overkill) that would reach your goals. You use SingalR for a persistent connection of the user to the server and you ping them from the server. If the connection fails to respond you abandon the session. This will be a fragile process and if you don't make very very sure the user is disconnected you will have lots of support calls from users wondering why they are continuously logged out while browsing your site on cell phone.
Suppose I have logged into an application which is running from IIS. Now I haven't logged out, but closed the browser. And when I'm accessing the application again, it defaults to the login page. How does IIS recognize that it is a new request and redirects the user to the login page?
I have another question. Suppose if I'm not closing the browser, which I used when I logged in. I'm opening the new browser to request a page from same application. IIS recognizes that it's a new request to the application and redirects the user to login page. Why does it not use the existing session or cookies which the first browser uses?
Please don't get irritated of my continuous questions... I am having huge confusion.
We say HTTP is a stateless protocol. Once the page is requested I have logged in. And the HTTP protocol connection will be terminated between IIS and browser, right? Then I am navigating to other pages in that logged in application. Now IIS recognises the user has logged in on this browser. But when I open a new browser and request that application, how does IIS recognises it is a new request? Since the HTTP protocol is disconnected, how does it work in the first case?
As you've correctly said, HTTP itself is stateless, and each request is technically separate from every other. Sessions, as used by web sites, are a workaround for that. What happens, normally, is that the server stores whatever info it cares to maintain between requests (like the logged-in user's username and/or ID, for example), and assigns that information an ID (called a "session ID"). It then tells the browser that session ID, in such a way that the browser can hand the ID back when it's time to make another request. If the browser plays its part and provides the session ID, then the stored information can be retrieved, updated, etc with each request, providing some degree of state even over a stateless protocol.
Sessions are usually implemented using cookies. That is, the server hands the browser a cookie with the session ID, and the browser hands back that same cookie with each request until the cookie expires or is otherwise forgotten. Some cookies (so-called "session cookies") aren't saved, and are forgotten when the browser is closed. A freshly opened browser doesn't have any session cookies to pass, so if the server uses session cookies to do sessions (which it should), it will consider the user not yet logged in and bounce them to the login page if they need to be logged in.
Session cookies will usually be shared between tabs in the same browser, and will sometimes even be shared by windows opened by "File > New Window" from an already running browser, because both of those cases will typically just be a part of that browser. But if you start the browser from the Start menu, or however your OS lets you start a program, it's a whole other process -- and session cookies are rarely shared between processes.
The server typically also only remembers sessions on its end for a limited time (anywhere from seconds to years, depending on the server and/or site settings) after each request that uses the session. If the browser passes a cookie that corresponds to a session the server no longer remembers, it'll act as if there's no session at all. Which, in cases where you have to log in, will again bounce to the login page.
There are cookies that are passed always no matter are you logged or not. They are mapped to session in IIS.
Check out the following articles. They might be helpful.
IIS Dropping Sessions
Session Management in ASP.NET
I say until you log out, session times out or you close the browser. But am I right?
I had an interview today and the interviewer wanted to know if I log into a page and closes the browser (without logging off), what happens to the session.
I said that the session will be orphaned. He says no - because their users are able to connect back to the session by just opening up the browser (using a cookie only). I told him that's a persistent cookie - not a session cookie.
And I said that if that's the cause, there is nothing preventing the user from exporting the [persistent] cookie to a another computer and starting the session on that computer.
At first he said you can't export a cookie but when I explained how, he said that he'll look but since many many people including 2 architects came up with the design, it is unlikely they are all wrong.
A session cookie is a cookie without an expiration time.
Handling of session cookies varies by browser and by browser version, but generally cookies that have no expiration date are deleted when the last instance of that browser is closed (lifetime=runtime of the browser).
Importantly, the server-side session that corresponds to the cookie value has a completely independent lifetime that is defined on the server. HTTP is a connectionless protocol, so when your browser isn't in the middle of a transaction, the server side has no idea whether you're still there or not. Tomcat issues unique, fixed-length cookies named JSESSIONID that they link to stored session data on the server. In that case the session expiration time is stored on the server. ASP base64 encodes all the session info, encrypts it, and writes it to giant cookies in your browser so it doesn't have to store that session data on the server. The session expiration time is saved inside the encrypted data stored in the cookie. Either way there's a record of when the session should expire, so session lifetime can't exceed the server side timeout.
You can set the same cookies in another browser and send the same data (mostly cookies) that the first browser would have sent, and as long as the server timeout hasn't been reached, the server will let you access the server-side session the same way. When people do this to your cookies, it's called a session hijack.
Here's JavaScript code adding a "session" cookie, which is just a cookie where no "Expires" value has been set.
document.cookie="COOKIENAME=cookievalue";
Here's JavaScript that adds a cookie with a specific expiration time, meaning that the browser is instructed to stop sending it with outgoing requests after that time:
document.cookie="COOKIENAME=cookievalue; expires=Fri, 31 Dec 9999 00:00:01 GMT";
The cookie data sent to the server does not include metadata like expiration time; the server only sees the key=value pairs.
Expiration data is only for the browser to read.
Setting a cookie with either of the above methods will cause the browser to send that cookie to the server this way:
Cookie: COOKIENAME=cookievalue
The server initially sets the cookie with or without an expiration date, but it has no idea whether that has been changed, and it doesn't really care. There's no functional difference between a cookie set to expire next month and a session cookie on a computer that stays on with the browser running until next month.
You are absolutely right. Session cookies are deleted when the browser closes and persistent cookies are deleted when their expiration time is up. Their website must use persistent cookies if the sessions stays alive after the browser closes. All cookies can be exported to another computer. This is a well known security vulnerability that is mitigated by using SSL.
There isn't a clear definition of "session" in web applications. A web site may decide to use either persistent cookies or session cookies to look up a session context on subsequent requests (or maybe something besides cookies). If the session lookup is done through a session cookie, then what you said about the session being orphaned (on the server, not accessible by a client) is correct.
However, "when you close the browser" is ambiguous. If you have two instances of Internet Explorer open, for example, both windows may be keeping a session cookie alive. Therefore, closing "the browser" that the web site page is displayed in won't necessarily clear the cookie.
Not sure if it's the same as ASP, but I know that in PHP it's 20 minutes
For various reasons I am fed up with ASP.NET session state and I'm trying to do it myself (separate question coming soon related to why I'm fed up and whether it's feasible to do it myself, but for now let's assume that it is).
Security concerns aside, it seems like tracking sessions involves little more than storing a cookie with a guid and associating that guid with a small "sessions" table in the database, which is keyed on the guid and contains a small number of fields to track timeout and to link to the primary key in the user's table, for those sessions that are linked to registered users.
But I'm stuck on a detail with the cookie, in the case the user's browser is not set to accept cookies. It seems to me that each time a user accesses any page that has session state enabled, ASP.NET must determine whether the browser supports cookies. If there already is a session cookie sent with the request, obviously it knows cookies are accepted.
If not, it seems like it needs to check, which as I understand it involves trying to write a cookie and redirecting to a page that tries to read the cookie. So it seems, when a user with cookies turned off visits several pages of a site, that ASP.NET
(a) has to do this round-trip test for every page the user visits, or
(b) has to assume the browser accepts cookies and create a record with a (provisional) session id for the user on each page -- and if session state is supposed to be persistent, it seems it has to write that initial session id to the database on each page.
But (a) sounds crazy and (b) sounds crazy also, since we would quickly accumulate session ids for all these single-page sessions. So I'm thinking there must be some other trick/heuristic that is used to know when to do the round-trip test and/or when to actually create a record for the session.
Am I wrong to be perplexed?
(To be clear, I'm not talking about implementing a custom storage solution within ASP.NET's pluggable session state system. I'm talking about skipping ASP.NET's session state system entirely. My question is a more detailed version of this one: Implementing own Session Management in ASP.NET.)
Session behaviour is set through the sessionState element in web.config. In the sessionState element the HttpCookieMode can be set to one of UseUri, UseCookies, AutoDetect, UseDeviceProfile.
UseUri and UseCookies tell ASP.NET explicitly how to handle storing the session identifier. If UseDeviceProfile is used then the behavior is determined by whether the user agent supports cookies (not whether they are enabled or not).
AutoDetect is the interesting case that you are interested in. How ASP.NET is handling the auto detection is explained in Understand How the ASP.NET Cookieless Feature Works. In that article you will see that they have 5 different checks they do. One of the checks is, as you mention, to set a cookie and do a redirect to see if the cookie exists. If the cookie exists, then the browser supports cookies and the sessionID cookie is set. However, this is not done on every request because another check they do before tring to redirect is is check to for the existence of any cookies. Since after the initial set-cookie and redirect the sessionID cookie will be set then the existence of the cookie lets ASP.NET know that cookies are supported and no further set-cookie and redirects are required.
Well, cookies are a standard mechanism of web authentication. Do you have any reason at all why you wouldn't want to use them? Are you sure you're not trying to invent a problem where there isn't any problem?
Most serious websites I know of require the browser to accept cookies in order for the user to be authenticated. It's safe to assume that every modern browser supports them.
There's an interesting article about cookieless ASP.NET that you should read.
EDIT:
#o.k.w: By default the session state is kept by ASP.NET in-process (read: in memory). Unless told explicitly by the configuration to store the session in the database (SQL Server is supported out-of-the-box), this won't result in a database hit. The stale session states will get purged from the in-process storage. Unfortunately, with default ASP.NET settings every cookieless request will result in a new session being created.
Here's a detailed comparison of available session storage options: http://msdn.microsoft.com/en-us/library/ms178586.aspx.
In config file I have the below settings
sessionState mode="InProc" cookieless="false"
Does this indicates that the sessionid is stroed in cookies? If yes then how is it picked and sent to the server and how is it verified across postbacks.
What will happen if cookies are disabled in my browser, will the session(sessionid and session variables) still be created?
Where(default path) are the cookies created and stored by default for sessions and can i change the path?
What format and kind of data is stored in cookies for session?
If i store a class object in session then what is actually stored in cookies?
Also if i use authentication mode as forms with cookies then what will happen if cookies are disabled in browser?
The session cookie is a special non-persistant cookie. It's only stored in memory, so in most cases even when cookies are disabled it still works fine.
It's also possible to enable something called cookieless sesssions where the sessionID is embedded in the URL, like this:
http://yourserver/folder/ (encrypted session ID here) /default.aspx
Here's a link to an MSDN article with more details: http://msdn.microsoft.com/en-us/library/aa479314.aspx
NOTE: It is possible to completely block the session cookie. For instance, in IE8, I just went into Tools > Internet Options > Privacy. When I cranked the slider up to 'High' or greater, my sites never got past the login screen because the session cookie was blocked - in fact, Josh Stodola said below that in this case the session would never even be created on the server.
However, understand that this type of behavior effectively breaks the Internet. So unless you're building a site targeted at conspiracy theorists, in my opinion (and the opinion of most of the largest sites in the world) there's no need to cater to the tiny percentage of users who don't play by the normal rules.
For them, the Internet just isn't going to work the way it's supposed to.
My guess is that each request by the client will be seen as a new session by the server.
If you happen to grab the request headers from your browser, you can see that a SessionID is part of the header. This is used by the server to determine which session belongs to which user.
Instead of session id being passed via cookie, it is typically passed as a query string in the URL, or as a custom HTTP header. With the scenario you described, however, your user will never obtain a session because you have cookieless set to false.
I have not implemented this personally. But it should be like:
As Cookiless=false in web.config file and browser has disabled cookies, when first request for the page comes, HTTP module will check for forms authentication cookie. Now it will be empty which send user to login page. Now when second request for any page on website will come it will again find forms authentication cookie empty and send user to login page. So for every request user needs to create new session.
No, If cookies are disable the session will not work.
if you want to use session when cookies disable then you can pass session thru URL.
It stores directly in the browser
There are two ways session state can store the unique ID that associates client with server session; by storing an HTTP cookie on the client or by encoding the session ID in the URL.
Session Mode="InProc" is a default mode which stores the session state information in web server. However when you say cookieless="false" you are saying to stored unique ID in cookie. This Id is created when session is created, so during postback ID is picked up from cookie. If cookie are disabled in browser,yes session still will be created and this id is passed along URL.
You can browse to cookies by going to browser settings->Privacy->Content Settings->All cookie and site data->Stored with site name
Probable you might find cookies in %userprofile%\AppData\Roaming\Microsoft\Windows\Cookies but might differ from operating system to system.
In cookies you usually store small piece of insensitive personal information. If you need to store sensitive data such as user name and password it is better to encrypt those data.
In cookie you usually store information about the users. For more details please visit URL
http://msdn.microsoft.com/en-us/library/system.web.configuration.sessionstatesection.cookieless(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/ff647070.aspx#pagexplained0002_cookielessforms