As late, I've started noticing that my web application randomly logs out a user after a random amount of requests between pages. I've gone through all possible scenarios and have noticed that it only happens when the UserIsOnlineTimeWindow property (of the Membership provider) doesn't equal the default FormsAuthentication Timeout property.
Does the UserIsOnlineTimeWindow affect the default FormAuthentication provider?
Do they need to be the same?
If so, please explain ...
The following is pretty self-explanatory, though it doesn't describe any relation between the default Membership API and FormsAuthentication (with regards to the aforementioned properties affecting one another):
Specifies the number of minutes after the last-activity date/time stamp for a user during which the user is considered online.
http://msdn.microsoft.com/en-us/library/system.web.security.membership.userisonlinetimewindow
that does seem strange. UserIsOnLine Time does not update anything I know of. I'd suggest looking at the cookie in a browser like chrome with the dev tools and actually check what the expire time on the cookie is. Best I know, that is the only thing that will cause a logout (besides deleting the cookie)
Related
I've an ASP.NET web site that uses FormsAuthentication and a standard Session mechanism. In one of it's webpage the processing(on click of refresh button grid rebinds) is base on session value.If i leaves the screen open for a 'long time' and then tries the refresh. Nothing refreshes.It because session value expires.
So is there any way, i can set configure setting in web.config and synchronize both authentication cookie timeout and session timeout ?
In web.config, set the timeout value of the sessionState element, and the same value in the authentication element.
First, see this SO thread for your answer.
You can attempt to "synch" - perhaps by logging in and setting session vars in the same method, but that's not really a "setting"....
What follows is just my take/opinion that expands on that answer.
IMHO, I think you need to rethink what each type of "storage" is for. Forms Authentication is exactly for that purpose - authentication to some "content" or "resource" that you deem needs to be protected.
Session is more for exactly that - e.g. because some data/resource is "volatile" (changes within x time) - the usual example for this is if you have an ecommerce site, you have to track inventory changes for availability of a product (inventory changes because of purchases/returns made by users, while other users are browsing/shopping). That or the simpler process of users adding items to a cart (sessions and/or cookies, aka "persistence").
Its important to know that on the client (browser), cookies are the primary mechanism for sessions (or url for cookie-less sessions).
So depending on what content/resource it is you are referring to, change the process depending on which of the 2 types they fall under.
if it's a protected resource then display/access should be controlled by your auth scheme
if it's volatile/changing content/persistence needs, then sessions or just cookies might fit the bill (or newer client side storage)
if it's both (protected and volatile) then, auth first and then whatever mechanism fits the bill for volatile/persisted content.
Hth....
We just upgraded to IIS7 and have had intermittent issues with SESSION variables. In a nutshell a very low percentage of users are getting new SESSION IDs with each page request. Clearing cookies has solved this problem for just about every use I've come across.
My question is... Is there a way to programmatically do this? It's been a lower percentage of calls of people unable to login/can't get a certain application to work, so it's not a HUGE deal, but we are having to walk people through the process of clearing cookies all day. I haven't read of, nor seen a way to force users to clear cookies.
Most other questions on here are uses having this issue everywhere, as if there is a programmatic error. Our applications work fine, it's just a small percentage of users who used our applications on our old server can't get new session cookies from the new server.
We were running IIS6/CF9 and we upgraded to IIS7/CF10. This problem is cross browser. We have seen it turn up in IE, FF, and Chrome.
--EDIT--
If a user clears cookies and goes to domian.com and then to sub.domain.com, the domain.com cookie takes precedent and the browser I guess never returns the sub.domain.com cookie it gets from the sub.domain.com server. Turning on J2EE cookies on sub.domain.com fixes the issue, I guess, but the clients still run around with a cookie from domain.com. domain cookies is whatever is set by default... i.e. we don't set it to anything in app.cfc. I have no idea how it is set on domain.com.
In Application.cfc do you have domain cookies set to true?
Sounds like it could be related to the session fixation Hotfix Adobe introduced in February last year. Was your CF9 server fully patched?
In short, CF now issues new CFID/TOKEN values on every session and won't use existing cookie values (to prevent session hijacking). Make sure your app is writing these new values to cookies and not allowing existing cookie values to be used.
Here's a detailed explanation As pointed out in the comments on that post, using J2EE sessions is indeed one way of solving the problem.
some users of my site contact me and said that they have a problem to see their information. the problem is that they see information of other users !
i developed my site by asp.net mvc 3 and asp.net membership. when i logon by that username and password everything is ok. i think something happened like ISP cash or network cash for them ! because other users hasn't any problem. i check my code and no problem find !
ISP cache or network cache can not cause this problem. you should search for this problem in your code. also authentication method is not in charge of this problem.
the problem maybe because of session or cookie expire. when a session expires, your app may look for a default data (for example form other user roles) and present it. so should look for such security holes in your application.
another problem maybe because of caching problem in your code or asp.net cache ! caching users data and show it to other users!
I once had something like this happen on an ASP.NET page. Turned out the problem was that I had caching enabled on one of the pages and so the user could see the information on a previous user.
The most likely scenario is that you are caching results server-side and not varying the cached information by the user. Either you need to vary the caching by the parameter that is related to the user or by the user themselves (using VaryByCustom).
Example:
[AuthorizeByUser( Roles = "Admin" )]
[OutputCache( Location = OutputCacheLocation.Server, VaryByParam="*", Duration = 500 )]
public ActionResult Profile( int id )
{
...
}
Varying by all parameters here means that each value of the id parameter will have a different cache entry. Here we assume that id is related (perhaps is) the user's id so each user will have a different cached entry. Note your security (the AuthorizeByUserAttribute) would also need to be set up so that it won't serve up cached results to unauthorized users. Here I'm assuming an implementation derived from AuthorizeAttribute which verifies that the user is in the "Admin" role or has a user id related to the id in the method signature. See my blog post on custom authorization for ideas on how to do this: http://farm-fresh-code.blogspot.com/2011/03/revisiting-custom-authorization-in.html.
I had this exact problem when we brought in the source code from another digital agency. We took their codebase and added more features to it. Testing went fine on both dev and staging and we went ahead to publish it.
As soon as the site went live, we had a lot of users complaining that they were seeing other users’ information as soon as they logged in. We couldn’t replicate it because it happened intermittently.
We thought it could be static method. Replaced all of them by instantiating an object and call that method, the problem was still there.
We thought it was Singleton pattern. We removed them but the problem was still there.
It took us weeks to figure out the culprit. The issue was the load balancing feature set up by the previous digital agency. It was working fine on their two load balancing servers. The problem started as we were hosting on one server. As soon as we turned it off, the problem went away. However, the damage was done. We lost a lot of customers as they didn’t trust our system anymore.
It happened eight years ago but I still have nightmares about that issue from time to time.
I'm trying to implement a 'remember me' functionality on my website to allow the users to remain logged in without having to login again.
I do something like this:
System.Web.Security.FormsAuthentication.SetAuthCookie(userName, true);
I've noticed that the 2nd parameter (createPersistentcookie) is not really persistent as it depends on the timeout value set in the config file.
From what I understand:
if createPersistentcookie=false then the user will automatically be logged out if s/he closes the browser or after x minutes of activity (x being specified in the config file).
if createPersistentcookie=true then the user will NOT be logged out if s/he closes the browser but will still be logged out after x minutes of activity (x being specified in the config file).
Note that in both cases 'x' has the same value and comes from the config file.
What I would like to do is:
-if the visitor doesn't want to stay logged in all the time I would like him to be automatically logged out after 20mn of inactivity of if he closes the browser. To do this I would set createPersistentcookie to false and the timeout value to 20mn.
-if the visitor DOES want to stay logged in all the time I would like him to be automatically logged out only after 7 days of inactivity. Closing the browser won't log him out. To do this I would set createPersistentcookie to true and the timeout value to 7 days.
You see the problem: in one case the timeout is set to 20mn and in the other case the timeout is set to 7 days but in the config file I can only specify 1 value.
Any suggestions?
The title and first part of the question is in conflict with what you ultimately state as your goal.
To address the first part:
You need to construct the ticket yourself and explicitly set the expiration on the COOKIE the same as the timeout and then set the cookie.
This is easier said than done, because MS in it's infinite wisdom does not expose the timeout property of the formsauthentication element. There is a pretty simple workaround.
See the code in this answer to see what is required to create persistent tickets.
In conclusion: You are not doing anything wrong, the createPersistentCookie functionality is broken but can be worked around.
To address your stated goal:
There is really no clean way to do this using FormsAuthentication. Any attempt to do so would result in brittle hacks around a well designed, secure system that is dead simple to implement and leverage. If you attempt this with forms auth you will find yourself chasing ghosts.
good luck.
You can set expiration time programmicaly. Authentication cookie can be decrypted to FormsAuthenticationTicket using FormsAuthentication.Decrypt(). Then you can re-create the ticket by setting expiration time.
createPersistentcookie means whether cookie will be destroyed when user closes browser or not. You can specify very long lifetime and persistent cookie for remembering the user
My team is working on a crappy old website and most of the pages are still ASP classic. However, we've recently migrated to forms authentication using ASP.NET and wildcard mapping. Everything works surprisingly well except for one thing: logged in users are timing out too quickly. After looking in the logs it appears people are timing out exactly after 20 minutes (which is the specified timeout due to inactivity).
So, our hypothesis is that the ASP classic pages are not tripping whatever mechanism in the forms authentication framework that resets the inactivity timer. I've googled around and even read the wildcard mapping post by the Great Gu but still can't find anyone else who is having this problem. So, 1) Have you ever seen this problem? and 2) What's the best workaround? (other than manually placing a hidden frame in every janky ASP page that loads a dumb .NET page in the background)
Update: slidingExpiration is set to true
Also: We can't use perpetual sessions because we need the application to time out after 20 minutes of inactivity. Also, this terrible site was written so that the interface is usually stored in the page. There's no simple piece of interface code I could slip the JavaScript into. We tried to put some js into an include file that was called by about 80% of our pages but it's caused some esoteric problems with file download buffers so we may have to try a different tack. Thanks.
Create a perpetual session.
Essentially you end up emitting some JavaScript and an image tag in your master page or navigation users controls (whatever you're using for consistent navigation). This JavaScript on some interval changes the source of the image tag to an http handler endpoint (some .aspx, .ashx) which returns a 1x1 pix clear gif as a response for the image. The constant request ensures that idle pages will keep the session alive.
As long as a browser window is open to your page your ASP.NET session will never time out.
Often the JavaScript will tack on a random number to the request so that the browser doesn't cache the request.
A decent walkthrough is available here.
I am assuming that you have manually created the cookie, in which case your timeout value in code is probably overriding your timeout value in the configuration.
First, if possible (which it probably isn't) don't create the cookie manually, it will save you from not only this headache but dozens of others.
If you must manually create the cookie, make sure that the timeout you are using is actually reading the timeout value that you have set in the configuration file and that sliding expiration is set to true (which you have said it was).
That said, we still have ocassional strange timeout problems when the cookies are manually created. Where I work we implemented a solution which allowed the cookies to be created automatically and timeouts were no longer a problem; however, it did create other issues and we were forced to switch back.