I have an asp.net website running on IIS7 and have been having an issue with some users from a university suddenly losing their session. The one thing all these instances have in common is that the user's client url/host address, that they are accessing our website from, changes half way through their session. To be clear, this is what I am recording on their page access:
Request.UserHostAddress.ToString()
Session state is tracked using the standard asp.net cookie. The relevant line in web.config:
<sessionState mode="InProc" timeout="40"/>
The website doesn't use frames, and is run from a single server (i.e. not a web farm) using a single worker process (i.e. no web gardening). It only occurs periodically to a single user while other user's sessions remain open at the same time.
I've added cookies to the list of things to be logged for the site as per this article on troubleshooting Session loss. A couple of questions:
Is it possible that it is the university that is dropping the session cookies and our server isn't even receiving them? And if so, would enabling the logging of cookies pick this up?
Is it possible that IIS drops the cookies if they don't match the previous url associated with it?
The cookie keeps the connection with the session and its associate with the domain. In some cases the domain maybe called with www. in front and in some other case not - and the cookie will be lost, so an the session.
To avoid that place on web.config the domain name as
<httpCookies domain="domainname.com" .... />
with out the www. to keep the cookies with or with out it.
Now because you use InProc that is run as a service and keep the session on memory and not on a database, this service is known that is drop the session for some reasons. To avoid that you must use a database to keep your session.
Other case can be a move from https to http and if you have place the cookie only to be secure, will be lost again.
related Share session between ashx and aspx
Related
Code is hosted on same server with two different domain one is Internal testing(abc1.com) and External testing(abc2.com) and different app pool for them, code is same and folder structure is same.
Session lost issue only for only one domain abc2.com.
Session set from one page and after Respone.Redirect trying to access session is lost in case of External testing site only.
Any one having any clues.
How to troubleshoot issues ?
There are actually two problems here;
As #John rightfully mentioned in the comments, if the domains don't match then your sessions aren't carried over. The reason is that for sessions to work classic ASP issues a unique cookie per visitor.
Cookies are bound to a (sub)domain, if you run on two different (sub)domains the cookies set on one domain can't be read by the other domain.Therefore the session on one domain won't be matched to the other domain.
Unfortunately that still won't solve your problem completely, because each application pool in Classic ASP also creates it's own session cookie. That's why increasing processes on your application pool will also result in a messed up session scope.
So in short, sessions in classic ASP only work in the same domain using a single application pool process.
The ony way to work around this is to write your own session scope, issue your own cookies per user, and store corresponding variables in a backend of your own.
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
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
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.