up vote 4 down vote favorite
1

Since we are getting an increasing number of users coming to our sites (phpclasses.org and jsclasses.org) from StackOverflow, we decided to implement support to let users with StackOverflow accounts to login in our sites.

The OpenID authentication with http://openid.stackexchange.com/ is working fine as with other OpenID 2 providers that we support like Yahoo, except that the user e-mail address as ax attribute is not being returned. We use the e-mail address as unique key avoid multiple accounts being created by the same user.

I don't know if this is intentional or if it has to do with the parameters that we are passing to StackExchange OpenID provider. I read something about a whitelist somewhere but I am not sure if it is related with the problem.

Can anybody clarify why it is not returning the account email address as ax attribute?

Here follows the attributes that we are passing with the checkid_setup message.

http://accounts.icontem.local/ is our development site that manages the all the accounts of our users and provides single sign-on services to our actual sites. The production single sign-on site is actually https://accounts.icontem.com/ but we have not enabled StackExchange support there until we sort this issue.

Here is a sample of the list of parameters that we are passing during the initial POST redirect request.

Redirecting to OpenID provider https://openid.stackexchange.com/openid/provider openid.mode=checkid_setup openid.identity=http://specs.openid.net/auth/2.0/identifier_select openid.trust_root= openid.return_to=http://accounts.icontem.local/external/?server=StackExchange&return_to= openid.assoc_handle={634798386067877388}{eD8w5Q==}{20} openid.ax.type.email=http://axschema.org/contact/email openid.ax.type.nickname=http://axschema.org/namePerson/friendly openid.ax.type.fullname=http://axschema.org/namePerson openid.ax.mode=fetch_request openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.if_available=email,nickname,fullname openid.ns=http://specs.openid.net/auth/2.0 openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select

share|improve this question
  • I analyzed further StackExchange response and it actually returns the e-mail address, except that it is set using arbitrary namespace alias, like alias3. According to the OpenID AX standard, the response values should be openid.ax.value.alias, so the namespace of AX response values should be ax, not some arbitrary namespace name. I have tweaked our OpenID consumer component to handle your namespace aliasing, but I think it would be better if you used ax as namespace instead. – mlemos Aug 7 '12 at 19:44
up vote 1 down vote

Your understanding of the attribute exchange mechanism is not complete; the documentation clearly states that the extension alias can be different to avoid naming conflicts on the provider; "ax" is just one possible alias, but the meaning itself is encapsulated by the URI.

See also: Definitions and Conventions

I stumbled upon this when I was developing my own provider code, but I immediately saw the connection with XML; each namespace can have an alias, but just the alias has no meaning at all.

An important feature of using namespaces in this way is versioning; code that works well for one version might break in the next version (using the same alias), so it's best practice to load the right model for each version and ignore those that are not supported.

share|improve this answer
  • Your interpretation is probably correct. Maybe the other section that I reference is suggesting something that is not accurate. Actually I supposed that since the request uses ax as namespace, the server would have to return the same alias for that namespace. Anyway, I have tried our OpenID components with many, many OpenID servers and this is the first to not use ax as namespace alias for AX attributes. There is no reason to not use ax as namespace or at least honour the namespace used in the request. So I am afraid the StackExchange OpenID server will give the same problem to other clients. – mlemos Aug 31 '12 at 0:15
  • @mlemos then other clients should be fixed :) btw, their client code behaves in the same way – Jack Aug 31 '12 at 2:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .