服务器端用户代理检测是否不好?

31

8
我认为它更多是不可靠,而不是坏。 - Leigh
我认为这就是为什么你在每个UA字符串中看到“Mozilla”的原因。回答你的问题,我认为你应该提供选择,就像现在的网站一样:他们会重定向移动用户,但仍然提供让他们查看“正常”网站的选项。 - BiAiB
不要只考虑用户代理。浏览器的指纹分析,就像谷歌等公司所做的那样。 - jcolebrand
这整个问题可以通过阅读这个评论得出答案,也就是说... @Raynos,我认为你知道自己的答案...它有用...但由于其缺乏可靠性,我们不应该将其用于除统计跟踪之外的任何事情。 - rlemon
@rlemon 这个问题更多关于服务器端的 userAgent 处理,以及何时可以接受。我更想寻找相关的阅读材料。 - Raynos
@Raynos 啊啊啊。好的,我只是被你的问题弄糊涂了;因为看起来你已经很清楚我们为什么不应该使用它了。 - rlemon
3个回答

21
我认为这取决于你的动机。例如,在移动Web领域,您试图做的是为用户提供在其平台上看起来合理的东西。当纯粹为了他们自己的利益时,为什么要关心用户代理报告了什么?如果他们花费精力用不同的用户代理欺骗您,那么他们是唯一受害者。当然,主要问题是误报; 它并不完全可靠。
我赞成您不应该依赖它,但是移动开发人员正在受到像这样的通用声明的攻击。是的,有很好的替代方案,但在您可以想象的每个浏览器中,这些信息实际上可能在某些时候非常有用,因为确定性开始降低。
您绝不能使用任何纯文本标题来促进访问控制。
当有更好的替代方案时,用户代理检测被认为是不好的,但是在一个逐渐降低确定性的检测过程中包含它肯定没有伤害。
我对整个过程的问题在于我们陷入了为用户提供合理的东西的困境,但似乎从未认为询问是否可以接受。如果您对用户代理不确定,请为什么不问一次并存储?您可以使用用户代理作为指南。
因此,总结我的想法,用户代理标头不可靠,所以依赖它是不好的。这并不意味着您不能从中提取有价值的信息,而更可靠的选项则让您处于不确定的状态。一般来说,得出它是不好的结论是错误的。只是你用这些信息做什么使它变得好或不好。

更新

看到您对问题的更新后,我有以下评论要贡献。 我是否想要嗅探图像请求并基于用户代理向客户端提供图像?

如果这是唯一的变量,那么也许可以工作,但很少情况下您只会变化图像。我不想每个请求都进行检测,因为我想为客户端提供一致的解决方案。这意味着我为他们提供了一个页面,导致他们请求正确的资源。这个页面为所有集成资源产生一个单一的一致解决方案。此文档中的所有变化都适用于特定视图。

我尊重用户代理字符串在视图过程中更改的可能性非常小,似乎不值得担心。然而,采用这个原则也减少了需要执行浏览器/平台检测的次数,这只会有益无害。这使您可以更轻松地在客户端上切换视图。如果客户端说实际上您的视图是错误的,我是平板电脑而不是手机,您该如何进行更正?您为用户提供更好的页面,否则您将需要为您的图像请求欺骗标头...可怕的想法。不要使用用户代理字符串来提供通用资源,如图像

潜在的改进

平台识别是现代Web发展中非常活跃的领域。随着计算变得更加普及和平台变化更加广泛,我们需要了解所服务的平台的需求也越来越大。我认为当前条件下解决这个问题的一般解决方案将落在指纹识别和统计分析上。
考虑这个应用程序 - akinator.com - 注意到从大量稀疏数据的统计分析令人讨厌地准确。在有限的环境中(浏览器配置集),可以想象我们可以向客户端的浏览器提出一些问题。然后,在某个n维特征空间中对响应进行统计分析。将用户代理作为此空间的一个维度将是有用的,并且具体取决于您发现的结果,它将自我限制。如果它大部分不准确,则会看到大幅度的扩散,并且您从中获得的价值将是自我限制的。
当然,从这种统计模型中获得任何价值的能力需要您能够获得一些验证过的真相。例如,这可以是运行JavaScript测试套件以检测客户端js功能,或者确实在不确定性中,您可以要求用户告诉您他们的平台是什么。
------- 如需进一步阅读,我建议您参阅Mozilla的这篇文章

https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent

今天,在提供HTML之前,查找这些字符串是了解设备是否在移动设备(或平板电脑)上运行的唯一方法。

