I'm working on a SAAS application that uses subdomains. For some reason users with long names who are part of companies with long subdomains aren't able to access the app after logging in until the browser does a hard refresh. Until the refresh, they end up in a redirect loop. This seems to be isolated to Chrome and Firefox only. It seems like its an issue with cookie caching but I can't be sure.
Has anyone seen this issue before?
After a little more digging I found this only happens when SSL is enabled. Over http there are no issues.
Resolved this by stripping the cookie down to as small as possible.
Turns out cookies over roughly 1kb require multiple packets to transfer. So, my guess is that only one packet can make it through our load balancer with SSL going? I can't confirm the exact reason behind the issue but it seems to be resolved.
The Forms Auth cookie gets pretty large on its own (due to encryption / validation overhead), so it only takes a few properties to get over 1kb.
Related
I have an app on foo.com which has an iframe that loads another application from bar.com. The bar.com webapp relies on maintaining session with a session cookie which it issues on the response to the first request to bar.com. ITP at some point decides it's no longer going to send the bar.com session cookie on requests to bar.com in that iframe... and the bar.com webapp goes fubar.
The arrangement works fine if I disable "prevent cross-site tracking" in Safari. And it works fine in any other browser.
I think ITP is deciding that the cookie being loaded in the iframe is a third-party context. And although the user directly interacts with the webapp presented in the iframe (clicks, drags, etc), ITP does not register that as first-party interaction.
That's all mighty unfortunate and I'm not finding a way to work around it. Any suggestions? There are no ads or ad-tracking involved here.
If you feel there is a bug in the way ITP is handling your web app, you should file a Radar so we can investigate.
As it stands, unless your app is embedded on a number of other sites, it’s unlikely it would have been flagged as a tracker.
Can you give details about your application, and where it might be used so we can investigate?
In my web application, there's a link sending a redirect (302 to another GET request) together with some cookies. It works fine, except when used from MS Access by a guy I remotely work with. I know close to nothing about what and how he does, I only know that he uses Application.FollowHyperlink.
The link from Access should be opened in a browser, but after the redirect, there seem to be no cookies there. When used normally, there's no problem. Can it be like that Access handles the link itself and sends the redirected URL to the browser?
Maybe a stupid question, but I have no idea about Access (never ever seen it) and I'm sitting only on the server side. There's nothing interesting in the server logs...
The problem was MS doing some complicated things like here instead of simply opening an URL in a browser. Access accesses the page, sees the new URL, and gets and eats all cookies. While digesting the cookies, it points the browser to the new URL. The browser has no cookies and no access to anything.
This summarizes it nicely:
This problem occurs because of missing session cookies for the Web server. This problem is specific to certain Web-server designs that depend on cookie information instead of authentication information or that depend on cookie information plus authentication information.
To me it sounds like "works with MS only", though I'm not exactly sure what "authentication" they mean.
I've tried searching and found questions that were close to this, but I could not find one answer that actually details this exact issue.
What (if anything) prevents a user from sniffing a network, getting all the asp.net forms authentication cookies a site is sending to me (or sniff the cookies I'm sendint to the server), setting those cookies in their own browser and viewing the site as the authenticated user?
Inherently, I don't think there's any native mechanism to prevent the scenario you describe. I think that's one reason MS recommends that Forms Authentication cookies have a very limited lifespan (set a short Expiration time), and be communicated across SSL.
SSL is the only thing that can prevent it.
We have a web application running on ASP.NET 3.5. It is viewed by the world as one URL but in reality there are multiple IIS boxes hosting the application controlled by a load balancer.
My problem is that it is a sensitive application with strict security controls around it, and that post authentication if you open another browser to the same application and log in as someone else, the second login overwrites the first logins' session id value in the cookie, and then the first window crashes.
Any idea how I can get around this?
The session ID is placed in the cookie. If another browser window is opened and starts a second session the ID in the cookie will be replaced.
Also, logins should not be controlled via the session cookie. There is a Forms Authentication cookie for that purpose which is more secure as I recall.
Most web applications only allow one session per PC. Try logging into Yahoo Mail, Amazon or Ebay twice on the same machine and you will find the same problem. So ASP.NET is pretty much designed around the idea that there is one login per PC. Although, if you have multiple browsers installed on a machine, you can generally log into apps more than once because each browser keeps its own cookie collection.
edit: You might want to try cookieless sessions, in theory they might allow multiple sessions per PC, although I haven't tried it. But cookieless sessions come with plenty of problems and limitations of their own.
In short, there may be some hacky way to do what you want to do, but it will probably be fiddly and cause other problems elsewhere, because what you are asking for goes against the grain of ASP.NET's core design.
I have an asp .net webforms app that uses forms authentication. For a small number of users we have a problem where they log in, they navigate to a couple of pages and then they are asked to log in again. Once logged in for a second time they seem to be able to stay logged in as expected. They shouldn't be asked to login the second time.
This is a single server, no web farms, nothing tricky.
This only happens to a few users, but it does seem to be all users from the same building. I am unable to replicate this and at this point might even start to deny that t was happening if one of our trainers hadn't watched it happen to a couple of customers.
Has anyone else seen anything like this?
I am also seeing a lot of "Membership credential verification failed." errors in the event log. This may be related, but all the googling I've done seems to point to web farms and the like, not a single server.
UPDATE
There is no proxy server, the IIS server and the browser (IE8) are both on the same machine.
The AV software installed is Symantec Endpoint, on one machine, on the other the user didn't have any AV at all (AV Fail!).
The browser is IE 8 with no frills, not a single addin that didn't come with the default installation.
Both session and user login time-outs are set to 30 mins and the problem happens within 1 min of the user logging on.
Logging shows the user to only have one IP address.
I have tried the sessionMode in all it's variations, this doesn't seem to make any difference.
Something has to be causing ASP.NET to think these users have new sessions or their authentication cookie is getting invalidated. Here a a few things I can think to check:
Are the users accessing the site through a proxy server? One of our customers has a proxy that will sometimes close all open connections causing ASP.NET to see the session as new.
Could an overly agressive anti-virus, anti-spyware product be "eating" the session authentication cookie?
Do they have a cookie manager browser add-in that is causing the authentication cookie to disappear or change?
Sounds basic but I've seen this happen because of site timeouts being set too short. If the user sits on the page for longer than the timeout, they will be forced to logon again. And this could be specific to a page when that page presents a large amount of data that takes a while for them to go through.
One other thing I just thought of, have you allowed multiple worker processes for the ASP.NET process (aka web gardens)? If so, the same constraints as with a web farm would apply for authentication.
Crack open Fiddler from the problem user's PC and see what's getting passed in the headers. My bet is on a proxy server and or networking issue.
Are the users possibly coming from a dynamic ip address? I've seen problems where the users sessions get messed up because the IP address that they're accessing the site from changes for some reason.
Are the people this is happening using a browser that's somehow different (different browser, different version, different extensions)? That could be a clue.
In general, when the problem is somewhat reproducible or at least predictable, I use Http Fiddler. Install it on a client machine, turn it on, and start browsing (this works via a system proxy - so it'll work for firefox, IE and any other proxy-supporting browsers alike). Fiddler will record all http traffic between client and server, and you can then peruse such a session later on to find any oddities.
It's a long shot, but one thing I've seen happen occasionally that can lead to these sorts of unpredictable errors is scripting parallelization issues: sometimes buttons + links have onclick handlers which cause a post-back. If you have several such handlers that fire on the same event - in particular when the default event still fires additionally to your custom onclick or whatnot - you may be causing several postbacks when it appears to be just a single postback. That can cause all kinds of unpredictable weirdness as it's not entirely clear which request ends up "winning" - and some odd errors may cause a session to terminate. Since this behaviour is very browser + network latency sensitive, it seems quite unpredictable when it occurs.
Delete the cookie on the client PC's that are playing up
ASP.NET Forms Authentication can redirect users to the login page if they do not have the credentials to access a specific page. It does this so that users who may have more than one login are given the opportunity to login with another account which may have the appropriate access. Basic question I know, but are the users using the same credentials the second time they log in?
Its possible that you have don't have specifically specified asp.net to use cookie based session but are allowing either cookie or cookieless sessions.
In the later case the session id is embedded in the Url. The type of issues you are experiences might be explained by that. Basically depending on how you define your links, some of them would not get the session id, so the user would get a new session when using those links - or maybe during a redirect. That could explain why at specific parts of your site the users loose their session.
If you have the mixed mode enabled, try setting it to only cookieless and go through your site.
Update: Based on the extra info posted there is surely more info needed for it. Some extra things to check:
Are you using subdomains, if that's the case the cookie might not be configured to allow that and that doesn't fail in all environments.
If you are using in-process session, make sure there isn't a bug in the application causing it to restart the process
Maybe what's causing it to ask for login again is an authorization check, and you have an issue on some roles related code
Is it possible that the user is just opening a separate window? ;)
To rule out the possibility of the browser or a browser addon messing things up, have you checked their User Agent strings? If they are randomly distributed it might not cause the problem, but if they're all the same, this might be a hint too.