I am implementing site with login via facebook.
I call FormsAuthentication.SetAuthCookie(response.email, true); after facebook authenticates user.
Form authentication timeout is set to 129600 (3 month).
Should i set session timeout to the same value?
As far as I understand session timeout should be as few as possible.
Is it normal if session timeout less then form timeout? (for example form 129600 session 30)
I know that there are many similar questions, but this problem isn't clear for me.
Thanks.
You're using cookies for authentication, your server session doesn't matter. A potential problem is that if you store data on Session object and it expires, that could cause troubles to user since functionality depending on this data would probably fail.
If you handle server Session expiration properly, you won't have any problem.
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.
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 have couple questions about security in ASP.net and in general.
Where are stored "Authorization" cookies? When I logined in the system and then decided to logout I suppose for this enough to delete cookies from my browser but this not work. Then I rethink that these cookies is supplied from browser stored passwords, but wrong again, since I don't see login/password info for my site there.
And since "Authorization" cookie is always returned in response for 401 code, user stays always logined in the system and I can't understand how to logout.
The timeout for ".ASPXAUTH" - 30 min is recommended, and then cookie expired. Though I login, then after recommended 30 minutes I need to login again (even with sliding property to true, I can just leave a page for more than 30 minutes). But when I login to the most of the sites (such as stackoverflow for example), I can enter here again without logining even after week delay. How it is implemented, is that sites just set timeout for much bigger timespan or there is some other techniques?
Thanks!
Answer to question 1:
Use FormsAuthentication.Signout(); to logout. This will delete the authentication cookie. The authentication cookie is stored in the http-request and in the response as every other cookie.
Rergarding your 2nd question: Your cookie should expire after 2880 minutes. I don't know why it expires after 30 minutes in your case. Also the sliding expiration normally works. Could your browser settings have some influence? Another possiblility could be that the Visual Studio internal web server does not behave like a real web server. Try your settings on IIS.
EDIT:
I think the answer to your 2nd question is here
EDIT
This problem seems to have strangely disappeared. There must've been something funky with my environment. I'm voting to close this question.
When a user logs in, I inflate the session with a bunch of data from the Login page code-behind. Then I redirect the user to a different page in the application. I also have some session recovery logic which re-inflates the session based on the auth ticket when the user's session expires.
What seems to be happening is that I inflate the user's session with a bunch of data from the login page, then redirect them, and the request for the page to which I redirect them doesn't seem to have the session, so the application has to re-inflate it. I don't understand this - I've looked at the cookie and the session ID is not changing, and I am not resetting the session data anywhere in the code. Is this an ASP .NET 'feauture'? I'm using ASP .NET 4.0.
Edit:
To clarify: The session is inflated during the login request (on the click even of the login button). During the next request, it doesn't appear the session is populated any longer, so I end up having to re-inflate the session. Any requests that user makes after that, the session seems to "stick" and I have the properly inflated session for subsequent requests.
To answer your question SessionState data is independent of login/logout.
There are several reasons why data might "disappear" from SessionState.
If you are using InProc SessionState on a web farm, the user may have a subsequent request be served by a different machine in the farm.
SessionState can clear if it gets too full (like a cache).
If you are using a custom SessionStateStoreProvider, it may not be saving/retrieving the SessionState properly.
I am using sessionstate stored in stateserver in asp.net. I have a link on header that displays users login id.
Problem:
When session expires in stateserver my application still displays loginid and it throws an error when hits code that depends on value stored in session.
Looks like asp.net has no idea when session expires on stateserver and continue working on same session with value saved in cookie in user's browser.
To tackle this problem in another application i am checking for session with each request and expire user's session if it's expired in sessionstate.
I am not sure i am doing right thing here. Isn't asp.net suppose to keep session data saved in cookies synced with session in stateserver?
Could you please explain what would be best practice to handle this?
The right practice is to "find" the user's session each time you receive a postback. And right then and there, if you can't find it, report an error that their session has expired and they need to log in again.
If you are using ASP.Net Webforms, you can consider the Load event of the page or control to check whether the session has expired. Here's the relevant code
if(Session["yourvar"] == null)
ShowError();
Thanks For all answers,
By Default my session timeout value for form authentication were higher then sessionstate. That made session on sessionstate expire and cause issues. I think keeping form authentication value little lower than sessionstate would be the best practice.