实际上,阅读您的统计方法(顺便说一句,这是一种非常常见且完全可行的方法),我意识到最正确的策略是_详尽的测试套件_:对于每个浏览器版本,将其提交给完整的标准测试,并使用此来构建足以进行测试的签名。从那些签名中构建一个搜索树来分支和最小化每个客户端的检测数量。这需要用户启用他们所有的功能(例如允许Javascript运行),但简单的提示就足够了。 - MrGomez
关于您建议询问用户的问题,我不认为这是普遍适用的。已修改其用户代理的用户与那些在直接提示下会“明确撒谎”的用户之间的重叠足以舍弃考虑此类系统。尽管如此,在抽象意义上,值得考虑的情况是无法确定用户代理的情况 - 例如,当代理网关位于用户和请求的页面内容之间时。因此,这是可行的,但我认为其能力更加有限。 - MrGomez
我的担忧关于统计方法不仅限于用户代理检测机制的通常考虑因素。假设我有一个详尽但昂贵的测试套件,我想用它来识别一组必要的客户端填充,例如。在客户端运行此套件是用户成本的开销。统计方法假定准确地获取了一小部分可用信息(包括用户代理字符串),可以显著减少检测时间。 - Matt Esch
同意。如果我们将详尽方法中的检测泛化,并执行简单的贝叶斯推断,我们可以很快、有效地得出指纹识别解决方案。哦,多么有趣啊!某个地方应该有人开始着手研究这个问题了。 - MrGomez
1
我不假设浏览器提供的任何数据的性质或价值。我利用客户端上运行的准确、真实识别测试套件的可用性,以及一些易于识别的信息部分来生成一个统计模型,该模型在价值方面自然而然地得到纠正。我还可以以一定的统计精度得出结论,我已经正确地识别了这个用户代理的能力的机会。随着时间的推移,对测试套件的依赖程度降低,可靠的模型从真实世界的数据中建立起来。 - Matt Esch
2
(是的,我们现在需要这个。) - Matt Esch

4
这要看情况。仅使用user agent作为分支服务器级代码逻辑的唯一信号,最好是可疑的,最坏的情况下是不安全的,但如果提供基本代理,则可以定义特定类别浏览器的基本功能并提供相应内容以满足其需求。

你所描绘的场景是这种情况的完美说明。在服务器级别上尝试检测移动浏览器并降低发送给它们的内容是完全合适的,因为你正在尝试根据他们的需求调整用户体验(例如,通过提供较小的图像和更好的内容流以适应较小屏幕的限制),同时平衡服务器的需求(发送较小的图像,从而减少负载和带宽)。这种策略只需要改进。

这里有一些设计原则,你应该始终遵循,以确保你的用户代理检测实践不会被你的用户视为可疑:

  • 始终提供查看网站完整版本的功能,并相应地规划您的负载配置文件。否则,人们会试图通过更改代理来规避此问题。

  • 始终在创建模态视图时清楚定义网站内容的修改。这将消除您可能已经进行或未进行的任何FUD的疑虑。

  • 始终提供到替代版本网站的路径。例如,使用类似http://mobile.example.org的东西来迁移人们到移动版本,做出设计层面的假设,即当请求该路径时,您的受众已经明确要求。

  • 奖励用户为您提供正确的代理凭据,通过为他们提供更好的内容和性能体验来回报他们。当您预见到他们的需求并为他们浏览的网站版本提供更快的性能时,用户会更加满意。

  • 避免滥用和手动重定向模式。例如,当您检测到用户正在运行iOS时,不要使用大而笨重的弹出广告来阻止他们使用您的移动应用程序。(诚然,这是我个人的烦恼。)

  • 永远不要基于用户代理限制网站的访问权限(而是选择严厉警告用户如果他们离开轨道会发生什么,并围绕此起草您的支持政策)。例如,我们中的许多人都很喜欢为“最适合在Internet Explorer中使用”的网站更改代理,以防止其他浏览器。如果可以避免,您不应成为这种不良实践的又一个例子。

简而言之:提供正确的用户代理是用户的决定。 您可以使用此功能为选择运行其客户端纯净香草或不知道更好的用户定义默认体验。这里的目标是通过给予用户所需的选项和所需的体验来奖励您的用户,同时平衡他们的需求和您自己的需求,从而避免提供虚假用户代理。任何超出这个范畴的尝试都会让他们感到犹豫不决,并因此被视为极不可信。
您当然可以尝试通过其他方式来检测浏览器但这仍然是一个开放的研究领域。浏览器能力和指纹随着它们在功能上的竞争而改变,并且试图追赶优化性能通常是棘手的,目前还没有解决方案。

我同意这个答案中对于使用统计分析的观点,因此请不要误解我的意思。但是,作为一个在这个领域积极工作的人,我可以告诉你并没有什么神奇的方法可以给你完美的分类确定性。然而,启发式算法可以帮助你更有效地平衡负载,为此,一旦你明确定义了可接受的错误率,浏览器询问策略可以对你有所帮助。


2
在“标准浏览器”情况下,它并不差,但由于许多浏览器为用户提供一些配置选项/插件/其他内容来修改用户代理,因此它并不可靠。
在这种情况下,我会实现类似于 Facebook 的东西 - 根据 UA(可能还有其他东西,即“指纹分析”)检测是否重定向到移动版本(即 http://m.facebook.com/...)或不重定向(即 http://www.facebook.com...)。同时,他们提供了一个 URL 参数 m2w,可以覆盖此重定向机制。
根据移动运营商的不同,甚至可能会发生他们拥有某些内容感知代理/缓存,可以在您的终端上以“正常”的浏览器形式进行图像缩放/重新压缩...
考虑浏览器外的情况...例如,如果您正在提供某些特定的协议(如 WebDAV),这可能是唯一的选择,以具有某种“特定于平台”的行为(例如 OS X 和 Windows 之间的区别)。

重定向到移动版本或拥有单独的移动网站是已知的反模式和不好的例子 ;)。 - Raynos
@Raynos 我不完全同意,但唯一的选择是检测客户端(不是用户代理,而是基于JavaScript的功能检测),并通知服务器已发现哪些能力... - Yahia
1
移动端的最佳选择是媒体查询、渐进增强和响应式设计。 - Raynos
1
@Raynos 近年来,许多移动浏览器都具备了 JS 功能,并且 CSS 媒体查询无法检测到所有相关功能 - 因此,在我看来,“真正的选择”是两者的结合。 - Yahia

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接