Не удается получить атрибуты из ответа DotNetOpenId

Я пытаюсь выяснить, как получить информацию о пользователях после проверки через открытый идентификатор. Неважно, предоставляю ли я ClaimsRequest или FetchRequest всякий раз, когда я звоню

response.GetExtension<ClaimsResponse>

//Or

response.GetExtension<FetchResponse>

//Or

response.GetUntrustedExtension<ClaimsResponse>

// OR

response.GetUntrustedExtension<FetchResponse>

Я всегда получаю нулевую ссылку. Я добавляю информацию, как и во всех примерах, которые я видел, вот так:

request.AddExtension(new ClaimsRequest{ Email = DemandLevel.Require });

// Or

var fetch = new FetchRequest();
fetch.Attributes.AddRequired(WellKnownAttributes.Contact.Email);
request.AddExtension(fetch);

Любая идея, что я делаю неправильно?

Обновить

Добавление информации о конфигурации, предложенной Эндрю, частично помогло мне. Наконец-то я получаю ClaimsResponse с response.GetUntrustedExtension<ClaimsResponse>, однако response.GetExtension<ClaimsResponse> по-прежнему возвращает значение null. Также возвращенный ClaimsResponse на самом деле не содержит никаких данных, которые я запросил. Вот запрос:

var request = openId.CreateRequest(Request.Form["openid_identifier"]);
request.AddExtension(new ClaimsRequest
    {
        BirthDate = DemandLevel.Request,
        Country = DemandLevel.Request,
        Email = DemandLevel.Require,
        FullName = DemandLevel.Request,
        Gender = DemandLevel.Request,
        Language = DemandLevel.Request,
        Nickname = DemandLevel.Request,
        PostalCode = DemandLevel.Request,
        TimeZone = DemandLevel.Request 
      });

      return request.RedirectingResponse.AsActionResult();

Вот моя конфигурация

  <uri>
    <idn enabled="All"/>
    <iriParsing enabled="true"/>
  </uri>
  <dotNetOpenAuth>
    <openid maxAuthenticationTime="0:05">
      <relyingParty>
        <security
                    requireSsl="false"
                    minimumRequiredOpenIdVersion="V10"
                    minimumHashBitLength="160"
                    maximumHashBitLength="256"
                    requireDirectedIdentity="false"
                    requireAssociation="false"
                    rejectUnsolicitedAssertions="false"
                    rejectDelegatingIdentifiers="false"
                    ignoreUnsignedExtensions="false"
                    privateSecretMaximumAge="07:00:00" />
        <behaviors>
          <add type="DotNetOpenAuth.OpenId.Behaviors.AXFetchAsSregTransform, DotNetOpenAuth" />
        </behaviors>
      </relyingParty>
    </openid>
    <messaging>
      <untrustedWebRequest>
        <whitelistHosts>
          <!-- since this is a sample, and will often be used with localhost -->
          <add name="localhost" />
        </whitelistHosts>
      </untrustedWebRequest>
    </messaging>

I'm running v3.2.0.9177


person Micah    schedule 04.07.2009    source источник
comment
Можете ли вы указать, какой OP вы тестируете?   -  person Andrew Arnott    schedule 05.07.2009
comment
Конфигурация поведения приведет к тому, что ClaimsResponse всегда будет присутствовать, даже без каких-либо значений, как вы говорите. Похоже, ваш код правильный, и, поскольку myopenid поддерживает как sreg, так и AX, я удивлен, что это не работает для вас. Я посмотрю, смогу ли я провести дополнительное расследование.   -  person Andrew Arnott    schedule 05.07.2009
comment
Я добавил комментарий о тестировании на myopenid.com специально к моему ответу, поскольку я предполагаю, что это то, с чем вы столкнулись. Также просто совет: тег безопасности, который вы добавили в свой файл web.config, не нужен, если вы оставили его дословно, как это было на странице вики. Это все значения по умолчанию. Единственные существенные изменения, которые я вижу здесь, заключаются в том, что вы добавили «localhost» в качестве хоста в белый список и поведение, о котором мы говорили.   -  person Andrew Arnott    schedule 06.07.2009


Ответы (1)


Вполне может быть, что провайдер, с которым вы тестируете, не поддерживает эти расширения. Или, если это Google, он отвечает на вопрос только один раз (если только при входе в систему вы не будете не оставлять установленным флажок «Запомнить меня»).

Теперь с DotNetOpenAuth v3.2 лучшим способом отправки расширений, вероятно, является использование нового расширения атрибута «поведение». Он будет автоматически использовать sreg и/или AX (до трех различных форматов AX) в зависимости от провайдера, чтобы максимизировать ваши шансы на получение полезного результата, если провайдер вообще поддерживает какое-либо из этих расширений.

Вставьте этот бит в свой файл web.config, где это предлагается на вики-странице с полной конфигурацией .

<behaviors>
    <add type="DotNetOpenAuth.OpenId.Behaviors.AXFetchAsSregTransform, DotNetOpenAuth" />
</behaviors>

Затем используйте ClaimsRequest/ClaimsResponse (sreg) вместо AX' FetchRequest, чтобы поведение могло выполнять свою работу.

Поскольку вы упомянули, что тестируете myopenid.com, я также сообщу, что, похоже, они отключили поддержку расширений, когда вы тестируете RP, который находится на «localhost». Ваш RP, по-видимому, должен быть общедоступным и, возможно, даже доступным для обнаружения (в соответствии с правилами OpenID 2.0 для обнаружения RP), чтобы запрос атрибута был выполнен. Это может быть то, с чем вы сталкиваетесь.

person Andrew Arnott    schedule 05.07.2009
comment
Бьюсь об заклад, проблема с "localhost" - это проблема. У меня еще не было возможности протестировать его, но я отпишусь здесь сегодня днем, когда у меня будет возможность взглянуть на него. - person Micah; 06.07.2009
comment
Я нашел это полезным, так как я не могу получить расширения от myopenid с локального хоста. спасибо Эндрю - person eiu165; 28.12.2009
comment
Это решило мою проблему, спасибо Андрей! Стоит добавить, что это behaviors под relyingParty. - person Bojan Bjelic; 21.06.2011
comment
@Эндрю Арнотт должен быть общедоступным и, возможно, даже доступным для обнаружения - есть ли простой способ проверить, действительно ли это то, с чем я сталкиваюсь? Обратите внимание, что у меня еще нет подходящего домена, к которому можно прикрепить мой код, поэтому я все еще на локальном хосте. - person Matt; 09.01.2013
comment
Не совсем так, @Matt. Если вы находитесь на частном хосте, вы не сможете обнаружить неудачный входящий вызов. - person Andrew Arnott; 10.01.2013