获取Sinatra完整RefererURL的技巧分享

一分耕耘，一分收获！既然打开了这篇文章《获取 Sinatra 完整 Referer URL 的方法与技巧》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

本文探讨了在 Sinatra 应用中尝试获取完整引荐来源 URL 时遇到的常见问题，即 `request.referrer` 仅返回协议和域名。核心原因在于现代浏览器默认采用更严格的引荐来源策略（如 `strict-origin-when-cross-origin`），这导致跨域请求时引荐来源 URL 被截断。文章将详细解释这一机制，并通过示例代码展示问题，并提供理解和应对策略。

在构建 Web 应用程序时，有时我们需要了解用户是从哪个完整的 URL 跳转或引用到当前页面的。特别是在提供 JavaScript 代码给外部网站调用时，获取调用方网站的完整 URL 对于分析、日志记录或根据来源调整响应内容至关重要。然而，开发者在使用 Sinatra 框架的 request.referrer 或 request.env["HTTP_REFERER"] 属性时，可能会发现它们仅返回了引荐来源的协议和域名，而非完整的路径信息，这与预期行为不符。

问题场景复现

假设我们有一个 Sinatra 应用，其目标是识别调用其提供的 JavaScript 代码的远程网站的完整 URL。以下是一个简化的 Sinatra 应用示例，用于调试并打印出请求相关的环境变量：

require 'sinatra'

get %r{/test} do
    debug = {
        :referrer => request.referrer,
        :http_referer => request.env["HTTP_REFERER"],
        :path_info => request.path_info,
        :query_string => request.query_string,
        :host => request.host,
        :url => request.url,
        :path => request.path
    }
    STDERR.puts debug.inspect
    erb "test" # 假设存在一个 test.erb 模板
end

如果这个 Sinatra 应用部署在 http://www.server.com，并且有一个远程网站 http://www.remote.com/url-with-test-code.html 包含如下 HTML 代码，通过

当 http://www.remote.com/url-with-test-code.html 页面加载并请求 http://www.server.com/test 时，我们期望在 Sinatra 应用的日志中看到 :referrer 键的值为 http://www.remote.com/url-with-test-code.html。然而，实际输出可能如下：

{:referrer=>"https://www.remote.com/", :http_referer=>"https://www.remote.com/", :path_info=>"/test", :query_string=>"", :host=>"www.server.com", :url=>"https://www.server.com/test", :path=>"/test"}

从上述输出可以看出，request.referrer 和 request.env["HTTP_REFERER"] 都被截断为仅包含协议和域名 (https://www.remote.com/)，而丢失了具体的路径信息 (url-with-test-code.html)。

根源分析：浏览器引荐来源策略

这种现象并非 Sinatra 或 Ruby 的问题，而是现代浏览器为了增强用户隐私和安全性而实施的引荐来源（Referrer）策略所致。许多浏览器已经将默认的引荐来源策略从旧的 no-referrer-when-downgrade 更改为更严格的 strict-origin-when-cross-origin。

• no-referrer-when-downgrade (旧默认值): 在协议降级（例如 HTTPS 到 HTTP）时，不发送 Referer 头部。其他情况下，会发送完整的 URL。
• strict-origin-when-cross-origin (新默认值):
  • 在同源请求中，发送完整的 URL 作为 Referer。
  • 在跨源请求中，仅发送源（协议、主机和端口）作为 Referer。这意味着路径和查询参数等信息会被移除。
  • 在协议降级时，不发送 Referer。

当 http://www.remote.com 请求 http://www.server.com 上的资源时，这是一个典型的跨源请求。根据 strict-origin-when-cross-origin 策略，浏览器只会发送 http://www.remote.com/ 作为引荐来源，从而导致服务器端获取到的 Referer URL 被截断。在某些更严格的策略下（如 no-referrer），甚至可能完全不发送 Referer 头部。

应对策略与注意事项

由于这是浏览器级别的安全和隐私特性，服务器端无法强制浏览器发送完整的跨域 Referer URL。因此，我们不能直接依赖 request.referrer 来获取完整的远程网站路径。

1. 理解与适应： 接受这一事实是关键。如果您的应用逻辑需要完整的来源 URL，并且该来源是跨域的，那么您可能需要重新评估您的设计或寻找替代方案。

2. 客户端协作（如果可能）： 如果您对远程网站的 HTML 内容有控制权，或者可以与远程网站的开发者协作，可以考虑通过客户端 JavaScript 将完整的 window.location.href 作为查询参数传递给您的脚本。例如：

   在 Sinatra 应用中，您就可以通过 request.params["referrer_url"] 获取到这个值。但这需要远程网站的主动配合。

3. 仅依赖来源信息： 如果您的需求只是识别请求的来源域名，那么当前 request.referrer 返回的截断信息已经足够。例如，判断请求是否来自白名单域名，或者进行基于域名的统计。

4. 服务器端日志分析： 某些情况下，如果您有能力访问请求发起方的服务器日志（例如通过 CDN 或其他代理），这些日志可能包含更详细的请求信息，但这超出了直接通过 request.referrer 获取的范畴。

总结

在 Sinatra 或任何其他 Web 框架中，当处理跨域请求时，期望通过 request.referrer 获取完整的引荐来源 URL 是不现实的。这是由现代浏览器默认的更严格的引荐来源策略 (strict-origin-when-cross-origin) 决定的，旨在保护用户隐私。开发者应理解这一机制，并根据实际需求调整应用程序的设计，例如通过客户端主动传递信息或仅依赖可用的来源域名信息。直接从服务器端获取完整的跨域引荐来源 URL 几乎是不可能的任务。

到这里，我们也就讲完了《获取Sinatra完整RefererURL的技巧分享》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！