我是否应该根据协议前缀来区分 OpenID？ http 与 https
我使用 DotNetOpenAuth 为我的 ASP.NET 应用程序实现了简单的 OpenID 支持。但我最近意识到，与 https://johndoe.example.com 相比，该实现将 http://johndoe.example.com/ 视为不同的用户。
这导致不少用户感到困惑。我不确定此时该怎么办。 这是一个错误还是一个功能？
事实上，我可以将此行为视为一个功能：如果用户指定 HTTPS，则用户可能不希望系统首先接受 HTTP 身份验证。
另一方面：如果用户完全出于无知而指定 HTTPS（临时 Web 访问者对“S”部分的用途一无所知），那么拒绝其身份验证尝试就会令人困惑。
什么被认为是最佳实践？
I have implemented a straightforward OpenID support for my ASP.NET app with DotNetOpenAuth. Yet I recently realized that the implementation was treating http://johndoe.example.com/ as a distinct user compared to https://johndoe.example.com.
This lead to quite a few confused users. I am unsure what to do at this point. Is this a bug or a feature?
Indeed, I can consider this behavior as a feature: if the user specifies the HTTPS, the user might not want the system to accept HTTP auth in the first place.
On the other hand: if the user specifies HTTPS out of sheer cluelessness (the casual web visitor is clueless concerning the purpose of the "S" part), then rejecting it's authentication attempt is confusing.
What is considered as the best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的 - 它们完全不同，应该如此对待。
OP 的建议是始终使用 https，但情况并非总是如此（现在）。
Yes - they are completely different and should be treated as so.
The recommendations to OP's is to always use https but that isn't always the case (just now).
理论上，http 和 https 身份可能不同。实际上（正如现实世界中的提供商所实施的那样）它们不应该是这样。
StackOverflow 不区分 http://abdullin.myopenid.com 和 https://abdullin.myopenid.com，因此该解决方案可能适用于 99% 的场景。
Theoretically http and https identities could be different. Practically (as implemented by the providers in the real world) they shouldn't be.
StackOverflow does not differentiate between http://abdullin.myopenid.com and https://abdullin.myopenid.com, so the solution should probably work for the 99% scenarios.