我正在尝试决定如何允许用户注册我的网站...有 openID、clickpass、facebook connect、google friend connect 等，或者是老式的内部“输入用户名、电子邮件、密码等。”
简要了解如何设置 OpenID似乎需要做很多工作才能使 openID 正常工作。
有没有人有为 OpenID（或其他）设置站点的经验？另外，有谁知道这些方法的注册周转率是否比经典的“内部”注册更高？例如.. 如果您同时允许内部注册和 openID，那么您的用户中有多少百分比正在使用 OpenID？
一如既往，感谢您的意见。
It really depends on the type of site and who your users are.
We looked at the possibility of using OpenID for our e-commerce store (we sell apparel), and the conclusion was that we would be flat out nuts to implement it. I'm not the smartest software developer in the world by any means, but if I could barely wrap my mind around it enough just to get an account for StackOverflow (Why do I have to go to some third party provider? Why should I trust them? What happens to my account if they go under? As a business, what do I do if a customer asks me to reset their password?), then it's not just anecdotal to say that our customers would have problems with it. In addition, for any e-commerce business, it's usually unwise to take on a third-party dependency unless carefully considered, and especially for something as critical as logging in. If a major OpenID provider were to go down, you'd be losing sales. If we implemented OpenID, it would definitely be an alternative, red-headed step child implementation when compared to the native sign in mechanism.
Even with our in-house registration of e-mail addresses and passwords, we had to use an Amazon.com style login form because users kept filling out the "new customer" form even when they already had an account:
Login screen. Amazon's sign-in screen remains a model to be emulated, minimizing the common problem of new customers who try to log in without having registered. Amazon presents two questions in linear order: (1) "What is your email address?" and (2) "Do you have an Amazon.com password?" For the second question, users can select one of two radio buttons: "No, I am a new customer," or "Yes, I have a password." Many other sites present the new- and established-user sections side-by-side, and thereby divert new users to the established-user section through the magnetic attraction of type-in fields. -- Jakob Niesen, useit.com
When users have trouble navigating two fields and a radio button, you can imagine the hilarity that ensues when they are presented with multiple authentication mechanisms.
If you're implementing a social-oriented Web site that is designed to integrate with Facebook or some of the Web-2.0-savvy consumers, then these alternative authentication mechanisms may make sense. Until the dust settles on OpenID, though, I wouldn't add it to a commercial site: nobody has asked for it. They have asked for PayPal and Google Checkout, which we implemented, but there's only a small amount of overlap there.
My general recommendation would be to have the usual in house username and password mechanism that can be supplemented by these alternative identification mechanisms. But realize that each alternative identification mechanism runs the risk of customer confusion and increased customer support.
Just my two cents; hope that helps.
@Nicolas 有一些非常好的观点。
我建议从标准用户名/密码开始，如果有足够多的用户要求，稍后添加 OpenID 等作为选项（就像 Plaxo 教程一样）。
现在拥有一个工作站点总是更好，而不是一个项目以 90% 的成绩被罐头。:-)
简要了解如何设置 OpenID 似乎需要做很多工作才能使 openID 正常工作。
这真的不是很多工作。对于一个还没有接近公开的项目，我下载了Dope OpenID，在玩了几个小时（大部分时间花在做我非常讨厌的 CSS/HTML 工作）之后，我有了一个看起来和工作起来都像你的登录程序设置登录到 SO 时查看。
例如.. 如果您同时允许内部注册和 openID，那么您的用户中有多少百分比正在使用 OpenID？
现在，当您可以将 yahoo、AIM 和 GMail 登录用作 OpenID 时，创建您自己的用户验证真的没有什么意义，并且不必担心是否正确地加盐哈希，以及如果用户未能登录 3 次/秒应该被禁止几分钟，当用户忘记密码时恢复密码等。
当然，您也可以提供一个普通的登录名，但是您仍然必须携带 OpenID 从您的肩上举起的所有好东西。要求用户注册他们可以使用的 gmail 或 yahoo 帐户并不可怕，他们中的大多数人可能已经拥有一个。
If you will need to maintain state information about your users (preferences and such) then you probably should provide your own user/password mechanism. This does not stop you from allowing users to take advantage of OpenID and its ilk. The question you need to answer is how much time should you devote in your project to supporting more than one method. Like all design decisions, there is a cost and a benefit to everything. Weight them both and pick the answer that fits your budget.
另一个可能的选择是使用像RPX这样的 SaaS 服务，而不是自己使用库来编写 OpenID 代码。您可以在几个小时内获得 OpenID、facebook 和 myspace 登录。您的应用只需要能够生成 HTTPS 并解析 JSON 或 XML 响应。
我打算在我的社交网站上做一些类似的事情，但与其他网站做的有点不同。大多数网站允许用户使用这些服务登录，我计划将这些服务添加到我的注册表单中，然后他们选择服务、openID、facebook connect、myspace ID，然后我打算做的是获取这些服务提供的所有信息和将它们作为变量存储在我的 php 脚本中，然后保存到 DB，其概念是允许他们在注册时从其他服务导入信息，以使他们更容易注册，这意味着他们以后必须填写的配置文件字段更少，并且这样的