OFF2000: You Are Unnecessarily Prompted for Your Password When You Follow Hyperlink on an Office Document

When you follow a hyperlink on a Microsoft Office 2000 document to an Active Server Pages (ASP) page that redirects you to another Office 2000 document, you may receive an unnecessary password prompt. For example, your ASP code may look similar to the following:
A hyperlink to this page looks similar to the following:

The password prompt dialog box appears by design.

When you click the hyperlink to the ASP page, which redirects you to another document, the following occurs.

NOTE: This example uses the sample code in the "Symptoms" section of this article.

1. If you open the original document (Doc1.doc) in Microsoft Internet Explorer, the document is opened as read-only.
2. Word starts in Internet Explorer. When you click the hyperlink to the second document (http://server/redirect.asp?docid=doc2.doc), the URL is written to a registry key because it was clicked in an Office program.
3. Internet Explorer now takes control and goes to the ASP page. Before the ASP page redirects the user, Internet Explorer tells Word to handle the document at the pre-redirected URL (http://server/redirect.asp?docid=doc2.doc).
4. When Word receives the new URL, it compares the URL to what is in the registry key (from step 2). In this case, the URL matches, so Office asks for Read/Write access to the URL.
5. Word then calls to the Internet Publishing Provider to handle the downloaded file. Because the URL is still the same (http://server/redirect.asp?docID=doc2.doc), the Internet Publishing Provider is asking for Read/Write access to the ASP page on the Web server, which you do not have access to, so you are prompted for your password.
6. After the password prompt dialog box is dismissed, the ASP code is executed, and the REDIRECT occurs. Therefore the redirected document opens in Word (http://server/docs/doc2.doc).

Word 2000, Internet Explorer, and the Web Publishing Provider are behaving correctly here. There may be a case in which a user actually wants to edit the ASP page on the Web server; therefore this type of access is available.

To work around this problem, you can use a combination of server-side and client-side ASP script. You no longer use the RESPONSE.REDIRECT server-side method, but instead use the LOCATION.REPLACE client-side method. The following is a sample code similar to the one in the "Symptoms" section of this article that uses this method: