当从外部源(例如Excel、Word等)单击链接时，为什么无法识别cookie ?

I noticed that when a link is clicked externally from the web browser, such as from Excel or Word, that my session cookie is initially unrecognized, even if the link opens up in a new tab of the same browser window.

我注意到，当从web浏览器(如Excel或Word)外部点击一个链接时，我的会话cookie最初是无法识别的，即使该链接在同一个浏览器窗口的新标签中打开。

The browser ends up recognizing its cookie eventually, but I am puzzled as to why that initial link from Excel or Word doesn't work. To make it even more challenging, clicking a link works fine from Outlook.

浏览器最终识别出了它的cookie，但是我很困惑为什么Excel或Word的初始链接不起作用。为了使它更具挑战性，点击链接可以从Outlook中运行。

Does anybody know why this might be happening? I'm using the Zend Framework with PHP 5.3.

有人知道为什么会这样吗?我正在使用Zend框架和PHP 5.3。

12 个解决方案

#1

This is because MS Office is using Hlink.dll component to lookup if the link is Office document or something else. MS Office expect to open the document linked within documents without the aid of external browser (using Hlink.dll component of IE6).

这是因为MS Office使用的是Hlink。如果链接是Office文档或其他文件，则查找dll组件。MS Office希望在不借助外部浏览器(使用Hlink)的情况下打开文档中链接的文档。IE6的dll组件)。

If session cookie protects website Hlink naturally is being redirected to login page and having reached HTML page and not able to "understand" it opens it in external browser. Note that it opens not original URL (expected behavior) but the result of redirect, even if it was 302 redirect.

如果会话cookie保护网站Hlink，那么它自然会被重定向到登录页面，并且已经到达HTML页面，并且无法“理解”它将在外部浏览器中打开。注意，它打开的不是原始URL(预期行为)，而是重定向的结果，即使它是302重定向。

Microsoft has that bug in unsupported component (Hlink.dll), instead of recognizing the bug they turn it over to our head (trying to convince us that it is flaw of SSO system we use, i.e. session cookies) and refuses to upgrade it. It offers workaround that turns off the lookup functionality of MS Office:

微软在不支持的组件(Hlink.dll)中有这个bug，他们没有识别这个bug，而是把它交给我们的负责人(试图让我们相信这是我们使用的SSO系统的缺陷，即会话cookie)，并拒绝升级它。它提供了关闭MS Office查找功能的变通方法:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
  Office\9.0\Common\Internet\ForceShellExecute:DWORD=1

Or offer us to workaround serverside, to avoid HTTP redirects and change into Javascript redirects or META REFRESH redirects (i.e. to have Hlink get text/html page on original URL and make it run external browser to handle it).

或者让我们在服务器端工作，以避免HTTP重定向和更改为Javascript重定向或元刷新重定向(即让Hlink获取原始URL的文本/html页面，并使其运行外部浏览器来处理它)。

#2

We had this same problem and wrote an open source gem to help those using rails: https://github.com/spilliton/fix_microsoft_links

我们遇到了同样的问题，并编写了一个开源gem来帮助那些使用rails的人:https://github.com/spilliton/fix_microsoft_links。

You can use the same approach we used on any framework though:

你可以使用我们在任何框架上使用的方法:

Detect if the user agent is from a Microsoft product
检测用户代理是否来自Microsoft产品。
Render a blank html page with a meta refresh tag that will cause the browser to refresh the page with the correct cookies
呈现一个带有元刷新标记的空白html页面，浏览器将使用正确的cookie刷新页面

Example code here: https://github.com/spilliton/fix_microsoft_links/blob/master/lib/fix_microsoft_links.rb

示例代码:https://github.com/spilliton/fix_microsoft_links/blob/master/lib/fix_microsoft_links.rb

#3

Server side this worked for me in IIS (using a rewrite rule)

服务器端在IIS中可以使用(使用重写规则)

<rule name="WordBypass" enabled="true" stopProcessing="true">
    <match url=".*" />
    <conditions>
        <add input="{HTTP_USER_AGENT}" pattern="Word|Excel|PowerPoint|ms-office" />
    </conditions>
    <action type="CustomResponse" statusCode="200" statusReason="Refresh" statusDescription="Refresh" />
