9

我已经阅读了其他问题，他们大多谈论这样做的安全性。这并不完全是我关心的问题，主要是因为该网站的问题是基于浏览器的游戏。然而，更大的问题是用户 - 并不是每个用户都有足够的文化来理解 OpenID。当然，RPX 使这很容易，这就是我将使用的，但是如果用户没有 Google 或 Facebook 或其他任何帐户，或者不信任系统使用现有帐户登录怎么办？他们必须在另一个提供的帐户上获得一个帐户-我相信大多数人都会知道该怎么做，更不用说费心去做了。

还有一个问题是如何在应用程序中管理它。一个用户可能想用一个账户使用多个身份，所以处理起来并不像用户名+密码那么简单。如何在数据库中存储用户的 OpenID 身份？使用 OpenID 也给了我一个好处：RPX 可以提供广泛的个人资料信息，因此我可以预先填写个人资料表格并要求用户根据需要进行编辑。

我目前有这个：

Users:
------

ID     Email              Etc.
--     ---------------    ----
0      bob@yahoo.com      ...
1      alice@yahoo.com    ...

UserOpenIDs:
------------

ID     UserID     OpenID
--     ------     ------
0      0          0
1      0          2
2      1          1

OpenIDs:
--------

ID     Provider   Identifier
--     --------   ----------------
0      Yahoo      https:\\me.yahoo.com\bob#d36bd
1      Yahoo      https:\\me.yahoo.com\alice#c19fd
2      Yahoo      https:\\me.yahoo.com\bigbobby#x75af

使用这些外键：

UserOpenIDs.UserID -> Users.ID
UserOpenIDs.OpenID -> OpenIDs.ID

这是在数据库中存储 OpenID 标识符的正确方法吗？我如何将 RPX 给我的标识符与数据库中的一个匹配以登录用户（如果标识符已知）。

所以这里有一些具体的问题：

  • 如何让没有 OpenID 或不想使用 OpenID 的用户可以访问它？（例如，使用他们的 Google 帐户登录的安全问题）
  • 如何将标识符存储在数据库中？（我不确定上面的表格是否正确）
  • 我需要采取哪些措施来防止某人以其他用户身份登录并愉快地使用他们的帐户做任何事情？（据我了解，RPX 通过 HTTP 发送标识符，所以任何人都需要做的就是以某种方式获取它，然后在“OpenID”字段中输入它）
  • 使用 OpenID 时我还需要注意什么？
4

3 回答 3

4

使其可访问

首先对于没有 OpenID 的用户，您可以制作一个小页面来解释如何创建帐户（甚至指向某些提供商）。这样，创建 OpenID 帐户并不比普通帐户难。

对于不想使用 OpenID 的人，您有两个选择。第一个：在您的 OpenID 登录旁边实现旧式登录，让用户选择他们想要的方法。第二个是只有 OpenID ......这简化了你的工作。说一些用户比受信任的 OpenID 提供商更信任网站来登录，我认为这很奇怪，因为 OpenID 提供商经常使用加密连接等......

存储在数据库中

johnny g提出的模式正是您所需要的。（我只是不知道你为什么用反斜杠而不是斜杠来存储 URL）

您可能希望在使用 URL 之前对其进行规范化，这样您就可以避免将http://openid.test.com/abc和http://openid.test.com/abc/等内容作为不同的 URL 处理。

采取的额外措施

没有任何。您应该只使用来自http://openid.net/developers/libraries的库。

用户身份的确认是提供商的问题。只有用户和网站知道该帐户的密码。

如果有人有你的 OpenID URL （这是公开的），他仍然需要密码（或另一种身份验证方法，如 SSL 证书）才能登录。

于 2010-04-19T15:30:51.417 回答
3

Arg，回答我之前的评论。

对于您的第三个问题“措施......以防止某人以另一个用户身份登录......”，据我了解 OpenId，您永远不会接受来自不受信任来源的 OpenId Url。在实施中，您的站点托管提供商的登录信息，提供商的站点直接与您联系，因此您始终接受来自受信任站点的 OpenId Url。

换句话说，即使恶意用户像 Pokemon 一样收集 OpenId，他们也无法访问您的系统。

对于您的第二个问题“我如何存储...”，您的架构将起作用，尽管它看起来有点放松。例如，通过使用多对多映射 [ie UserID to OpenID]，您允许一个用户属于多个 OpenId，而一个 OpenId 属于多个用户。你想要前者而没有后者。

一个简单的外键约束就足够了。

UserID     Email        
------     --------------- 
86000      bob@yahoo.com 
86001      alice@yahoo.com 

UserID     Identifier 
------     ---------------- 
86000      https:\\me.yahoo.com\bob#d36bd 
86000      https:\\me.yahoo.com\bigbobby#x75af 
86001      https:\\me.yahoo.com\alice#c19fd

提供表UserID的外键Users并且 上存在唯一键约束Identifier，这实质上表明 aUser拥有零个或多个唯一Identifiers。原则上，我可能也会在该表上添加一个主键，但那是肉汁。

希望这可以帮助 ：）

PS如果您对集成或利用 OpenId 有疑问，请逐步执行。确定接收 OpenId Url 的每一点源，然后问问自己是否有可能让恶意用户访问该入口点。我希望只有一个这样的入口点，除了受信任的 OpenId 提供者之外，每个人都无法访问它。

于 2010-04-08T17:54:49.670 回答
-1

我注意到第一个问题的答案：

如果用户不能或不想使用 OpenID，请与现有提供商合作并直接在网站上注册，或者自己成为提供商（尽管这也意味着拥有经典的用户名 + 密码帐户，并且有点错过问题的重点-> 仅使用 OpenID）。

于 2010-04-08T17:25:47.847 回答