The most probable usage we will have for OpenID authentication is when we open up some more interactive features on our site - you know all this social web stuff that's going on ;) - take commenting for instance or contact forms and what not.
Now, there's of course no problem using "inline authentication" like
<if not="" openid="" authenticated="">
Login with Google, Yahoo or [provider]
but since programming is fun it would be way cooler if you could actually make the OpenID module a Roxen UserDB or in some other way integrate it so that you authenticate as a "real" Roxen user.
Does anyone have any ideas or guidelines for how to make that possible?
I have a module you might be interested in:
This module handles login the same way ac cookie auth works, but uses its own user database (of course).
Provides a global member scope (so that for all XML and HTML) pages you can access the logged in users information.
Couple of rxml tags to handle the member information and retrieving information, logging.
Log-in goes through a normal form and through the <bt-member-cookie-login/>-tag it is easy to make the connection to whatever AC-user you like, which is perfect since you can keep your user when you are in your edit area and do development and styling.
This way we uses a couple of proxy users (normally only 3, but is not limited by this module, only practical and simple).
This module are a MODULE_SECURITY and have to be registered as the first module to handle authentication for almost all protection classes in AC.
I would suggest that you have this type of module but authentication and creation of a community user may be done in two ways:
- The traditional register form, verifying by email or sms or
- Through OpenID in which you authenticate and/or create the user.
In code something like:
<if openid="" authenticated="">
<community-cookie-auth-login OpenID="identifier" path="/" domain="yourdomain.com" ac-identity="community_user" />
[Authentication through form login logic.]
And if everything is OK:
<community-cookie-auth-login email="&form.email;" password="&form.password;" path="/" domain="yourdomain.com" />
This module may be a little too much for your liking but you may look at it. I must also say, that I am one of the authors for this module so it is mixed with a bit different styles of programming :)
Your module looks clean enough as it is, if it only handled the openid authentication you may use another module to actually handle the users and their permission to stuff through that? Meaning one is identified through your OpenID module or through your Worpress-login-module etc, but identified through your user module that has a very simple RXML interface to login a person since all security is done through other modules:
ac-identity="open_id_user" path="/" domain="yourdomain.com"/>
This way, you may keep the OpenId functionality clean and reusable for other type of things you need some sort of authentication/user information exchange for.
The module I suggested always assumes that the user has an email address, and that may not work, and it has a couple of functions that may be unnecessary - it is used for our community sites. We have a lot of modules that stores these community users id, needed to display who inserted that message in the forum, sent that letter etc, but one of the main part is that all those module must also remove information for a given user, so each of these modules have a couple of methods available through the provider module interface and is called from user module when we need to remove all information for that particular user.
Thank you for your reply Erik!
That's something along the line I was thinking. So a solution is to make a MODULE_SECURITY which checks if the user is logged in via OpenID and a proxy-user and if so you could populate the user scope with the information from the OpenID authentication. In that way the authentication would be transparent in the RXML code in the templates, i.e. the internal Roxen authentication is done by a proxy-user but the user scope is populated from the OpenID information.
Is that a correct principle?
Yes, but only have one module that is a MODULE_SECURITY, it does not have to know that the login process goes through OpenId. Then you can have other login schemas.