Now:

OpenID provider AX implements hook_openid_provider() and processes on $op = 'response'. It then does some aliasing and parsing and calls openid_provider_persona_process_ax() to let openid_provider_persona retrieve attributes.

openid_provider_persona_process_ax() in turn invokes hook_openid_provider_ax() to let other modules add their information.

Problems:

* No clean seperation between UI and API - can't use provider persona without using its UI
* hook_openid_provider_ax invoked from hook_openid_provider_persona
* Modules that only want to use AX features need to use AX and persona because AX requires persona.

I e. g. would like to use simple content_profile profiles and plug them into AX.

Suggested solution

  • Make AX independent from. Persona depends on ax.
  • openid_provider_ax_response_process() invokes hook_openid_provider_ax()
  • openid_provider_persona implements openid_provider_ax()
  • openid_provider_persona_schema_definitions() moves to openid_provider_ax.module

Would that make sense? Am I missing something here?

Aside and may be related: does persona negotiation work? I've installed and tried provider/ax/persona, created 2 personas and the system never asked me which persona I'd like to use when I used my provider to create an account on the relying site...

Comments

darren.ferguson’s picture

Alex at this moment i believe the persona negotiation only works if you do not have the Yes always clicked but currently i am not completely sure.

I am out of town this week and hence will get in contact with you regarding this, i will look at the suggestion above regarding what you are explaining.

aron novak’s picture

Here are the first patches.
Possible further directions
- make the _ax module a mapper what handles possible submodules - fields pairs. So it would be possible to get the email from one module, the name from other one. However this is complicated because of personas, etc.
Instant benefit: now it's possible to replace personas module with something else.

darren.ferguson’s picture

Aron

patch looks fine will get it committed upstream to the module either tonight or tomorrow morning so it is in CVS.

darren.ferguson’s picture

Version: » 6.x-1.0-beta1
Assigned: Unassigned » darren.ferguson
Status: Active » Closed (fixed)

Patches have been committed to the modules and they are now in CVS.

alex_b’s picture

Status: Closed (fixed) » Fixed

Setting this to fixed. I am always confused when I can't see the green entry for this patch on the module issue queue...

Status: Fixed » Closed (fixed)

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