在 PHP 中创建唯一用户指纹的方法
在 PHP 中生成用户唯一性“指纹”的最佳方法是什么？
例如：
- 我可以使用用户的 IP 地址 然而，作为“指纹”， 是同一 IP 上的多个其他用户
- 可能 使用用户的IP+用户代理作为 然而，“指纹”是单个用户 可以简单地从 Safari 切换到 firefox 再次被视为独特的
理想情况下，指纹因此标记“机器”而不是浏览器或“ip”，但我无法想象这是如何实现的。
接受有关如何唯一地识别用户的想法/建议，以及您的方法有哪些优点/缺点。
What is the best way to generate a 'fingerprint' of user unique-ness in PHP?
For example:
- I could use a user's IP address
as the 'fingerprint', however, there
could be multiple other users on the same IP - I could
use the user's IP + user agent as
the 'fingerprint', however, a single user
could simply swap from safari to
firefox and again be seen as being unique
Ideally, the fingerprint so label the 'machine' rather than browser or 'ip' but I can't think of how this is achievable.
Open to ideas/suggestions of how you uniquely identify your users, and what advantages/disadvantages your method has.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
最简单和最好的方法：使用 phps 会话管理 - 每个客户端都是给定一个 ID，存储在 cookie 中（如果启用）或作为每个链接和表单上的 get 变量给出（或者您可以自己设置 cookie）。但是，这只是浏览器的“指纹”——如果用户更改浏览器、删除 cookie 或其他任何内容，您将无法再识别它。
通过 IP 地址识别每个客户端通常是个坏主意，而且行不通。使用同一路由器的客户端将具有相同的 IP 地址 - 通过代理池连接的客户端在每次页面加载时可能会具有另一个 IP 地址。
如果您需要一个无法由客户端以简单方式操作的解决方案，请尝试执行以下操作的组合，使用客户端浏览器支持的所有内容，并在每个页面加载时对它们进行比较：
有一个名为 evercookie 的解决方案，它实现了所有的这个。
Easiest and best way: use phps session-management - every client is given an ID, stored in a cookie (if enabled) or given as a get-variable on every link and form (alternatively you could set a cookie on your own). But, this only "fingerprints" the browser - if the user changes his browser, deletes his cookies or whatever, you can't identify it anymore.
Identifying every client by IP address is usually a bad idea and won't work. Clients that use the same router will have the same IP addresses - clients connected through a proxy-pool could have another IP address with every page load.
If you need a solution that can't be manipulated by the client in an easy way, try to do a combination of the following, using all that are supported by the clients browser and compare them on each page-load:
There's a solution called evercookie that implements all of this.
还有其他一些事情需要考虑，用户的公共 IP 地址在每次页面加载时也可能会发生变化。
有多个组织在其路由器中交换公共 IP 以平衡流量。
There's something else to take in account, the public IP Address of a user is something that also can change in every page load.
There are multiple organizations that switch public IP's in they routers to balance traffic.
不能保证达到 100% 的可靠性，但结合一些常用方法可以给您带来有意义的结果
采取最简单可行的路线，并在必要时随着时间的推移进行调整。
Achieving 100% reliability is not guaranteed, but combining some common methods can give you meaningful results
Take the simplest possible route that could work and adjust over time if it seems necessary.
我有三台不同的计算机、各种手持设备，其中许多安装了不同的浏览器。我在家里交替使用所有这些，并将它们带到其他地方，所以基本上，在不同的 IP 地址上。我想指出的是，如果您的目标是阻止某人，那么对浏览器或机器进行指纹识别永远不会是万无一失的。
我建议您采取不同的方法。根据您所掌握的非决定性信息来判断您被禁止的用户的身份（如果是不常见的情况，则为相同的 IP 或相同的用户代理，或者一些 javascript 浏览器指纹识别方法，例如可用字体、可用插件、非标准窗口大小等），并要求那些可疑的访问者进行某种更高形式的身份验证——例如使用 Facebook、Google+ 或 Twitter 进行 oauth。然后您可以查看该社交媒体帐户是否真实，或者只是为了规避而创建的。还有电话验证 API，以防您的用户群不熟悉社交媒体，并且取决于用户不规避禁令对您的价值有多大。
I have three different computers, various handheld devices, and many of them have different browsers installed. I use all these interchangeably at home take them with me other places so, basically, on various IP addresses. What I'm trying to point out is that fingerprinting a browser or a machine for that matter is never going to be foolproof if your goal is to block a person.
I recommend you take a different approach. Judge based on the inconclusive information you have available that suggests the identity of your banned user (same IP or same user-agent if it's a uncommon one or else some of the javascript browser fingerprinting methods such as available fonts, available plugins, non-standard window size, etc.) and require of those suspect visitors some higher form of identity verification -- such as oauth with Facebook, Google+, or Twitter. Then you can look to see if that social media account is genuine or created just to circumvent. There are also phone verification APIs in case your user base isn't social-media savvy and depending on how valuable it is to you that users don't circumvent banning.