This certainly is a strange one...
I have an ASP.net 4.0, C# website that has a login page using FormsAuthentication to handle user access. There's also code throughout the site that boots the user back to the login page whenever a session times out or something else that requires them to login again happens. This is all really basic stuff that I've done about a dozen times before.
I know this whole process is working, because I've been able to login to the site running through VS2010 on EVERY browser I tried. It also works perfectly fine when it's sitting on the development server using Chrome, Firefox, Safari (Mac), and two Cellphone browsers. The only thing I've had a problem with is Internet Explorer.
Now, this one is a bit hard to debug considering it works in IE locally but not on the server. The fact that it also works in other browsers on the server is also sort of ruling out a server configuration issue.
What I did to try and figure out where it could be going wrong was add a query string to my FormsAuthentication.RedirectToLogin("WhateverPage=WhateverSectionOfCode"); line to try and solve this. The problem is that when I run the site in IE, it never appends that Query String, which leads me to believe that it never hits any of those "RedirectToLogin" lines.
I know it authenticates, because the code that updates the Last Login timestamp in the database only fires if the user is authenticated. It looks as if the "RedirectFromLogin" line does go out and find the proper entry in the web.config...and it might actually be redirecting me, but even if it does, it always bounces me back to the login screen.
I've been through all of the really basic ID-10T errors (heh) that could possibly be causing this: Heightened security settings, disabled cookies, etc., but I'm getting the same results on multiple machines.
I'm really sort of stumped as to what to check for next. I've already had two other sets of eyes on the code, but they couldn't come up with any reason as to why this was happening. If anyone has any suggestions as to what could be happening, I'd love to hear them.
Thanks!
i think it is something about cookies..
did you set the domain attribute in the web.config?
<authentication mode="Forms">
<forms loginUrl="~/login.aspx" name="cookiename" domain="domain.com" cookieless="UseCookies" slidingExpiration="true" timeout="60"/>
</authentication>
forms Element for authentication (ASP.NET Settings Schema)
I know this ticket is a bit old, but apparently IE can't set forms authentication on a domain with an underscore in the name. So if the issue appeared on a development server that was, say Dev_XP, then IE won't be able to set an authentication cookie.
That's what happened with me. Here's the link: http://orwin.ca/2012/02/09/formsauthentication-setauthcookie-not-working-in-ie-but-works-in-other-browsers/
This is the KB artical that outlines the issue http://support.microsoft.com/kb/316112
I'm having same issue, but with all other browsers except Chrome.
The strange thing is that when all these browser are tried locally (in same computer where service is running), everything works well.
When I'm connecting remotely - only Chrome works. Firefox and IE are redirecting me back to login page every time, though user is authenticated - same as yours, in database logon timestamp updated.
But I have also developer server, located in the other network, connection to this network takes less time, and here are all three browsers works OK too.
So I think that the problem is in IIS settings, which might be different on real vs developer server, or it might be a problem in Redirect and thread, which creates session. I found some interesting topic about this. It's about ASP WebForms though. See my question on stakoverflow. And please, let me know if you solve this problem!
Related
I have an old ASP.NET intranet application where the forms login page is demonstrating unusual behavior. If any version of IE has a cleared history (history, not cookies) when they submit to log in the page executes a blank post back and remains on the login page.
If they refresh the page or had been redirected to the login page from trying to directly access another page then they are logged in without trouble.
I have published additional copies of this application to the same IIS server and they initially did not exhibit this behavior however after some number of hours they began acting the same way. Republishing to the same instance does not "fix" the issue like publishing to a new site does and neither does removing the old application and then publishing to the same name.
I'm not sure where to go from here so any help would be appreciated.
To me these are the key observations I have made:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
I replaced the button click code with a Response.Redirect to Google. When the button is not behaving correctly this redirect was not being fired. This indicates to me that the button code is not being executed. After the page is reloaded/refreshed it redirects properly since the button code is now firing.
When the same code is published to this IIS server under a different name it does not exhibit this defect for a number of hours. What could happen after a few hours to cause this behavioral change? Republishing to the same IIS site does not fix the issue for a few hours like publishing to a new IIS site does.
I have removed the button code from this posting because it is in my opinion a red herring as the code doesn't appear to be being executed at all.
This is what the cookies looked like in the network tools when the site is working
The difference here from when the site is working to when it is not working is that the Form1 key is marked as Sent and not Received.
Something new I have also noticed is that when the site is not working the favicon shows as (aborted). I now believe that the request is being completely aborted because I have overriden the page's OnInit and the code I entered is not being executed when the site is not working.
Today my work opened a ticket with Microsoft to help get this problem resolved and they have said it was a "head scratcher."
I disagree with Nick's thought that there is a problem in the code because of your assertion:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
This suggests there is a difference between servers, the way they are configured or the code is deployed that is stopping it from working. As it is a forms authentication problem, I am reminded of the bug that screwed up forms authentication in IE10 - see IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
Are your servers identical? Running the same OS, .NET versions, patches, hotfixes etc?
Microsoft saved the day.
They told us that the older versions of IE will look for the favicon in the root folder in IIS and not the application path regardless of where you're pointing it to look. There we found that the root folder's authentication settings were set to Windows Authentication only. For whatever reason this was causing the forms authentication to be aborted until we added Allow Anonymous to the root folder.
I'm having a strange problem in a Silverlight Business Application that calls an external API. I'm sure it's just one line wrong or something. The API has one call that uses digest authentication and I handle that all myself. My code was working before, but then I began a transition to hosting the backend API and this front-end website on Azure and something must have changed. Now, before the request comes back to my code to handle, the browser is popping up a login dialog of its own. If I cancel out of that dialog, it moves on to my code and authenticates successfully.
It seems as if the browser is handling the request, noticing the 401 status code, and attempting to resolve it itself. But I do register the ClientHttp factory for the http:// prefix as suggested, and the request type that is created is a ClientHttpWebRequest. Like I said, this was all working about a week ago using the same authentication code and everything, so I'm sure it's just going to be some setting. But I'm not sure where that could be and I haven't found anyone else with this problem.
Curiously, when I publish the ASP project to an Azure website, it all looks and acts as expected, but the login doesn't even pop up the dialog. It simply doesn't do anything when I click "login." So that part looks like maybe an unhandled exception is being thrown then it's not telling me about it, but I'm not sure why that would be the case on Azure but not IIS Express.
Basically, I just don't want that dialog coming up. I am inclined to assume that the same problem that's causing that is whatever is making the Azure-hosted version not do anything.
I've done a fair bit of searching and found this question, "How can I supress the browser's authentication dialog?" which seems to be the same issue, but as I stated a few times, this was working just last week. I do have full control of the API and this site, so I could alter some things to make it suppress HTTP statuses and simply return a 200 with details in the content as a substitute, but I'd rather avoid that extra layer of complexity if it really is something simple, as I imagine it is.
After some fiddling, it seems the best way to handle this error is simply to use the WebRequest.Credentials property and populate it, rather than forming my Digest authorization header myself. It isn't exactly what I was going for, but it will do for now. I still don't know why this stopped working in the first place. But what fun is programming if everything goes according to plan?
Our operator has implemented a Round Robin load balancer on our web portal and it seems to be causing some problems I can't get to the bottom of.
I'm able to identify which server we're on and as we navigate around the site we stay on server A. If I leave it for 5 minutes and try another page I'll get pushed to server B, logged out and shown the log in page.
I've got them to make sure the MachineKey in the machine.config is the same on both servers and I've tested locally that the session isn't being used - I can turn the session off completely locally and it still works. I've verified on both servers it is creating an ASPXAUTH cookie on the domain so we should be classed as authenticated on both servers - but keep loosing my authentication every time I change server.
Any ideas on what could be causing the logging out? I'm guessing it's my misunderstanding about how ASPXAUTH works.
Sessions are handled separately from Forms Authentication. There is a good explanation of this here.
The most common reason for Forms Authentication failures on load-balanced environments is lack of synchronization of the MachineKey element. You've stated that you've got the server operators to ensure that the MachineKey is synchronized, but have you verified this yourself in some way? Is this the case on ALL the web servers? From previous dealings with a couple of commercial web hosts, I've found that it is (unfortunately) difficult to take their assurances at face value.
Another thing to check is if the FormsAuthentication configuration (timeout, path, name, etc.) is the same on all of the hosts.
Are the patch levels the same on all of the hosts? You might want to see if the compatibility switch mentioned here is applicable in your situation.
Assuming that the hosting setup is correct, maybe you have initialization code on the page that logs you out if some condition is not fulfilled?
Try to take a look at the server logs and trace the sequence of HTTP requests involved during a failed page request. That might produce a clue.
Edit: This guide to troubleshooting Forms Authentication problems is detailed, and quite helpful: Troubleshooting Forms Authentication
Check for any other application functionality which depends on cookies. The web server on Server B will not recognize cookies that came from Server A. If any part of your authentication depends on cookies being populated, then that could cause your problem.
You have probably already ensured that the domain used for cookies is the same on all of the load balanced servers, but I thought I'd mention that. If the domains aren't compatible, then the browser will simply not send cookies to the server.
I'm having an interesting problem with FormsAuthentication on a client project I'm trying to assist with. Here's the problem:
The domain of web app was changed from .companyA.com to .companyB.com and I set up an IIS redirect to send anyone attempting to go to .companyA.com to .companyB.com. That works just fine.
Now I can't log in to the site. I did some digging and found out that there are authCookies being defined in the web.config, so I changed the the authCookie domains to match .companyB.com. I was still not able to log in.
I did some more digging and found that there was a SQL Reporting server set up. I changed the domain in the config files of the reporting server to match .companyB.com. Still can't log in.
For general purpose troubleshooting of this type of issue is there anywhere else I could look? I've just been put on this as a firefight so I've limited domain knowledge and can't open the solution in VS because the only VS they have available is too old for the solution.
EDIT: OK, after further digging, I found out that the user isn't authenticating wasn't the main issue. There was a problem with connecting to the reporting service DB and the exception was being swallowed up. Thankfully it showed up in the event viewer. Unfortunately this still leaves me with problems, I can't figure out why SQL won't authenticate me anymore and how changing domain names could possibly lead to that.
Debugging is really simple. Just get any http debugger (Fiddler will do) and run your application. You will see a list of requests. Just pay attention to the response which sets the auth cookie and then what happens in consecutive requests.
You will probably see that the cookie is set but is missing futher on. This could be because the cookie is issued for domain A (you will see the cookie's domain in the debugger) and the browser is not delivering it to the domain B (which the browser is supposed to do; it will never carry cookies to other domains).
Anyway, an http debugger will be a great help here.
We are rolling out a site for a client using IIS tomorrow.
I am to take the site down to the general public (Sorry, we are updating message) and allow the client to test over the weekend after we perform the upgrade.
If it is successful, I open it to everbody - if not, I rollback.
What is the easiest way to put a "We're not open" sign for the general public, but leave the rest open to testers?
Redirect via IIS. Create a new website in IIS and put your "Sorry updating" message in the Default.aspx. Then switch ports between the real site (will go from 80, to something else (6666)) and the 'maintenance' site (set on 80).
Then tell your testers to go to yoursite.com:6666.
Then switch the real site back to 80 after taking down the 'maintenance' site.
I thought it would be worthwhile to mention ASP.NET 2.0+'s "app offline" feature. (Yes, I realize the questioner wants to leave the app up for testing, but I'm writing this for later readers who might come here with different needs).
If you really want to take the application offline for everyone (for instance to do server maintenance) there is a very simple option. All you have to do in ASP.NET 2.0 and higher is put a file with this name:
app_offline.htm
...in the root directory of your ASP.NET application. Put an appropriate "sorry come back later" message in there. That's it. The ASP.NET runtime does the rest.
Details on Scott Guthrie's blog.
Require that testers login. You can even hide the login page so that you need a direct link to even see it. Then, for all people not logged in, redirect to the page that displays your message.
Fire up another "site" in IIS which will catch your host-header for your primary site. Use either a custom 307/503/404 page that has "we're down for maintainance" or use some sort of URL-rewrite to redirect people to your single static file.
switch host-header-binding on your real site to something else, like dev.domain.com or testing.domain.com that your developers use.
Or, block by IP, and have your custom "Not authorized" page tell visitors that your down to maintainance.
You have several options.
Some methods that I've used before:
Windows authentication and/or separate subdomains for client to test.
Disable anonymous website access in IIS and give your client a username/password combo to test the website.
Disable default document in IIS and give your client an absolute URL to the main index file.
We tend to have a log in page and an include file across all pages in the site (usually the DB Connection as it's included in all files) that checks for a valid logged in session. If you've not logged in you get a message saying the site's down for maintainance