SharePoint login prompt when accessing files in a Document Library Solution


Español | English

UPDATED 29-SEP-2011: Fixed for anonymous sites and IE. Really Works!

Since long ago we faced a problem here at the University Of Veracruz, with some of the out-of-the-box funcionality in WSS, MOSS 2007 and SharePoint Server 2010.

As we all know, in order to login in a non anonymous SharePoint Web Site, we have to provide our domain/username credentials. That is ok if our site has not the “allow anonymous” option enabled. But what happens when we click on an Office document (such as Word or Excel file) using Internet Explorer?

Any time we try to open a file, we are again, prompted for the credentials. This happens even if the user was the creator of the file or the “allow anonymous” option is enabled.

What does Microsoft has to say about it?

This is by design.

Some references of this problem from Microsoft’s Web sites:

Multiple Logon while open office Document from SharePoint

Office: Authentication prompts when opening Microsoft Office documents

How documents are opened from a Web site in Office 2003

Are you crazy?

What is happening is that Office is trying to be so smart that needs to know who you are in order to provide some functionality for working with online documents inside the Office suite.

– Me: That’s fine, but at least give me the option to disable this behavior from SharePoint Administration.

– Office-SharePoint: No. You cannot.

Explanation of this behavior

Well, if you try to open an Office file directly from a remote place, Office wants to know who the hell you are. If the server responses with the

  • Microsoft Office Protocol Discovery or a
  • FrontPage Protocol or a
  • WebDav Protocol

then it ask you for credentials. Not only Office does this. If you try to open a library as a HTTP SharePoint Folder View, Windows (something to do with how IE handles downloads) does the same. The request comes from one of these protocols so the Microsoft client app have to ask for credentials. It is by design. You can see this yourself if you catch the Request.UserAgent string at the moment you open a file from SharePoint.

You can create an HttpModule that searches for the Request.UserAgent string, so if you find one of these protocols, then send a 200 status code in the response. The problem here is that you are disabling not only logins prompts for documents, but for the entire client integration feature (opening files from Word, Excel or folder views in libraries). This is not what we want.

We want to be able to use client integration, it’s a nice feature, but we do not want to be prompted inside our document libraries.

Solution WSS 3.0 and MOSS2007

As I said before, there is not a solution for this problem since this behavior is by design, but that is not going to stop us, is it? Here you have a workaround.

After searching all over the Web with no results, I decided to face the problem myself. If you notice, there is an option inside the file dropdown menu called “Sent To->Download a Copy”. This options does exactly what we are trying to accomplish. It calls a file inside layouts folder called download.aspx. This file serves a file from SP content database using this code:

// This inside download.cs file
Response.AddHeader("Content-Disposition", "attachment;filename=" + filename);

That’s why this option does not open the file directly on the server (the attachment string does it all).

The problem here is that this download.aspx file needs you to be authenticated. So if your site is anonymous, the option “Sent To->Download a Copy” will ask you for credentials. It’s stupid I know, but it does. They fix this on SPS2010 though.


Don’t worry. We are going to handle the anonymous stuff later on (See below on Anonymous section)

So, where is the code for that «Download a copy» option?

Exactly, as you are guessing, in a JavaScript file called “CORE.JS” located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\template\layouts\[some numbers] folder.

1. Make a backup of your CORE.JS file.

2. Find this line in the CORE.JS file:

Find this function
function DispDocItemEx(ele, fTransformServiceOn, fShouldTransformExtension, fTransformHandleUrl, strProgId)

3.Add this just below it UPDATED (29 SEP 2011):


/ Agregado por Memo Vera para evitar que abra las App de Office.
/ 28 SEP 2010
/ Modificado el 29 SEP 2011
var office_extensions = /(.docx?|.pptx?|xlsx?|md[ab]|mp[pt])$/i;
if (office_extensions.test(ele)) {
STSNavigate(ctx.HttpRoot + "/_layouts/download.aspx?" + "SourceUrl=" + escapeProperly(ele.href));
return false;
if (
event.cancelBubble = false;
return true;
/ FIN modificacion


Leave the rest of the function just as it is. No need to change anything else.

Don’t worry, no need to restart your SharePoint Server or any service. No need to add your SharePoint Server URL to your Trusted Sites (although I recommend it).

There you go. Refresh your Web Page and make sure you clean your local Web Browser cache so you get the new version of the CORE.JS file.


I have this working on my environment with WSS 3.0 with no problem. Everyone is happy, can use SharePoint Client Integration and those login prompts for online editing are gone. If I want to edit a document online, I select the option “Edit in Microsoft Word” or open the file from Word App.


Anonymous sites browsing with IE on MOSS 2007 and WSS 3.0

Like I wrote before, we are using the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\template\layouts\download.aspx file witch is the one that serves files from SP content database. The problem with anonymous sites and this file, is that it needs you to be authenticated. As crazy as it might sound, it is true. Try it yourself on a clean SP box:

Create an anonymous site, upload some Office documents and log off. Open IE and visit your site as anonymous and click on “Sent To->Download a Copy”. The box will ask for your credentials. Just crazy.


Microsoft fix this on SPS2010 though, so you do not need to do this on 2010 boxes.

We have to add just a simple line of code inside this file that tells SP that we dont need to be authenticated.

1. Open your C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\template\layouts\download.aspx file. I dont have to tell you to make a backup first.

2. Make some modifications, so your file will end like this:


<script runat="server" type="text/C#">
/ Cambio por Memo Vera y no pedira autenticacion
/ 29 SEP 2011
protected override bool AllowAnonymousAccess
return true;


3. Nice! Save your file.

4. Try it! Visit your site anonymously and click on a file or use the option Sent To->Download a Copy”.


Beautiful, isn’t it?


Solution SharePoint Server 2010

In SPS 2010 is slightly different.

The JavaScript file called “init.js” located in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033 folder.

The functions inside this file reffer to the core.js file. This init.js es minified (from init.debug.js) so it won’t be easy to edit. You have to be carefull.

1. Make a backup of your init.js file.

2. Find this line in the init.js file:


function DispEx(o,n,e,a,d,i,g,m,k,b,h,j,f,c,l){


3. Add this just right to it (remove the line breaks if necessary):


/*Agregado por Memo Vera para evitar que abra las App de Office. 18 NOV 2010.*/STSNavigate(ctx.HttpRoot + "/_layouts/download.aspx?SourceUrl=" + o);return false;


Update: Excel files have a problem with SPS2010. They wont download until you log in. They do not even have the context menu «Download a copy» enabled. I also have a problem with Office Web Apps. Give me sometime to figure it out this part. In the mean time, i suggest you to upload those files within a zip file.

This will only work for logged on users.

1. Find this line in the init.js file:




2. Add this just right to it (remove the line breaks if necessary):


/*Agregado por Memo Vera para evitar que abra las App de Office. 29 AUG 2011.*/return false;


Leave the rest of the function just as it is. No need to change anything else.

This applies for all Office files and it’s working also on others browsers like Firefox.

Hope it helps you.


Well, the only one I can think of is when some SharePoint update or patch replaces the CORE.JS file. No problem because we added just a couple of lines of code. We can certainly add them back.

Try it yourself and let me know if this has worked for you.