I am building a website with asp.net and c# 3.5.
The problem is User Session gets cleared between requests. Not all sessions, just that user session is renewed suddenly when a new request or postback occurs.
I am using IIS7 and Win2008 R2. I Checked and found out that no recycling happens, WorkerProcess is set to 1, Website is not restarted. Just a user session is renewed and gets new sessionId. not all Sessions, just a user session is renewed.
It is A very strange problem, I searched the web and couldn't find the solution
If you have any clue?
I think i found my problem, The problem name is "canonical domain". Users enter the site without www in start of its url, but between request ( especially in Respone.Redirect("~") or when i redirect user to payment gateway and when it returns back ), the url turns to a url with www. So the cookies renew and that user session lost in this point.
Canonical domain can be solved with IIS7 Url Rewrite module, in SEO -> Canonical domain name.
Related
I have a website in production server, asp.net webforms using Asp.Net Identity system.
Sometimes, when users tries to login, it redirects then back to login page after successful authentication thereby denying them access to user dashboard and other secured pages.
The temporary solution to this is for me to Recycle Application Pools in the hosting server (via plesk). But it appears again after some time. Sometimes before 24hrs or more.
The issue most often occurs when multiple users are getting logged in at a range of time... From my observation.
I don't know the main cause of the issue and I'm seeking a permanent fix to it. What could be the issue? How can I resolve this?
Useful hint:
After authentication at the login page, I usually create a response cookie which holds other value which I use to keep track of the user. If the cookie expires, I redirect the user back to login. I usually check for existence of this cookie on the master page for each page load. So I don't know if this could be a possible cause. If it is, whats the best practice to employ?
I've tried checking the cookies being set if it's the possible challenge, but no success.
This is probably a duplicate question, but since I can't find the answer in the questions from the past I am going to ask again.
In my ASP.NET application, when I authorize the user, I set the custom FormsAuthenticationTicket. The persistance variable is false, so the authentication cookie should only be valid for current session.
My question is when would this session end? I restart my IIS Express development server, I shut down the dev machine, etc, and the session seems to be still active and the user is authenticated with that cookie.
How come in my VS 2012 + IIS Express environment sessions are immortal?
That's not an issue. You can restart the server and as long as the authentication cookie is still valid, the user is considered logged in. Remember, HTTP is a disconnected protocol.
The cookie will be removed the moment the user logs out and you programmatically remove the cookie or when the user closes his browser.
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
We have a non-SSL ASP.NET web app that allows a user to login (ASP forms authentication, inproc).
Once authenticated, we redirect their browser to an external, SSL secured page on another web site / domain altogether that we do not control.
The client is redirected back to a pre-configured url on our original http web app when done.
However, the customer is then asked to "re-login" again on our side which is undesired...
It seems the forms authentication cookie is destroyed when transitioning between HTTP and HTTPS and back again.
How can I keep the forms authentication cookie alive so that the customer does not have to re-authenticate on the round trip?
It's not being destroyed; you're not authenticating on your domain, so the cookie's not being set on your domain, and thus requests on your domain will not contain said authentication cookie.
This is GOOD. If this didn't happen, then every cookie from every domain you ever visited would get sent with every request. Which is obviously 1) crazy and 2) a security hole. Setting a cookie on mydomain.com should never be visible to pages on myotherdomain.com.
If you're using a 3rd party authentication system, like google, facebook, etc, they'll all have some sort of callback token that you'll have to process and set your own cookies.
Consider to set cookie's domain property for your cookies with more specified can be found here or try this code:
Response.Cookies["your_cookie_name"].Domain = "yourdomain.com";
You're looking for a Single Sign On solution.
It might be a little overkill for your problem, for which you might just want to get the same domainname. But if that isn't an option you might want to take a look at:
Windows Identity Foundation
Suppose I have logged into an web application. I'm on the page Default.aspx. If iis restarts then I need to re-login to use the application.
Is it possible to go back to the same page if IIS restarts?
How are you authenticating your users? Using forms authentication stores a client side cookie which can survive IIS resetting. Are you storing any authentication information in session state perhaps?
Edit
Just to add you can also redirect a user to a different page from the login page. Take the following url http://example.com/Login.aspx?ReturnUrl=%2fDefault.aspx.
This URL can be used to redirect the user to the Default.aspx page after they login. Assuming your using Forms authentication you can then redirect them using FormsAuthentication.RedirectFromLoginPage(userName, false); The false parameter prevents a persistant cookie from being created.
If you mean the ASP.Net application domain recycles, you're issue is that you're losing session state data, right? If that's the case, then how about storing session data in the StateServer or inside SQL Server? The default is "in process", so it's wiped clean when the app domain recycles.
If you set a cookie on each page the user vists stating which page they were on, then in your OnLoggedIn event you can check for the existance of this cookie, and redirect the user to the page - we use a similar mechanism for round-robin logins to multiple domains at once.