http_referer 使用 https 丢失
想象两个网页，都使用 https 查看。它们驻留在不同的域中。
我如何（合理地）确保某人通过驻留在另一个（特定）域上的超链接到达我的页面？我只想允许来自该域的流量。任何关于实现这一目标的最佳方法的想法将不胜感激。
我尝试查看 HTTP_REFERER，但显然在这种情况下它没有被发送。我知道 HTTP RFC 指定不从 https 发送引荐来源网址信息 -> http，但这也适用于 https ->跨域 https 或 ssl 证书？
如果重要的话，我的域在 ASP.NET 上运行。我无法控制源域。
谢谢。
Picture two web pages, both viewed using https. They reside on different domains.
How can I (reasonably) ensure that someone arriving at my page came via a hyperlink that resides on another (specific) domain? I only want to allow traffic from that domain. Any ideas on the best way to accomplish this would be appreciated.
I tried looking at the HTTP_REFERER, but apparently it is not being sent in this case. I know that the HTTP RFC specifies not sending the referrer info from https -> http, but does this also apply to https -> https across domains or ssl certs?
My domain runs on ASP.NET if it matters. I have no control over the source domain.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
详细说明 mjv 的响应：您应该将 HMAC (RFC 2104) 放入 URL 中。在两个服务器之间拥有共享密钥，并让原始服务器生成 /timestamp/hmac/path 形式的链接。 hmac应该从hmac(key,timestamp+path)进行验证，这样不同的镜像会生成不同的hmac。然后，目标服务器可以决定时间戳是否足够年轻以源自重定向。
您可以通过将客户端的 IP 地址放入 hmac 来进一步限制这一点，要求接收 URL 的同一客户端也解析它。不过，在存在仅处理 http 而不处理 https 的 HTTP 代理的情况下，这可能容易出错，反之亦然。
Elaborating on mjv's response: you should put HMAC (RFC 2104) into the URL. Have a shared secret between the two servers, and have the originating server generate links of the form /timestamp/hmac/path. The hmac should be verified from hmac(key, timestamp+path), so that different images generate different hmacs. The target server can then decide whether the timestamp is young enough to originate from a redirect.
You can further restrict that by putting the IP address of the client into the hmac, requring that the same client that received the URL is also resolving it. That may be error-prone, though, in the presence of HTTP proxies which process only http and not https or vice versa.
无论 RFC 是否允许发送 http_referer ，您都会发现许多 Web 客户端和/或其与服务器之间的代理或其他与隐私相关的网关都会删除或欺骗 http_referer在标头中，大多数基于 http_referer 的“身份验证”方案充其量只能部分发挥作用。
如果您与第一个 https 服务器的托管人有一些合作，您可能会同意在向服务器的请求中传递基于 time+something_else 的哈希代码。通过验证您端的哈希码，您将知道您的 https 访问者来自其他服务器[最近]。
Whether or not the RFCs allow the sending of http_referer or not, you'll find that many web clients and/or the proxies or other privacy-related gateways between it and the server will remove or spoof the http_referer in the header, rending most http_referer-based "authentication" scheme partially functional at best.
If you have some collaboration with the custodian of the first https server, you may agree on passing along a time+something_else-based hash code of sort in the requests to your server. By verifying the hashcode on your end, you'll known your https visitor came from the other server [very recently].
如果您无法控制推荐网站，那么您就不走运了。
如果可以的话，嗅探引荐来源网址，如果它不存在，则会弹出一个登陆页面，上面写着“单击此处转到站点 A，以便您可以返回此处”。
此外，花一些时间研究一种更可靠的方法来访问“安全”站点。
If you've got no control over the referring site you are out of luck.
Sniff the referrer if you can, and if it's not present throw up a landing page that says "click here go to site A so you can come back here".
Additionally, spend some time working on a more robust method of accessing your 'secure' site.