每一个OpenID提供商都有提供URL（如谷歌： https://www.google.com/accounts/o8/ ID ）

Every OpenId provider has a provider Url (e.g Google: https://www.google.com/accounts/o8/id)

使用 OpenIdRelyingParty.CreateRequest 我成功地设法将用户重定向到谷歌提供地址和接收供应商的回调。一切运行良好。

Using OpenIdRelyingParty.CreateRequest I successfully managed to redirect the user to Google provider Url and receive the provider callback. Everything worked fine.

现在我想实现我自己的简单的OpenID提供商（我想，作为谷歌在我的例子）。 DotNetOpenAuth有一个供应商的演示叫OpenIdProviderWebForms。在过去的4或5个小时里，我一直在tryng使用相同的演示中，我成功地连接到谷歌来连接它。第一：这我不清楚，我应该叫什么URL。我想所有的URL（server.aspx，provider.ashx ...），他们都触发异常没有OpenID的端点上找到。所有的配置似乎就好了。

Now I'm trying to implement my own simple OpenId provider (I want to act as Google on my example). DotNetOpenAuth has a provider demo called OpenIdProviderWebForms. For the last 4 or 5 hours I've been tryng to connect to it using the same demo I managed to connect on Google. First: It's not clear to me what URL should I call. I tried all Urls (server.aspx, provider.ashx...) and all of them trigger an exception "No OpenID endpoint found". All the configurations seems to be just fine.

我如何实现一个简单的OpenID提供商？什么网址我应该叫 OpenRelyingParty.CreateRequest ？

How do I implement a simple OpenId provider? What URL should I call in the OpenRelyingParty.CreateRequest ?

推荐答案

首先，让我们建立一些术语：

First let's establish some terms:

在用户提供的标识符是触发OpenID查找用户实际类型（或通过单击RP一predefined按钮触发）的字符串发生。这是不正常的，这不应该被用来重新present用户在你的数据库，因为它是不安全的或独特的，但它是一个必要的起点。发现在这个标识符yeilds是声称标识符或 OP标识符。例如：yahoo.com，myopenid.com，andrewarnott.myopenid.com

The User-supplied identifier is the string that the user actually types in (or is triggered by clicking a predefined button at the RP) that triggers OpenID discovery to take place. It is not normalized, and should never be used to represent the user in your database because it is not secure or unique, but it is a necessary starting point. Discovery on this identifier yeilds either a claimed identifier or an OP Identifier. Examples: yahoo.com, myopenid.com, andrewarnott.myopenid.com

在声明的标识符是OpenID的标识符，用户控制或使用他的身份。它可能会或可能的没有的是一个URL（它可能是一个XRI）。从OP积极的断言将永远是一个声称标识符（即使发现开始的OP标识符）。例如： https://andrewarnott.myopenid.com/

The Claimed Identifier is the OpenID Identifier that the user "controls" or uses as his identity. It may or may not be a URL (it may be an XRI). A positive assertion from an OP will always be a claimed identifier (even if discovery started with an OP Identifier). Examples: https://andrewarnott.myopenid.com/

在 OP标识符，或的OpenID提供商的标识是OpenID的标识符的责任方还可能执行发现，要开始标识符选择流，其中RP还不知道该用户的身份标识会。例如： https://me.yahoo.com/ ，的 http://www.myopenid.com/ 和 https://www.google.com/accounts/ O8 / ID

The OP Identifier, or "OpenID Provider Identifier" is the OpenID Identifer that RPs may perform discovery on to begin an identifier select flow where the RP does not yet know what the user's Claimed Identifier will be. Examples: https://me.yahoo.com/, http://www.myopenid.com/ and https://www.google.com/accounts/o8/id

在 OP终点的是，RP用户重定向到以验证用户实际的URL，并用于建立共享的协会或执行的直接验证断言，采用了OP私人协会。例如： HTTP：//localhost/server.aspx ， HTTP： //localhost/provider.ashx ， https://www.google.com/accounts/o8/ud （注意结尾，而不是ID的UD）

The OP Endpoint is the actual URL that the RP redirects the user to in order to authenticate the user, and is used to establish shared associations or perform direct verification of an assertion that uses an OP private association. Examples: http://localhost/server.aspx, http://localhost/provider.ashx, https://www.google.com/accounts/o8/ud (note the ud ending instead of id)

因此​​，所有这样的背景下，你的 OpenIdRelyingParty.CreateRequest 通话应该得到一个用户提供的标识符，它也可以是声称标识符或者OP标识符。它应该的没有的是OP的端点。因此，例如，你可能会传递：

So with all that background, your OpenIdRelyingParty.CreateRequest call should receive a user-supplied identifier, which may also be a claimed identifier or an OP Identifier. It should not be the OP endpoint. So for example, you might pass in:

openIdRelyingParty.CreateRequest("http://localhost/sampleop/")

或

openIdRelyingParty.CreateRequest("http://localhost/user.aspx?username=bob")