2

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:

  1. 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.
  2. 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.
  3. 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 enter image description here

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."

Howard Tucker
  • 438
  • 9
  • 18
  • Are stepping through the code to make sure some internal error isn't occurring? – Mike Cheel Aug 18 '14 at 15:04
  • 1
    Without seeing the code, it is really difficult to know what the cause would be. There are several things that could be going on to cause this, and they are most likely located in the application code itself rather than the IIS configuration. The first thing I would start looking for is improper error handling, User and Application Session based storage, and other things that have to do with the user or application context. – Nick Zimmerman Aug 18 '14 at 15:05
  • That's what I was getting at Nick – Mike Cheel Aug 18 '14 at 15:06
  • I have edited in the code. This code has worked for years until recently so I did not think it would be a problem with the code. – Howard Tucker Aug 18 '14 at 15:12
  • I have now learned that the site is not even executing the button click code when this error is happening. – Howard Tucker Aug 18 '14 at 16:06
  • Was the server hacked by someone and there's malicious JavaScript on the page causing you grief? Check your browser debugger to see if you get any browser side errors. – Matthew Aug 21 '14 at 20:32
  • Have you tried using `Fiddler` to see if there is a difference in the data being sent and received when the page is misbehaving compared to when it is working normally? If any, what are the differences? – user1429080 Aug 25 '14 at 07:25
  • @WalrusvonZeppelin What environment differences do you have in production? Could it be redirecting the user to a secure page? Is a self-signed certificate being used? Do you believe there is a DNS issue? Does the application reference a domain name that is not recognized on the production server? Those are some issues I have run into myself. – AnotherDeveloper Aug 26 '14 at 16:44

2 Answers2

1

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?

Community
  • 1
  • 1
batwad
  • 3,588
  • 1
  • 24
  • 38
  • Please take a look at my recent edits. As to your question about the servers being identical the answer is unfortunately a definite no. – Howard Tucker Aug 22 '14 at 20:25
  • 2
    Do you have load-balancing in production? Could requests be failing to authenticate because of mistmatched machine keys? For a bit of fun, you could try changing to cookieless authentication and see if that makes a difference. – batwad Aug 23 '14 at 17:48
0

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.

Howard Tucker
  • 438
  • 9
  • 18