Impossibile ottenere attributi dalla risposta DotNetOpenId

Question

Sto cercando di capire come ottenere le informazioni degli utenti dopo la convalida tramite l'id aperto. Non importa se fornisco un ClaimsRequest o FetchRequest ogni volta chiamo

response.GetExtension<ClaimsResponse> 

//Or 

response.GetExtension<FetchResponse> 

//Or 

response.GetUntrustedExtension<ClaimsResponse> 

// OR 

response.GetUntrustedExtension<FetchResponse> 

ottengo sempre riferimento null. Sto aggiungendo le informazioni, proprio come in tutti gli esempi che ho visto in questo modo:

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

// Or 

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

Qualsiasi idea di cosa sto facendo male?

Aggiornamento

Aggiunta di informazioni di configurazione suggerita da Andrew mi ha fatto parte della strada. Sto finalmente ottenendo un reclamo di Claims con response.GetUntrustedExtension<ClaimsResponse> tuttavia response.GetExtension<ClaimsResponse> restituisce ancora null. Anche la risposta di ClaimsResponse non contiene in realtà nessuno dei dati che ho richiesto. Ecco la domanda:

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(); 

Ecco la mia configurazione

<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> 

Io corro v3.2.0.9177

Answer 1

Potrebbe benissimo essere che il provider si è test contro non supporta queste estensioni. Oppure, se si tratta di Google, risponde solo una volta alla domanda (a meno che durante l'accesso non si stia attento a non lasciare selezionato Ricordami).

Ora con DotNetOpenAuth v3.2, il modo migliore per inviare le estensioni è probabilmente quello di utilizzare la nuova estensione di attributo 'comportamento'. Utilizzerà automaticamente sreg e/o AX (in un massimo di tre diversi formati AXE) a seconda del provider per massimizzare le possibilità di ottenere un risultato utile se il provider supporta affatto queste estensioni.

Attaccare questo bit nel file web.config, dove suggerito nel full configuration wiki page.

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

Quindi utilizzare ClaimsRequest/ClaimsResponse (SREG) al posto di AX' FetchRequest in modo che il comportamento può fare il suo lavoro.

Dal momento che hai menzionato che stai provando contro myopenid.com, spunterò anche l'idea che sembra che abbiano disattivato il supporto delle estensioni quando stai testando un RP che si trova su "localhost". A quanto pare, il tuo RP deve essere pubblico e forse anche individuabile (secondo le regole di OpenID 2.0 per la scoperta di RP) affinché la richiesta di attributo sia onorato. Questo potrebbe essere ciò che stai incontrando.