| Project: | OpenID Provider AX |
| Version: | 6.x-1.0-beta1 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | darren.ferguson |
| Status: | closed (fixed) |
Issue Summary
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
#1
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.
#2
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.
#3
Aron
patch looks fine will get it committed upstream to the module either tonight or tomorrow morning so it is in CVS.
#4
Patches have been committed to the modules and they are now in CVS.
#5
Setting this to fixed. I am always confused when I can't see the green entry for this patch on the module issue queue...
#6
Automatically closed -- issue fixed for 2 weeks with no activity.