We use FormAuthentication to manage logins and I have a case where a customer complains where he can login from one computer but to from another.
I can see in my logs that his authentican is successfull but he gets bumped back to the login page. I can reproduce the symptons by disabling cookies so I asked the customer to test if cookies are enabled on http://www.tempesttech.com/cookies/cookietest1.asp, but this came out positive.
What have I missed? Is there any antivirus/security software that can mess up (ASP.NET) cookies?
The user is using IE7 and claims to have F-secure installed.
First ask from your customer to try to login using some other browser like google chrome.
If with other browser works, then ask from your customer to clear the cookies on his browser, if he can clear only your page cookies, then you must be check if you using too much cookies, or too big ones, and create a diferent shecma.
You maybe have set to store/cache the roles on cookie - this make cookie too big ones, and big cookies create problems.
Related
We have an application which has two user types. One of them is an administrator and the other one is a client. We are using AspNet identity to authenticate the user and issue a cookie.
However, there is a scenario where the administrator and the user share the same browser. When the client logs in, the cookie gets overridden and when coming back to the administrator pages we lose authentication. The same happens the other way around (client is logged in first, then admin).
Is there a way to support multiple authenticated users at the same time on the same browser?
Greetings.
Luis.
No, the browser has no understanding of any users. You set cookies and the browser sends back those cookies. The application then receives and checks those cookies to figure out the current user on the next request;
There's no way for the browser to know what cookies it should send back and there's no way for your server to know what the right user is other than reading those cookies. Why do you want 2 different user types sharing the same exact browser window anyway? That defeats the entire security model.
If 2 people must share the same device, then most browsers today support private windows or separate 'profiles' so you can have completely separate preferences and sessions without sharing any data. Here's a link to Chrome's profiles feature: https://support.google.com/chrome/answer/2364824
I am fairly new with developing in ASP.Net and I've searched high and low for a resolution to this, to no avail. I am using Forms Authentication to authenticate users and when I login with user A, I abandon the current session, generate a new session cookie/id and redirect from to my content page and everything works as planned. However, when I open a new browser window and navigate to the login screen, thus starting a new session, the authentication cookie for user A is automatically passed to this session and is part of the request cookies collection. Even worse, when I actually log in as user B and get a new authentication cookie then refresh the browser window for session A, it now has the authentication cookie of user B.
I have no idea why this is happening. I thought the browser (IE9) was caching the authentication cookie because the response-header collection is set to cache-control "private" even though I specifically set the Response.Cache.SetCacheability("no-cache") in my code-behind for all pages. Then I was thinking it could be a threading issue.
Any insight into why this is happening is greatly appreciated, Thanks.
Try different Browsers like Chrome and IE. Because browser share same cookie and temp file even opened in new windows. Above scenario will occur if you try with gmail.com or live.com.
Check your web.config files for session settings.
Check out the following link:
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.enablecrossappredirects.aspx
I'm afraid I cannot get through this problem on my own. It is weird that this issue seems to be unique for my installation.
On my WordPress-based website users are having trouble with the login, especially when using their mobile phones to authenticate: they are being logged out (even when checking "Remember me") and will have to re-enter their credentials (after which they're logged out again). From what I figured, it is most likely the fact that their respective mobile Internet Service Providers dynamically assign new IP addresses to their devices all the time, causing the authentication to fail.
When I'm using my desktop to login, everything will work just fine. However, say, I have successfully logged in to the site with Google Chrome, and I open an instance of Mozilla Firefox (or any other browser) to log in simultaneously, Chrome's user "session" will be shut down immediately (I know that because an asynchronous script is requesting whether or not the user is logged in and it prompts me to log in once I sign in using the other browser). Therefore I believe that the whole WordPress authentication has got something to do with the user agent, too.
Albeit I highly appreciate the extra amount of security provided by automatically voiding a running session when accessing the site from a different IP or browser, my users do not. Even for myself it is remarkably cumbersome, using three different machines plus tablet and phone to access the site from any possible place (eventually I stopped bothering to log in and just waited to get home).
Since WordPress authentication uses cookies, I looked into how these are generated. The wp_generate_auth_cookie() method uses the user name, parts of their hashed password, the expiration time and a salt (a constant salt defined in wp-config.php), but neither does it use the IP address nor the user agent.
I literally searched the whole WordPress folder for "user agent" or "IP address" occurrences but there is no login-related script containing the terms (merely a handful of plugins that don't affect the user session at all).
That puzzles me. How does WordPress even realize that I am logged in with a different browser / computer if it doesn't store that data with the authentication cookie? And where does the check happen that logs me and my users out?
Do you have any further ideas on how to troubleshoot the issue?
Thank you very much in advance!!
Harti
Cookies are stored by browsers and different browsers on the same machine don't share that storage. Thus when you login with Chrome, WP sends a login cookie to Chrome, starting a new session. When you then access the site with Firefox, FF doesn't have a login cookie so WP prompts you to login and then sends a login cookie to FF, also starting a new session. The next time you access the site with Chrome, it gets Chrome's login cookie, which doesn't match the last one sent out that's associated with your username, so everything starts all over again.
This doesn't directly explain the problem with mobile devices; it sounds like for some reason they aren't storing the cookies properly.
I need to ask:
I use Forms Authentication in my ASP.NET application.
but when I publish the web after the user login, if he didn't signout he just close the browser and after that he browse it again it will redirect him to default page.
How can I enforce redirecting him to the login page even if he didn't sign out?
You should see the documentation for forms authentication specified here. You can force the cookies to expire whenever you want setting the timeout attribute. Also, you could not use cookies at all by using the cookieless attribute. There are other optional attributes that could be useful for you, that might not be related to your question as well.
It will depend on whether or not their asp.net session id cookie still exists, or whether they have cookies enabled at all. To enforce redirecting to the login page you will need to find out how to make the cookies be lost when the browser is closed. In my experience this is the default behaviour anyway.
I will suggest you to check asp.net Membership,Profile and Role provider for specifically manage user Logins, Passwords and their profile.
This is one of the good articles from Scott Gu, you should bookmark when you want to work with Membership and Profiles.
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.