I tried to pull my AX attributes from myopenid.com with openid_client_ax DRUPAL-6--1 and openid_cp_field DRUPAL-6--1 and it failed silently (no profile created, no fields populated.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Aron Novak’s picture

http://openid.net/pipermail/general/2008-February/004029.html
I'm not sure what to do.

What is the "official" schema for the attribute exchange?
I notice that www.axschema.org defines several attributes; but they don't
work on myopenid.com.

And axschema is the official, it is stated at the linked thread.

darren.ferguson’s picture

The one we utilize in the mappings was the one that worked i believe axschema.org Openid.net seemed to have implemented their own slightly different i had that problem in the begining with it hence i put the schema their way because all the others supported it.

I think one of the readmes has something on that in it

gthorisson’s picture

I'm having a similar problem when trying to get both MyOpenID and Google OpenIDs to work. The problem isn't so much the schema URL (e.g. Google seems to work with both, so I just use the schema.net one to make MyOpenID play nicely), but rather the fact that the requested AX namespace is not handled consistently between providers. For instance, if I say in my request I want to use the ext1 namespace then Google will give me field names like this:

openid.ext1.value.country.1

while MyOpenID

insists on giving me its own 'ax' namespace no matter what:

openid.ax.value.country.1

Anybody else seen this?

I have a hack in openid_client_ax.module to work around this when retrieving AX values, but I was wondering if there's something I'm missing in the original request, or the OpenID Client AX configuration or something?

alex_b’s picture

Status: Active » Needs review
FileSize
586 bytes

I just talked to Aron on IM and he told me that what needs to be changed are the URIs that are used as keys in the attributes array. Right now their domain is *axschema.org* whereas myopenid.com requires *schema.openid.net* - Aron did I relay this correctly, can you confirm this?

Here is a patch that adds a drupal_alter() to the ax schema definition to let whatever third party module alter the definitions without hacking it. However, I'm thinking it may be possible to just add myopenid.com style schema definitions into the existing schema definition array.

RichardDavies’s picture

gthorisson,

According to the attribute exchange spec, the party composing the message gets to choose the namespace. So you can use "ax" or "ext1" as your namespace, but when the OpenID Provider composes the response, they are free to use whatever namespace they want, which may or may not be the same namespace you used in your request.

So when parsing the response, you need to search for the namespace defined as "http://openid.net/srv/ax/1.0".

wojtha’s picture

As alex_b wrote alter hook is maybe not necessary - I went this way without any knowledge about this thread.

I introduced new hook "openid_ax_schema" which allows other AX extensions to inject theirs schema.

Going this way there is little problem with the "identifier", I solved this with using "identifiers" starting from 200. Using alter hook seems to be better, since you can check the max identifier and use dynamical identifier in the extension. But using dynamical identifiers is a bad idea, because after some change on the site - module update, installing some other AX entension - identifiers could change.

wojtha’s picture

Title: AX not working with myopenid.com » AX not working with myopenid.com hook_openid_client_ax_schema is needed
FileSize
708 bytes

New patch introducing new hooks hook_openid_client_ax_schema and hook_openid_client_ax_schema_alter.

wojtha’s picture

Title: AX not working with myopenid.com hook_openid_client_ax_schema is needed » AX not working with myopenid.com - hook to add/modify the AX elements is needed
xamanu’s picture

Status: Needs review » Fixed

This is surely not a bad idea. Committed and pushed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.