5

We have a web site hosting Office documents behind IIS6 Basic authentication.

IE has an authentication token for basic auth, which it presents to download the file. The user clicks "Open", and then Microsoft Office Protocol Discovery does a HTTP OPTIONS request on the directory the file was served from. However, Office does not have the auth token that IE does, so it prompts again for credentials. Hitting Cancel will then show you the file in Office.

As we are not a Sharepoint-like application, and we don't have a way of responding to OPTIONS, I would like to reply to all requests with the OPTIONS method (that are sent with a user-agent of "Microsoft Office Protocol Discovery") with something like an empty 200, as RFC 2616 states:

If no response body is included, the response MUST include a Content-Length field with a field-value of "0".

I am leaning towards an ISAPI filter that responds with 200 - before the Basic authentication happens. Windows auth or anonymous access are not options. Are there any alternatives I am missing?

4
  • I'm afraid that you might get the tumbleweed badge for this.
    – MathewC
    Jun 19, 2009 at 15:07
  • 1
    Then it may get the Necromancer badge for whoever answers it :)
    – crb
    Jun 19, 2009 at 15:13
  • And I assume forcing "Save as" is not an option, right? If it is an option, then maybe changing the content type of Office documents to application/octet-stream may remove the "Open" button from the IE download dialog. (Feels more like a hack, and you already got a workaround by hitting Cancel.)
    – Arjan
    Jul 18, 2009 at 11:57
  • Another thing you may, or may not, need to take into account: would Office interpret any HTTP Expires or Last-Modified headers, if any of those are returned along with your empty response? Like: what would happen if someone selects a file from a Recent Files menu in Office: would it request the document from the server again, or would it use a cached version? (By the way: I would expect the OPTIONS request to include the full path. Apparently not, as your KB article claims that allowing anonymous browse permissions may solve it.)
    – Arjan
    Jul 18, 2009 at 13:33

4 Answers 4

2

Is the draconian approach of just denying the OPTIONS verb in IIS globally a possibility? You could install URLScan and put OPTIONS in the [DenyVerbs] configuration.

0

I think you can disable WebDAV for a web site using appcmd.exe. Could you create a separate web site to hold the documents and disable WebDAV on it? That shouldn't affect any Sharepoint sites running on the same server.

JR

4
  • appcmd.exe is an IIS7 program; we're running IIS6. (We aren't running Sharepoint, but unfortunately I believe we need WebDAV for another part of the application.)
    – crb
    Jun 20, 2009 at 15:37
  • 1
    You can disable WebDAV without appcmd, but obviously if you need WebDAV you're stuck. Even if you need WebDAV maybe you could still split the site into two separate sites, one with WebDAV enabled and one without. They could point to the same physical directory and you would use the WebDAV disabled site only when you don't want the HTTP OPTIONS verb to be processed. Other than that, your suggestion of an ISAPI filter is the only solution I can think of. Sorry :-( Jun 21, 2009 at 6:37
  • Do I get my Necromancer badge? :-) Jun 21, 2009 at 6:38
  • Even with WebDAV off, you still get a response to OPTIONS from IIS - in this case, a completely different code path. issociate.de/board/post/232980/…. :(
    – crb
    Jun 22, 2009 at 15:38
0

A bit too long for a comment, so I'll abuse an answer. In fact it does not apply to your question, and I don't think this behaviour will trouble you, but just to be sure you know about it.

The other way around, when clicking URLs in an Office document, Office (2007) first tries to determine what the URL does. If this yields some 301 Redirect to a login page because the visitor (being Office) is not authorized, then Office will in fact ignore the original URL. Instead, it opens the 301 URL in the default browser, which is not always IE.

This may direct people to a login page even when they already had their default browser running and authorized. This is a minor annoyance when the URL that was clicked is still available in some GET parameter of the 301 URL, like login?goto=original-url. However, if the original URL is stored in some session (for which then Office holds the cookie, not the browser), then the user will even get stuck on the login page as the web server does not know which page to show after the extra login...

I've only tested using Office 2007, which at the time used the following User Agent for its hidden request towards an Apache server:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0 [...])

So I assume that Office 2007 actually uses IE itself to do the request. I have also noticed that Office 2007 can access the cookies from IE. For example: when the user is authorized using IE (using a cookie; I've not tested using Basic Authentication), then Office does not receive the 301 Redirect to a login page. So, when Office makes the funny request then it passes the cookie from IE to the server. It may also pass any received cookies back to IE (I've not tested that).

(Thanks for the link to that KB article!)

0

Perhaps, you should verify your iis6 configuration.

in the website configuration ->home dir -> configuration ->mappings Do you have a mapping to the .doc extension.

another thing: website configuration ->home dir -> configuration ->mappings -> options: the enable session state option, is it active?

another thing: Are you using more "workers" in the app pool? (don't use more than one) - Application pools -> properties -> performance -> web garden maximum number of workers -> set it to "1"

Sometimes if it has more than one worker process the "auth" can be "lost"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .