I'm experiencing some trouble with an ASP.NET MVC 5 application that has been buggering me for a few days.
The application is using Forms Authentication to control whether a user is Authenticated, and Session to keep track of the user's data.
A few of our users are unable to log in, and I have been able to recreate the problem on a collegue's device. We don't know much about the devices with the problems, except that they all seem to be running iOS. I can't seem to nail down the pattern, though, as one user who reported the problem was running 11.2.5, which I am also running myself without trouble. The collegue's device is running 11.3 beta, but I haven't yet heard of any other users with this version, so I'm unable to pin point that as the problem - which also seems unlikely when one of the users with the problem is running 11.2.5.
The issue happens after the users try logging in. After a successful login, the user is redirected to a specific section of the site, where Authentication is required. Requesting any page in this section redirects you to the login page if you are not Authenticated.
Some of the resources that are requested on this page expect to retrieve some data from Session. For some reason, the Session cookie may sometimes be missing, and other times the Authorization cookie is missing.
For the past few days while I have been hunting this, my collegue's device happened to leave out the Session cookie when requesting our Cachemanifest, in which we expect to be able to generate a specific part based on some data from the Session. This caused the generation to fail, which in turn caused the request to fail.
After changing the generation logic to work around this, with a different solution if the Session cookie is missing, my collegue's device has changed its approach; Now, it includes the Session cookie when requesting this resource, but instead leaves out the Authorization cookie in a subsequent request to a different resource, which is still in the section that requires Authorization. This resource happens to be mentioned in the Cachemanifest, and because this next request does not include the Authorizaiton cookie, that request is redirected to the login page, which is interpreted by the Cachemanifest as an error.
As far as I recall, I haven't changed anything else, so I'm really at a loss as to why this devices' behaviour has changed.
Both of these cookies are included in other requests before and after the failing request, and there doesn't seem to be a pattern between what requests is chooses to leave these two cookies out of, or which cookies to leave out. The only thing that is consistent is that the behaviour doesn't change when retrying after clearing the browser data (only after I made my change, which I still don't see how could result in this behaviour).
The site is forcing HTTPS, so I tried setting the Session cookie to Secure, but that didn't seem to make a difference.
I still need to try setting the Authorization cookie to Secure, but I'm not very optimistic there. I also still need to try reverting my changes to see if the old behaviour reappears.
Has anybody experienced similar problems before, or does anybody have any further suggestions? I know I might be a bit sparse on the details, I'd be happy to provide any further details if I'm able.
Thank you in advance :)
Related
I've put a custom authorize attribute into my MVC application, which does
if (!this.Roles.Split(',').Any(filterContext.HttpContext.User.IsInRole))
and if true it will redirect you to unauthorised.
I put this attribute on my controller at controller level.
One action works fine, and in one action I get unauthorised.
Is there some bug or problem in the role system? I've read that logging out and in can force some cache to refresh or something, however the system I am using authenticates with your domain credentials so there is no way to log out.
I've tried restarting the app pool and deleting my session cookie but nothing has worked.
Has anyone experienced this specific issue before or has some guidance on perhaps flushing any caching related to it (assuming it's a caching issue)?
ETA: Another user on the system gave himself the role required for the controller and both actions work fine for him. So perhaps my user is somehow bugged. This is on UAT so slightly more difficult to debug than running on my local machine (which works fine).
ETA2: I'm pretty sure this is a caching issue, as going to the URL with ?1=1 in the query string, it works. I'm unable to invalidate the cache though. This may be a problem in the future when assigning roles to people.
First, we need more code before we could possibly give you any definitive answers. However:
Caching could be a problem. If you're using anything like OutputCache, you should ensure that you're using VaryByCustom and somehow including the user's id or other identifying token in the custom string returned.
If you're adding roles to users, you must either log the user out and sign them back in, or otherwise invalidate their authorization. In Identity, for example, you can simply invalidate the security stamp, which will cause the user to be reauthorized, updating things like claims or roles that have changed since they signed in.
ASP.NET MVC2
.NET 3.5
FormsAuthentication
URL: domain.com/myapp
Problem area: Dynamically created PDFs returned as FileContentResult
Everything was working fine until IE8. With IE8, when the user opens a PDF and then returns to the app, he has lost his authentication. I added an expiry on the forms auth cookie and the problem appeared to be resolved. However, I later discovered that the same problem occurs in the parent app. With the persistent cookie, when the user continues in my app (domain.com/myapp), everything is fine, but when he returns to the parent app (domain.com) window he has lost his authentication. The parent app uses a proprietary authentication and authorization architecture that relies on session state.
So my understanding of the problem is that the FileSystemResult does not carry any session information and thus the session is lost. I understand that by adding an expiration to the cookie, the cookie is persisted and that enables the authorization to persist in my app, even when docs were opened.
I don't quite understand why adding an expiry to my cookie transferred the problem to the parent app. So, I was wrong, this has been happening all along in the parent. Interestingly, when I hooked up Fiddler to watch what was going on, the problem went away.
Do you have suggestions to resolve this? I can't think of anything other than something really ugly like writing the file to the server and returning a page with a link to open the file directly.
Based on this question I think I am hosed.
There's some changes to the way IE8 handles persistance cookies which could be the route of your problems. There's an interesting post here that describes a possible solution.
The solution took us quite a while to find online believe it or not,
and when we found it we wanted to kick ourselves for not finding it
sooner. It all stems from the domain attribute of the forms
authentication settings within the web.config file of your
application. We typically left that attribute blank in our apps to
make it easier to develop. Further, none of the other browsers above
cared about that setting and functioned just fine. However, that
changed in IE8 and now that attribute is required.
While the problem happens almost always to users in Internet Explorer, it has happened in Firefox and Chrome a few times as well.
The issue is in which users attempt to login and either get a 422 error or are simply re-directed back to the login screen. We have a wildcard cookie, but we recently switched it to targeting www (about 3 months ago) and the previous cookie was set to expire at the end of the session.
We also recently switched to Devise authentication from Restful_athentication in hopes that it would fix the issue, but it doesn't seem to be helping. However, I don't see how these are related as they don't really manage the cookies, Rails does, they just put things in the cookies. I thought maybe the issue was that restful-auth was putting something in that got corrupt under weird conditions, but that apparently was not the case at all
UPDATE
After we switched to Devise, users encountering this problem no longer got a 422 error, but now the page just refreshes and nothing happens. I should also mention that when they enter in their email to retrieve their password (as they think they're entering their password in wrong), it returns that the email is not found in the system.
When they clear their cookies, particularly in IE, they still run into the same problem. I've walked a few users through searching for the individual cookies in Firefox and that has solved the problem. However, simply just going to clear cookies the normal way didn't work. The issue was mainly effecting IE7 users, but seems to be all across the map, with users reporting the issue on Chrome, IE8, Firefox, Safari and Safari for the Ipad.
Also, here's a link to the code for the session_store.rb here and here the host is set in def ensure_domain, which is here
UPDATE 2
I just made a very minor adjustment and it changed it so it always sends a host. I tried logging in every different way on every browser and didn't run into any issues. I'm hoping this helps
UPDATE 3 (LAST UPDATE)
We tried a combination of a few different things, so while I'm not exactly sure what fixed it, my best guess is removing the cache from 4 days to when the session ends/browser closes. While I'm not thrilled about this as I personally dislike having to login every time, I'd rather have the problem fixed (and this issue didn't start occurring until after we changed the cache length to 4 days.)
Sending a host was a mistake and actually made the problem worse for everyone as no one was able to login. Another strange thing was that when looking at the cookies created there were two Session ID cookies, which I would guess were causing the conflict, particularly with IE7. Some users are having to clear their cookies to get logged in still, but at least that seems to be working most of the time.
To any having a similar issue, sorry I couldn't be of more help!
If an HTTPS cookie is set to "secure", it WILL NOT be sent out on HTTP protocal. It is as if it doesn't exist. This sounds like what is likely "stripping out" your cookie.
Cookie basics: If something is worth protecting via HTTPS and you need to track that info afterward (ie, authentication token), it is best to keep it in the HTTPS cookie and only access it from HTTPS.
This is a cookie security issue, and is better discussed at: Secure cookies and mixed https/http site usage
I'm trying to use forms.signout but sometimes it does not log out the user and he still can navegates through the website.
How can I resolve this? I also configured web.config forms authentication, but it's still not working.
I'm using FormsAuthentication to autenticate an user passing he's login.
Thanks!!
I don't know what the cause is but a few things you might consider/try
are they actually able to still visit pages generated by the server or are they just going back to locally cached versions? What happens when they cause a postback that has code to check if they are authenticated does that work or does it fail? I think the later meaning they are signed out but viewing cached versions of the logged in page in which case you want to instruct the client not to cache the pages using for instances:
Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
You can try manually setting the cookie to be expired but this is a hack
FormsAuthentication.SignOut();
Context.Response.Cookies.Item(FormsAuthentication.FormsCookieName).Expires = Date.Now;
Response.Redirect("~/Somewhere.aspx");
Does the user have the domain (or a parent domain) in their trusted sites or intranet sites? I've run into some issues recently where a user is authenticated, but anonymous under circumstances where this is true. In my case it could also be that a parent site was, at one time, configured to allow windows integrated authentication. I've removed since removed that, but it didn't seem to help the problem. I haven't yet restarted IIS to see if this would have an effect. I've resorted to checking both that the user is authenticated and non-anonymous to ensure that the proper parts of the view are rendered. This is actually more accurate even though my login code should prevent having an anonymous login.
How do I "log out" a user? Know that this is not officially supported, but I need a quick and dirty hack. Saw somewhere I just throw out a 401 access denied - but anyone know the syntax
http://httpd.apache.org/docs/1.3/howto/auth.html#basicfaq
Since browsers first started
implementing basic authentication,
website administrators have wanted to
know how to let the user log out.
Since the browser caches the username
and password with the authentication
realm, as described earlier in this
tutorial, this is not a function of
the server configuration, but is a
question of getting the browser to
forget the credential information, so
that the next time the resource is
requested, the username and password
must be supplied again. There are
numerous situations in which this is
desirable, such as when using a
browser in a public location, and not
wishing to leave the browser logged
in, so that the next person can get
into your bank account.
However, although this is perhaps the
most frequently asked question about
basic authentication, thus far none of
the major browser manufacturers have
seen this as being a desirable feature
to put into their products.
Consequently, the answer to this
question is, you can't. Sorry.
As you can see from the full explanation above, you can't.
The only workaround is to invalidate the user session and cause the browser to request username and password again.
Additionally, you can try (I haven't tried it yet) to empty the WWW-Authenticate HTTP header.