在Word或Excel(PHP,Laravel)中单击URL时,路由无法正常工作 [英] Routing doesn't work properly when URL clicked in Word or Excel (PHP, Laravel)

查看:140
本文介绍了在Word或Excel(PHP,Laravel)中单击URL时,路由无法正常工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们有一个运行在PHP 5.5&上的应用程序; Laravel 5.2.它有一个用户帐户区域,其中所有路由都以/account/作为前缀.帐户区域的默认路由是/account/services.登录后,默认情况下会将用户路由到此页面.

当然,如果用户输入特定的帐户区域网址(例如example.com/account/billing),则在登录时(或如果已经通过身份验证的话)直接进入计费页面.

但是,如果我在Excel或Word中单击 https://example.com/billing ,到默认的/account/services页面(如果经过身份验证;否则,我登录后会去那里).

起初我认为这是因为他们正在插入隐藏字符并因此使URL无效,从而导致我们的应用程序将用户路由到默认URL.

所以我尝试了以下解决方案:

  • trim() URL
  • 删除不间断空格:$url = preg_replace('~\x{00a0}~','',$reqURL);
  • 删除字节顺序标记的功能(源自此处)

我什至将测试URL从浏览器复制到NPP中,并视为十六进制.似乎没有多余的字符.

如果我在浏览器栏中手动键入相同的URL,则一切正常.

这仅在需要身份验证的URL上发生,公共/前端URL似乎不受影响.这导致我此答案,但是我不确定它是否适用于我们的情况.在打开浏览器中的这些URL之前,Microsoft确实确实在运行Microsoft Office Protocol Discovery,但是我们的身份验证cookie被识别(浏览器打开到登录页面,但是如果用户具有有效的cookie,则会立即重定向到帐户区域).

还有其他人经历过吗?我还能看什么其他原因?

解决方案

Microsoft的用户代理确实是罪魁祸首.

我用.htaccess规则解决了该问题,该规则对与Office相关的用户代理的请求返回200响应. (以前,Laravel将302重定向返回到登录页面,因为这些路由都需要身份验证.)这会诱使Office打开带有预期URL的浏览器(如果未通过身份验证,它们仍会重定向至登录表单,但登录后重定向现在可以完美运行).

# Return 200 to Microsoft Office user agents to resolve redirection issue
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} MSOffice [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Microsoft\ Office\ Word [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Office [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Microsoft\ Office\ PowerPoint [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ms\-office [NC]
RewriteRule .* - [R=200,L]

我还尝试了此规则,该规则向MS Office协议用户代理返回不允许使用方法"响应,但是并不能解决问题.

# Intercept Microsoft Office Protocol Discovery
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Protocol\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Existence\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\-WebDAV\-MiniRedir.*$
RewriteRule .* - [R=405,L]

We have an application running on PHP 5.5 & Laravel 5.2. It has a user account area, in which all routes are prefixed by /account/. The default route for the account area is /account/services. Users are routed to this page by default after login.

Of course, if a user enters a specific account area URL such as example.com/account/billing, they are taken to the billing page upon login (or directly, if already authenticated).

However, if I click https://example.com/billing in Excel or Word, I go to the default /account/services page (if authenticated; otherwise I go there after logging in).

At first I believed this was because they are inserting hidden character(s) and thus invalidating the URL, causing our application to route the user to the default URL.

So I tried these solutions:

  • trim() the URL
  • Removing nonbreaking spaces: $url = preg_replace('~\x{00a0}~','',$reqURL);
  • function to remove byte order mark (sourced here)

I've even copied test URLs from the browser into NPP and viewed as hex. There don't appear to be any extra characters.

If I manually type the same URL into the browser bar, everything works perfectly.

This is only happening for URLs which require authentication, public / frontend URLs seem unaffected. This lead me to this answer, but I'm not sure it applies in our case. Microsoft is indeed running Microsoft Office Protocol Discovery before opening these URLs in the browser, but our authentication cookie is being recognized (the browser opens to the login page, but immediately redirects to the account area if the user has a valid cookie).

Has anyone else experienced this? And what other causes could I look at?

解决方案

Microsoft's user agent was indeed the culprit.

I solved it with an .htaccess rule which returns a 200 response to requests from Office-related user agents. (Previously, Laravel was returning a 302 redirect to the login page, since these routes require authentication.) This tricks Office into opening a browser with the intended URL (if they aren't authenticated, they're still redirected to the login form, but post-login redirect now works perfectly).

# Return 200 to Microsoft Office user agents to resolve redirection issue
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} MSOffice [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Microsoft\ Office\ Word [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Office [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Microsoft\ Office\ PowerPoint [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ms\-office [NC]
RewriteRule .* - [R=200,L]

I also tried this rule, which returns a "Method Not Allowed" response to the MS Office Protocol user agent, but it didn't solve the issue.

# Intercept Microsoft Office Protocol Discovery
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Protocol\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Existence\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\-WebDAV\-MiniRedir.*$
RewriteRule .* - [R=405,L]

这篇关于在Word或Excel(PHP,Laravel)中单击URL时,路由无法正常工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