</rule>

#4

Fix for VB.NET:

为VB.NET修复:

Dim userAgent As String = System.Web.HttpContext.Current.Request.UserAgent

If userAgent.Contains("Word") Or userAgent.Contains("Excel") Or userAgent.Contains("PowerPoint") Or userAgent.Contains("ms-office") Then
       System.Web.HttpContext.Current.Response.Clear()
       System.Web.HttpContext.Current.Response.Write("<html><head><meta http-equiv='refresh' content='0'/></head><body></body></html>")
       System.Web.HttpContext.Current.Response.End()
End If

It basically forces the browser to refresh the page, so the request comes in with the user agent of the browser and all the correct cookies.

它基本上强制浏览器刷新页面，因此请求将与浏览器的用户代理以及所有正确的cookie一起进入。

#5

Here is a solution for C# ASP.NET based on spilliton's answer above. In Global.asax.cs, add the following:

这里有一个c# ASP的解决方案。根据上面斯泼利顿的回答。在Global.asax。cs,添加以下:

    private static string MSUserAgentsRegex = @"[^\w](Word|Excel|PowerPoint|ms-office)([^\w]|\z)";
    protected void Application_OnPostAuthenticateRequest(object sender, EventArgs e)
    {
        if (System.Text.RegularExpressions.Regex.IsMatch(Request.UserAgent, MSUserAgentsRegex))
        {
            Response.Write("<html><head><meta http-equiv='refresh' content='0'/></head><body></body></html>");
            Response.End();
        }
    }

#6

PHP solution:

PHP解决方案:

This prevents the MS product recognising the redirect. MS therefore launches a browser from the required link.

这阻止了MS产品识别重定向。因此，MS从所需的链接启动浏览器。

if (isset($_SERVER['HTTP_USER_AGENT']))
{
    $http_user_agent = $_SERVER['HTTP_USER_AGENT']; 
    if (preg_match('/Word|Excel|PowerPoint|ms-office/i', $http_user_agent)) 
    {
        // Prevent MS office products detecting the upcoming re-direct .. forces them to launch the browser to this link
        die();
    }
}

.. redirect after this code

. .这段代码后重定向

#7

Here is my solution for this in WordPress. Add this to functions.php in your theme or another plugin file.

这是我在WordPress的解决方案。增加这个功能。php在你的主题或另一个插件文件。

This may be helpful if your system, like WP, sends logged out users to a login page with a redirect to the page they were trying to access. Word was sending users to this page, but then WP wasn't properly handling the case where a user was already logged in. This code checks if there is a current user and a redirect_to param passed. If so, it redirects to the redirect_to location.

如果您的系统(如WP)将注销的用户发送到登录页面，并将其重定向到他们试图访问的页面，那么这可能会很有帮助。Word向这个页面发送用户，但是WP没有正确处理用户已经登录的情况。这段代码检查是否有一个当前用户，并传递了一个redirect_to param。如果是，它将重定向到redirect_to location。

function my_logged_in_redirect_to()
{
global $current_user;

if($current_user->ID && $_REQUEST['redirect_to'])
{           
    wp_redirect($_REQUEST['redirect_to']);
    exit;
}
}
add_action('wp', 'my_logged_in_redirect_to');

#8

1.From excel/word point to http://example.com/from_excel.php

1。从excel/word point到http://example.com/from_excel.php

2.In "from_excel.php" redirect to page where you use session

2。在“from_excel。php“重定向到使用会话的页面”

<script>document.location.href = "http://example.com/page_with_session.php"; </script>

#9

Here's a VBA fix, for Excel. The same concept can be applied for Microsoft Word. Basically, rather than firing off the link from within Excel, the code executes the link from within a shell. Here's the code:

这是Excel的VBA修正。同样的概念也适用于Microsoft Word。基本上，代码不是从Excel内部启动链接，而是从shell中执行链接。这是代码:

