DotNetOpenAuth / WebSecurity 基本信息交换

Question

我现在在我的网站上进行了大量的 OAuth 登录。我的实现基于 WebSecurity 类，并根据我的需要修改了代码（我将 WebSecurity 源代码提取到我的）。

但是，我现在面临着一系列新问题。在我的应用程序中，我选择将用户电子邮件地址作为选择的登录标识符。它自然是独一无二的，适合这个用例。

然而，OAuth“标准”又来了。

有些提供商会将您的电子邮件地址作为“用户名”(Google) 返回，有些提供商会返回显示名称 (Facebook)。就目前而言，鉴于我的特定情况，我看到了两个选项：

选项 1 将更多框架源代码提取到我的解决方案中，直到我可以追查 OpenIdRelyingParty 类实际交互的位置（通过 DotNetOpenAuth.AspNet 外观）并从 OpenID 提供程序发出附加信息请求。

选项 2 当用户首次使用 OpenID 提供程序登录时，我可以显示一种“完整注册”表单，该表单根据所选的提供程序请求缺少的信息。*

选项 2 是最直接的，也可能是最快的实现方式，但也包含一些代码异味，因为必须根据所选的提供者执行不同的操作。

选项 1 将花费更长的时间，但最终会使事情更具未来性。我将需要执行更丰富的交互，因此这在这方面也具有优势。

我对代码的了解越多，WebSecurity 类本身实际上就非常受限制，因为它以简化集成的名义隐藏了许多有用的 DotNetOpenAuth 功能。

Andrew（DNOA 的作者）说属性交换的东西发生在 OpenIdRelyingParty 类中，但我无法从 DotNetOpenAuth.AspNet 源代码中看到使用此类的位置，所以我不确定需要什么源拉入我的代码以启用我需要的功能。

有没有人完全类似的东西？

Answer 1

AttributeExchange 仅适用于 OpenID 提供程序（Google 和 Yahoo!），您可以查看它们各自源文件中使用的扩展名。

我建议不要使用电子邮件地址作为用户名。电子邮件地址可以回收（帐户可以过期或关闭/取消，并且可以将电子邮件地址重新分配给新用户）。如果发生这种情况，您基于电子邮件地址的网站会将旧用户的所有数据“泄露”给新用户。大规模的隐私侵犯和诉讼可能在那里发生。在 OpenID 案例中使用声明标识符或在 OAuth 案例中使用服务提供商特定的用户 ID 号作为用户表中的主要标识符要好得多。当然，您可以在网站上的任何地方捕获并显示电子邮件地址将显示用户名，只要用户知道那是用户名——只是在内部你使用了比这更精确的东西.