问题描述
我希望有一个中央的，完全可定制的，开源的，通用的登录系统，它使您可以登录和管理所有在线帐户(也许有?)...
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
今天我开始构建一个Sinatra应用程序以登录到Google，Facebook，Twitter，Amazon之后，才发现 RPXNow ，OpenID和EventBrite，看起来它可以节省一些时间.
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
但是我一直想知道，不是身份验证专家，为什么我不能只有一个时尚的登录页面说输入用户名和密码，并检查您的登录服务"，然后在后台从 EventBrite 并以编程方式通过Mechanize提交表单，或者使用API(如果有的话)?如果他们不必经历弹出窗口和重定向并且可以使用任何以前存在的帐户，那么它将更加干净，并且用户体验也将更好.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
我的问题是:
- 我不应该那样做的原因是什么?
我对Cookie/会话/安全性的详细信息了解不多，因此，如果您可以进行描述或为我提供一些很棒的有用链接.谢谢！
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
我熟悉 OpenID 和API.我真的在想事情的安全性/法律性/保密性方面.我完全了解机密性部分，不知道是否有任何法律记录下来，但是假设它在ssl下，并且我不存储任何数据(将存储cookie和令牌)，那么对安全性有何影响?
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
推荐答案
如果我来到您的网站并给您我的gmail密码，那么我可以保证您不会阅读我的所有电子邮件，甚至不会发送一些电子邮件你自己?而且，如果您变得更聪明，说人们重复使用密码，那么我也可以尝试一下此密码是否适用于他的银行帐户".
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
作为用户，我不相信我的密码访问您的网站.期限.
Open Id和OAuth(这就是RPX所使用的)的重点是解决上述问题.我可以为您的网站授予对我的Facebook帐户的受限，可撤消和可配置的访问权限，而无须为您的网站提供我的facebook密码.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
用户界面令人困惑，我同意.但是随着时间的流逝，人们将了解它的全部内容，并且它将变得更好.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
这篇关于为什么我不应该以编程方式将用户名/密码提交给Facebook/Twitter/Amazon/etc?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！