7

I'm trying to figure out how to get the users information after validating via open id. It doesn't matter if I supply a ClaimsRequest or FetchRequest whenever I call

response.GetExtension<ClaimsResponse>

//Or

response.GetExtension<FetchResponse>

//Or

response.GetUntrustedExtension<ClaimsResponse>

// OR

response.GetUntrustedExtension<FetchResponse>

I always get a null reference. I'm adding the information just like in all the examples I've seen like this:

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

// Or

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

Any idea what I'm doing wrong?

Update

Adding the configuration info suggested by Andrew got me part of the way there. I'm finally getting a ClaimsResponse back with response.GetUntrustedExtension<ClaimsResponse> however response.GetExtension<ClaimsResponse> still returns null. Also the ClaimsResponse returned doesn't actually contain any of the data I requested. Here's the request:

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

Here is my configuration

  <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

Micah
  • 111,873
  • 86
  • 233
  • 325
  • Can you include which OP you're testing against? – Andrew Arnott Jul 05 '09 at 01:20
  • The behavior configuration will cause a ClaimsResponse to always be present, even without any values, just as you say. It looks like your code is correct, and since myopenid supports both sreg and AX I'm surprised this isn't working for you. I'll see if I can do some more investigation. – Andrew Arnott Jul 05 '09 at 14:59
  • I added a comment about testing against myopenid.com specifically to my answer as I imagine that is what you're running up against. Also just a tip, the security tag that you added to your web.config file isn't necessary if you left it verbatim as it was in the wiki page. Those are all the default values. The only substantial changes I see here are that you added 'localhost' as a whitelisted host and the behavior we talked about. – Andrew Arnott Jul 06 '09 at 12:58

1 Answers1

10

It could very well be that the Provider you're testing against doesn't support these extensions. Or, if it's Google, it only answers the question once (unless during login you're careful to not leave Remember Me checked).

Now with DotNetOpenAuth v3.2, the best way to send extensions is probably to use the new attribute extension 'behavior'. It will automatically use sreg and/or AX (in up to three different AX formats) depending on the Provider in order to maximize your chance of getting a useful result if the Provider supports any of these extensions at all.

Stick this bit in your web.config file, where suggested in the full configuration wiki page.

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

Then use ClaimsRequest/ClaimsResponse (sreg) instead of AX' FetchRequest so that the behavior can do its work.

Since you mentioned that you're testing against myopenid.com, I'll also throw out the heads up that it seems they've turned off extensions support when you're testing an RP that is on 'localhost'. Your RP apparently has to be public and maybe even discoverable (per the OpenID 2.0 rules for RP discovery) for the attribute request to be honored. This might be what you're running into.

Andrew Arnott
  • 80,040
  • 26
  • 132
  • 171
  • I bet the 'localhost' issue is the problem. I haven't had a chance to test it yet, but I'll post back here this afternoon when I get a chance to look at it. – Micah Jul 06 '09 at 13:33
  • I found this helpful, as I am unable to get the extensions from myopenid from localhost. thanks Andrew – eiu165 Dec 28 '09 at 19:59
  • This solved my problem, thanks Andrew! One thing to add is that the this is `behaviors` under `relyingParty`. – Bojan Bjelic Jun 21 '11 at 12:51
  • @Andrew Arnott "has to be public and maybe even discoverable" - is there an easy way to see if this is in fact what I'm running into? Note that I don't yet have a proper domain to attach my code to, which is why I'm still on localhost. – Matt Jan 09 '13 at 17:36
  • Not really, @Matt. If you're on a non-public host, you won't be able to detect the failed incoming call. – Andrew Arnott Jan 10 '13 at 14:35