$_SERVER['HTTP_REFERER'] 和 cookies
我在 SO 和其他网站上读到， $_SERVER['HTTP_REFERER'] 是我们作为程序员应该始终避免的事情。阅读 PHP 手册我们会遇到以下几行：
将用户代理引导至当前页面的页面地址（如果有）。这是由用户代理设置的。并非所有用户代理都会设置此项，有些用户代理提供了修改 HTTP_REFERER 的功能。简而言之，它确实不能被信任。
考虑到“用户代理”，例如Web浏览器（Safari、Chrome、Opera、Firefox，基本上都是），手册告诉我们这个变量可能会被它们更改。 这是我的第一个问题：
问题1：为什么“用户代理”要修改这个参数？网页浏览器不设置此参数的原因是什么？
这只是好奇心，我不会使用 $_SERVER['HTTP_REFERER']。 从我最新的声明中可以看出，如果我们确实需要这样的功能，我们就需要弄清楚一些事情。我首先想到的是 cookie 解决方案，在该解决方案中，我们会执行以下操作：
setcookie('latest_page', __FILE__, 60 * 60 * 24 * 7);
然后，根据您喜欢的方式，您可以恢复所需的内容。 这是第二个问题，也是最后一个问题：
问题2：这种方式是最好的吗？有什么办法可以改善吗？
I read, both on SO and other sites, that $_SERVER['HTTP_REFERER'] is something we, as programmers, should always avoid. Reading the PHP manual we encounter these lines:
The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.
Considering "user agents" things such as Web Browser (Safari, Chrome, Opera, Firefox, basically they are all), the manual tell us that this variable may be changed by them.
Here it comes my first question:
Question 1: Why should "users agent" modify this parameter? What are the reason for a web browser not to set this parameter?
It's just inquisitiveness, and i'll not use $_SERVER['HTTP_REFERER'].
From my latest statement, it's oblivious that, if we do need of such a function, we need to figure something out. The first thing that comes in my mind is a cookie solution, in which we do something like:
setcookie('latest_page', __FILE__, 60 * 60 * 24 * 7);
And then, based on how you prefer to do it, you can recover what you need.
Here it comes the second and last question:
Question 2: Is this way the best? Are there any way to improve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
没有理由避免
HTTP_REFERER。只是在使用时要注意，它并不总是被设置的，并且它可以被客户端自由操作，因此它是不可信数据。绝大多数客户端都会设置该变量，并且设置正确。
阻止它的主要原因是隐私：例如，当在网络邮件客户端中打开电子邮件时，外部图像的链接将在
HTTP_REFERER标头中携带网络邮件服务的地址。这就是为什么 GMail 和 Yahoo 努力阻止它。您建议的解决方法仅适用于同一网站内的移动，如果用户打开多个选项卡/浏览器窗口来浏览您的网站，该解决方法将会中断。如果您需要知道引用页面，更好的方法是添加一个 GET 参数，例如
Edit: 依赖 HTTP_REFERER 是危险的一个示例是在您的主页上显示实时更新的引用站点列表页面（“访问者来自...”），通过使用虚假的
HTTP_REFERER集访问您的网站，可以轻松地将任意 URL 偷偷添加到该列表中。There is no reason to avoid
HTTP_REFERER. Just when using it, be aware that it's not always set, and that it can be freely manipulated by the client, so it is untrusted data.The vast majority of clients sets the variable, and does so correctly.
The main reason for blocking it is privacy: For example, when opening an E-Mail in a web mail client, links to external images would carry the web mail service's address in the
HTTP_REFERERheader. That's why GMail and Yahoo make efforts to block it.The workaround you suggest works only for movements within the same site, and will break if the user has more than one tab/browser window open with which they browse your site. If you need to know the referring page, the superior method is to add a GET parameter like
Edit: One example where relying on HTTP_REFERER is dangerous would be showing a live-updated list of referring sites on your main page ("Visitors came from...") it would be easy to smuggle arbitrary URLs into that list by visiting your site with a fake
HTTP_REFERERset.HTTP 引荐来源网址可用于分析用户的行为，因为您可以看到引用当前页面的页面。它还可以向第三方站点公开敏感数据，例如 URL 中的会话 ID。这就是为什么许多网站使用 dereferrer 作为所有外部链接的单个退出页面。
这是某些用户代理根本不发送 HTTP 引用站点的主要原因。与此相反，仅当您实际点击链接或在页面上提交表单时才会发送 HTTP 引荐来源网址。以其他方式触发的任何请求（HTTP 重定向、通过位置栏/书签的直接请求）都不是引荐来源网址。
如果您在多个选项卡/窗口中打开一个网站，那么这样做将不起作用。您需要为每个页面请求提供一个标识符，以便您可以识别实际引用此页面的页面：
每个链接将包含请求 ID 来标识引用下一页的请求：
通过在表单上执行此操作，并另外使用不可预测的页面请求 ID 值，还可以使 CSRF 攻击变得更加困难。
The HTTP referrer can be used to profile a user’s behavior because you can see the page that referred to the current page. It can also unveil sensitive data such as a session ID in the URL to third party sites. This is why many web sites use dereferrer as a single exit page for all external links.
That are the main reasons why some user agents don’t send a HTTP referrer at all. In opposite to that, HTTP referrers are only send when you actually follow a link or submit a form on a page. Any request that was triggered otherwise (HTTP redirect, direct request via location bar/bookmark) is not a referrer.
Doing it that way won’t work if you have opened a website in multiple tabs/windows. You would need an identifier for each page request so that you can identify the page that actually referred this one:
Each link will then contain the request ID to identify the request that referred to the next page:
By doing this also on forms and by additionally using an unpredictible value for the page request ID you can also make CSRF attacks more difficult.
基于 Cookie 的解决方案不是最好的，也不是解决方案。
没有人使用它，因为 cookie 是一个站点范围的问题。
大多数时候“返回”链接毫无用处。每个现代浏览器都有一个后退按钮。
如果您无论如何都想实现它，只需按照在其他站点上实现的方式进行即可。
Cookie based solution is not the best nor the solution at all.
Nobody using it, because a cookie is a site-wide matter.
Most of time "go back" link is just useless. Every modern browser has a Back button.
If you want to implement it anyway, just make it the same way as it's implemented on the other sites.
如果您需要返回链接，您应该使用：
或者
这是向用户提供返回链接的最佳方式
If you need a go back link you should use this:
OR
This is the best way to provide a go back link to users
好吧，请记住，就像客户端设置的任何标头一样，它可以被篡改。所以要明智地使用它。
Well, remember that like any header the client sets, it can be tampered with. So use it wisely.
如果 Http 引荐来源网址未经清理而必须对您的网站数据库执行某些操作，则可能会很危险。它也完全是客户端，因此有人可以利用它。但除此之外并没有什么问题。
Cookie 也可以更改。如果您想要用户无法更改的内容，请使用 Php 会话。
Http referrer can be dangerous if it has to do something with your website database if not sanitized. It is also completely client side, so there is chance that someone can exploit it. But besides that there is nothing wrong with it.
Cookies can be changed too. If you want something that can not be changed by user go with Php Sessions.
嗯，网络浏览器确实没有理由不设置这个。您被告知要避免它，因为某些浏览器会避免它的原因相同，即滥用。就像在 URL 中保存重要的会话信息一样。
你不应该试图避免使用它，你应该负责任地使用它。并且不必使用任何“噱头”。例如，将其用作“恢复”导航是很常见的。例如，某人使用您的网页的会话已过期。您可以将它们发送到登录凭据页面。然后将它们重定向到请求的 URL。
当他们尝试首次访问您的网页而不通过登录屏幕时，情况也是如此。
您应该确保您在所有“限制区域”页面上检查有效会话。
Well, web browsers don't really have a reason not to set this. You've been told to avoid it because of the same reason some browsers would avoid it, wich is misuse. Like saving important session info in the URL.
You shouldn't try and avoid it using, you should just use it responsibly. And not have to use any 'gimmick'. For example, its very common to use it as a 'Resume' navigation. Say for instance someones session expired using your webpage. You could send them to the login credentials page. And then redirect them to the requested URL.
The same goes when they are trying to first access your webpage without passing through the login screen.
You should just make sure you check for a valid session on ALL of your 'restricted zone' pages.