So we ran into the problem of a customer's users' not being able to use our application. The users happen to use Internet Explorer and IIS (Internet Information Server) and the behavior was intermittend.
We thought, this is a network issues for sure; so we put sniffers on client and servers sides and observed that nothing was conclusive.
Another thing that threw us was that using an alternate browser such as Chrome everything seemed to be working.
When things did not work, however, we saw that IE (version 6 through 9) would not send any HTTP form information along. So even with simple HTML page that had two form fields "FirstName" and "LastName", we would see through the protocol capture that IE started an HTTP post, but no form fields and values. They had vanished. Poof !
Our further suspicion of maybe a plugin, proxy or firewall stripping this data out was also eliminated and we started staring at each like we are all going crazy. And, of course, we googled. Nothing there either. (Google, oh Google, why did you fail us!)...
Then, a little break, we discovered, that everytime things stopped working and Forms started vanishing, the user had just entered a secured area of the site and returned to an unsecured area. The security access was transparent as IIS was setup to use "Windows Authentication" similar to "Integrated Authentication"; thus, IE was doing this in the background. Thereafter, even if the user returned to the non-secure areas of the site, IE would refuse to send Form data. After more digging we found that this seems to be intentional; we even found an old web-page that descibed this as good feature for IE6. The behavior is this: after, IE authenticates to a site via NTML / Kerberos (i.e. some integrated way), all traffic to that site has to be secured and as part of the security mechanism no plain text form submission is allowed. Great !
The solution to this was to move the secure portions to a seperate site on IIS and thus everything started working as it should. IE was happy, customer was happy, and we could go to sleep.
Hope you don't have to spent as much time on troubleshooting knowing this.
B.
We thought, this is a network issues for sure; so we put sniffers on client and servers sides and observed that nothing was conclusive.
Another thing that threw us was that using an alternate browser such as Chrome everything seemed to be working.
When things did not work, however, we saw that IE (version 6 through 9) would not send any HTTP form information along. So even with simple HTML page that had two form fields "FirstName" and "LastName", we would see through the protocol capture that IE started an HTTP post, but no form fields and values. They had vanished. Poof !
Our further suspicion of maybe a plugin, proxy or firewall stripping this data out was also eliminated and we started staring at each like we are all going crazy. And, of course, we googled. Nothing there either. (Google, oh Google, why did you fail us!)...
Then, a little break, we discovered, that everytime things stopped working and Forms started vanishing, the user had just entered a secured area of the site and returned to an unsecured area. The security access was transparent as IIS was setup to use "Windows Authentication" similar to "Integrated Authentication"; thus, IE was doing this in the background. Thereafter, even if the user returned to the non-secure areas of the site, IE would refuse to send Form data. After more digging we found that this seems to be intentional; we even found an old web-page that descibed this as good feature for IE6. The behavior is this: after, IE authenticates to a site via NTML / Kerberos (i.e. some integrated way), all traffic to that site has to be secured and as part of the security mechanism no plain text form submission is allowed. Great !
The solution to this was to move the secure portions to a seperate site on IIS and thus everything started working as it should. IE was happy, customer was happy, and we could go to sleep.
Hope you don't have to spent as much time on troubleshooting knowing this.
B.
No comments:
Post a Comment