MS-Word 如何打开超链接？
我有一个带有超链接的 MS-Word 文档。该超链接指向我的服务器上的身份验证重定向器。当我按住 Control 键并单击超链接时，我的服务器日志报告它
- 使用 IE 进行了提取，然后
- 使用 IE 获取重定向 url，然后
- 启动“默认浏览器”（在我的例子中是 Firefox），并重新获取第二个（重定向）URL。
什么给？这是设计使然吗？
我注意到这一点是因为我的身份验证系统当前依赖于重定向器设置的 cookie。我对使用基于 url 的身份验证对此有一些想法，但我需要首先知道是什么激发了 Word 的行为。
我有一些猜测，但我正在寻找权威的东西（或者至少是更明智的猜测）。
I have an MS-Word document with a hyperlink. The hyperlink points at an authentication redirector on my server. When I control-click on the hyperlink, my server logs report that it
- does a fetch with IE, then
- fetches the redirect url with IE, then
- launches the "default browser", which is Firefox in my case, and re-fetches the second (redirect) URL.
What gives? Is this by design?
I noticed this because my auth system is currently dependent on cookies set by the redirector. I have some ideas about using url-based auth for this bit, but I need to know what is motivating Word's behavior first.
I have some guesses but I'm looking for something authoritative (or at least a better-informed guess).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不幸的是，是的。他们试图将其归咎于“Web 服务器使用的单点登录系统的限制”...
http://support.microsoft.com/kb/899927
Unfortunately, yes. And they try to blame it on "a limitation of the single sign-on system used by the web server"...
http://support.microsoft.com/kb/899927
其实，这就是一个“功能”。如果超链接指向 Word 文档，Word 将尝试下载该文档并将其打开。 （由于用户代理，您一定认为它是 IE，但请求来自 Word 进程中的 WinInet。）
当服务器不响应页面，而是响应重定向和曲奇饼。 Word 按照重定向来查看是否会获取 Word 文档，最终会得到一个 HTML 页面。然后它决定 Firefox 应该显示它，因此它使用最终重定向的 URL 启动 Firefox（但没有服务器发送的任何 cookie）。
如果这是 SSO 登录，Firefox 最终可能需要这些 cookie。
Actually, this is a "feature". If the hyperlink is to a Word document, word will attempt to download the document and open it. (You must be thinking it's IE because of the user-agent, but the request is coming from WinInet in the the Word process.)
The mess comes about when the server doesn't respond with a page, but rather responds with a redirect and cookies. Word follows the redirect to see if it's going to get a Word document, and it eventally ends up with an HTML page. It then decides that Firefox should display it, so it launches Firefox with the final redirected URL, (but without any of the cookies that the server sent).
Firefox may end up needing those cookies, if this is an SSO sign-on.
后期添加：
注意到同样的问题。 MVC 4 导致查询字符串信息丢失。
Word 仅在收到 Http 200 状态后才启动浏览器。
因此，我通过在控制器中检查请求是否来自 IE7（代表可能仅是 MS Word）并手动返回 200 来避免这种情况。
然后，“真实”浏览器将重新发送 http 请求，一切都会顺利结束，因为从那里开始，请求将被正常处理，并且所有信息都保留在与“真实”浏览器的会话中。
有点解决方法，但是嘿，它有效。它仅适用于少量请求（在我们的例子中）。
Late addition:
Noticed the same problem. Here with MVC 4 it caused the loss of querystring information.
Word launches the browser only after it receives a Http 200 status.
So I avoided this by checking in the controller whether the request comes from IE7 (representing likely only to be MS Word) and returning a 200 manually.
Then the 'real' browser will re-send the http request and all's well ends well, since from there the request is processed normally and all information is retained in the session with the 'real' browser.
Bit of a workaround, but hey, it works. And it's only for a small amount of requests (in our case).