Archiwa tagu: iis

Login prompt when opening Office documents from a public SharePoint site

Hi there,

we have a following scenario:

  • a MOSS 2007 web application,
  • publicly accessible,
  • its URL added in Internet Explorer to the intranet sites,
  • checked in and published office documents within this site.

The problem occurring is that when one wants to open a MS Office document from the site using Internet Explorer, the Office application (Word, Excel..) is asking for username and password, although the document is publicly visible and not password-protected. Even if one clicks „Cancel” on the login prompt, the file is opened seamlessly.

After some research, I came across two possible solutions that can be applied in order to get rid of the unnecessary login prompt: either remove the URL from IE’s intranet sites list (which might not be desired because of other benefits of intranet sites), or make  following changes in the applications settings in IIS (7):

Go to the web site’s features, open the request filtering feature, and in the „HTTP Verbs” tab, add a deny rule for the verbs „OPTIONS” and „PROPFIND„. In my case, the use of checking in/out documents, opening them in read-only mode etc., was not necessary in this application, thus the verbs could be inhibited without the loss of other needed functionalities.

More information can be found in this KB article.

Hope this helps,
Lukasz

Sys.WebForms.PageRequestManagerParserErrorException in an intranet-zone web application (IE)

Hi there,

this time I’d like to describe a pretty odd issue encountered a while ago.

We have a following scenario: We have an ASP.NET 4 web application, configured in IIS 7 only for basic authentication. The application uses quite a lot AJAX update panels and other javascripts. The problem that started occuring was the infamous Sys.WebForms.PageRequestManagerParserErrorException:

—————————
Microsoft Internet Explorer
—————————
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.

Details: Error parsing near ScriptResource.axd ….

It happened only using IE (v.7,8,9), but since IE has  always been a bit „different”, that was not the funniest fact about the problem. What was in fact strange, was that it happened only on some machines – I’ll come back to that later in this post.

However, all the hints pointing how to avoid that error failed. In fact, the application did not have any calls to Response.Write, Server.Transfer, neither http modules nor response filters. Trace was also disabled.

Not the first time, Fiddler came to rescue. I was able to notice that for each needed request for an aspx page, actually two requests were made. The first one was giving a HTTP status code 401 (access denied), then the second one was successful (HTTP 200). Analyzing the request headers the only difference between them was the authorization method. The request which gave 401 response had:

Authorization: NTLM DFGHJKLDRFGHNXAAAAA==

The second one had :

Authorization: Basic ZXVyasdasdasdasdasdasd=

Since the update panel and other asynchronous requests were getting a 401 response, the application was giving the error mentioned above.

Now, the question was, why would the NTLM authorization be enabled, if I had set explicitly in IIS the windows authentication method to be disabled? As mentioned earlier, only basic authentication was enabled. Since this app was also a sub-application of another one (which had windows authentication enabled), first thought was an inheritance problem of IIS settings. But the app having problems was overriding the parent setting (win auth disabled), so from that point of view it was OK.

As mentioned already earlier, the issue was occuring on some machines only. And there was the rub. The machines were the corporate ones of our company, and the website was added as an intranet site in Internet options. Additionally, the automatic logon for intranet zone was enabled:

automatic logon only in intranet zone

This setting is forcing Internet Explorer first to try to authorize the user logged onto the machine in the domain. That failed, since NTLM/Windows auth was disabled in IIS. First then the ‚correct’ basic authentication request was made.

As a solution you may either remove the application from intranet sites (if your/corporate policy allows it), or you may enable Windows authentication in the application instead of the basic one.

Hope it helps,
Łukasz