Private Sub Worksheet_FollowHyperlink(ByVal objLink As Hyperlink)
    Application.EnableEvents = False
    Dim strAddress As String
    strAddress = "explorer " & objLink.TextToDisplay
    Dim dblReturn As Double
    dblReturn = Shell(strAddress)
    Application.EnableEvents = True
End Sub

For the Excel sheet that contains the links, right-click the sheet tab and click View Code. The VBA editor appears.
对于包含链接的Excel表，右键单击“选项卡”并单击“查看代码”。VBA编辑器出现。
Paste the code into the window, and close the editor.
将代码粘贴到窗口中，并关闭编辑器。
Modify each link in the page so it simply points back to the cell that it is in. To do so:
修改页面中的每个链接，使其指向所在的单元格。这样做:
Right-click the link, and click Edit Hyperlink. An Edit Hyperlink window appears.
右键单击该链接，并单击Edit Hyperlink。出现一个编辑超链接窗口。
Click Place In This Document.
单击此文档中的Place。
Click the sheet name.
单击表的名字。
For Type the cell reference, enter a cell reference (e.g. A4).
对于单元格引用，输入单元格引用(例如A4)。
Click OK.
单击OK。

A couple of notes:

一些笔记:

You will need to save the spreadsheet as a macro-enabled spreadsheet (.xlsm). When users open the spreadsheet, they will be asked to enable macros. If they answer No, the links will not work.
您需要将电子表格保存为一个宏观支持的电子表格(.xlsm)。当用户打开电子表格时，将要求他们启用宏。如果他们回答“不”，链接将不起作用。
These instructions are based on Excel 2010. Presumably later versions are similar.
这些说明基于Excel 2010。大概后来的版本也差不多。

#10

I had to solve this issue for an ASP.NET site but I only wanted to use javascript/ jQuery:

我必须为ASP解决这个问题。但我只想用javascript/ jQuery:

var isCoBrowse = ('<%= Session["user"].ToString().ToLower() %>' != '0');
if (isCoBrowse && window.location.href.indexOf('ReturnUrl=') >= 0 && window.location.href.indexOf('dllCheq') == -1) {
    //redirect to the ReturnUrl & add dllCheq to the URI
    var toRedirect = decodeURIComponent(gup('ReturnUrl', window.location.href)) + '&dllCheq';
    window.location = toRedirect;
}

I got the gup function from: How to get the value from the URL parameter?

我得到了gup函数:如何从URL参数获取值?

#11

Use fix provided by microsoft given link below. https://support.microsoft.com/en-us/kb/218153

使用microsoft提供的fix在下面提供的链接。https://support.microsoft.com/en-us/kb/218153

#12

-2

I suspect this is a matter of how you are setting the cookie(s).

我怀疑这是你如何设置cookie的问题。

Due to the nature of how the web was created, example.com is not seen as the same domain as www.example.com; hence: you can be logged in at www.example.com and not logged in at example.com.

由于web是如何创建的，example.com并不被视为与www.example.com相同的域;因此:您可以登录www.example.com，但不能登录example.com。

So in other words, check the URL in your word or excel file - is it the same domain as how you are logged in within your browser?

换句话说，检查word或excel文件中的URL——它与你在浏览器中的登录方式相同吗?

There are two fixes/solutions to this cookie inconsistency: 1. redirect anyone who tries to load your site without the www. to the same page with the www. (or vice versa), or 2. when you are setting the cookie, make sure to specify the domain argument as ".example.com". The leading dot indicates the cookie should be valid on all subdomains of that domain as well.

对于此cookie不一致性，有两个修复/解决方案:1。如果没有www，请重定向任何试图加载您的站点的人。与www同页。(反之亦然)在设置cookie时，请确保将域参数指定为“.example.com”。前导点指示cookie应该对该域的所有子域都有效。

I suspect the reason the browser eventually recognizes it is because you probably eventually end up landing on a URL with the same domain structure as how you are logged in.

我怀疑浏览器最终认识到这一点的原因是，你可能最终会在一个URL上着陆，而这个URL与你的登录方式是一样的。

Hope this helps.

希望这个有帮助。

#1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
  Office\9.0\Common\Internet\ForceShellExecute:DWORD=1

#2