Не могат да се получат атрибути от отговора на 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> все още връща нула. Освен това върнатият 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, не е необходим, ако сте го оставили дословно, както беше в wiki страницата. Това са всички стойности по подразбиране. Единствените съществени промени, които виждам тук, са, че сте добавили „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 от localhost. благодаря Андрю - person eiu165; 28.12.2009
comment
Това реши проблема ми, благодаря Андрю! Едно нещо, което трябва да добавите е, че това е behaviors под relyingParty. - person Bojan Bjelic; 21.06.2011
comment

В Django >= 1.6 CSS класовете са включени в изхода list_display:

"Имената на полетата в list_display също ще се показват като CSS класове в HTML изхода, под формата на column-<field_name> на всеки <th> елемент. Това може да се използва за задаване на ширини на колони в CSS файл."

- person Matt; 09.01.2013
comment
Не съвсем, @Matt. Ако сте на непубличен хост, няма да можете да откриете неуспешното входящо повикване. - person Andrew Arnott; 10.01.2013