Greetings, A few months ago, a co-worker of mine created a Drupal module to support OpenID logins. The module was based on Dan Libby's PHP OpenID library. For anyone wanting to catch up, it was discussed here: http://drupal.org/node/33254 Some other OpenID discussion is here: http://drupal.org/node/23256 I've taken over the development of the module and I've updated the module to use the JanRain PHP OpenID implementation, which is a feature-complete port of our Python library. Our PHP library can be found here: http://www.openidenabled.com/openid/libraries/php Here is a link to the current module source, which is under fairly heavy development: http://www.openidenabled.com/resources/downloads/php-openid/openid.module Since authentication in general is probably a topic of considerable interest to you all, I want to be sure the OpenID module measures up. I've tried to be sure I understand Drupal's authentication internals and the role OpenID can play, but please correct me where appropriate. Here are some notes about the module: - The plugin declares a block hook and provides a one-field OpenID login form that appears in the left navbar. The module is not really an authentication module because it doesn't declare an appropriate authentication hook (username@server syntax won't work for OpenID). Various other callbacks in the module handle the OpenID authentication steps and set $user when appropriate. - If you log in with an OpenID and don't have a local Drupal account, an account is created for you with the appropriate authmap record. However, you'll be prompted for an email address upon successful OpenID authentication *before* the Drupal account is created. (My goal here is to make sure any kind of profile info needed is collected before the OpenID-auth'd user is allowed into Drupal.) - My major concern is how to blend OpenID with existing accounts so users can choose to use OpenID for their accounts. On my drupal installation, I can log in with a username and password or OpenID to access the same account, provided the appropriate authmap record is present (which I created manually). The use case we can think of here is, "I'm already known as johnboy on this Drupal installation, but I want to access the johnboy account with an OpenID now. How can I tell Drupal about that?" I'm thinking that the OpenID module can implement a form to let users configure this, but it will probably involve setting the users.pass field to NULL. What do you think? Do you have any recommendations for how we should go about doing this? What would be consistent for your futuristic vision of Drupal authentication? Any feedback would be much appreciated. Thanks! -- Jonathan Daugherty JanRain, Inc.
On 9-Feb-06, at 2:21 PM, Jonathan Daugherty wrote:
What do you think? Do you have any recommendations for how we should go about doing this? What would be consistent for your futuristic vision of Drupal authentication? Any feedback would be much appreciated.
Great news, Jonathan! I've been on the standards side of identity, looking at lots of evolving networks. James Walker recently checked in the 4.7 version of SXIP (http://drupal.org/project/sxip), and he's written a couple of other authentication schemes in Drupal -- it's probably best to get in touch with him for code-level questions. My view is that core Drupal-auth should be switched out at some point with an alternate system, since it is insecure by default. OpenID is my top candidate for this role. Thanks for getting on the list...looking forward to some more discussion about this... Cheers, -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On Thu, Feb 09, 2006 at 02:21:54PM -0800, Jonathan Daugherty wrote:
Here is a link to the current module source, which is under fairly heavy development:
http://www.openidenabled.com/resources/downloads/php-openid/openid.module
vision of Drupal authentication? Any feedback would be much appreciated.
Hi, This is great stuff; I've been trying to work out how to get OpenID going for a little while now. I downloaded your module, and tried it out (with drupal 4.7 beta 4). I couldn't find Auth_OpenID_DatabaseConnection anywhere, which Drupal_OpenID_DBConnection attempts to extend, but I worked around this by requiring DB/mysql.php and extending DB_mysql instead. This at least let me get as far as getting the other server to ask if I trusted my test site. However, on returning to my test site, I didn't seem to be any more logged in than I was before. Could this be caused by the missing Auth_OpenID_DatabaseConnection? I'm not very familiar with pear, so for reference, I installed by: 1. Recompiled php with --enable-bcmath (since I didn't have a recent enough gmp to use that) 2. Coped Auth/ from the PHP-OpenID-0.9.1 tarball into /usr/local/apache/lib/php 3. Modified the require_onces in Consumer/Consumer.php to use full paths, since it didn't seem to find them otherwise, even though /usr/local/apache/lib/php is in the include_path (I think). 4. Put your openid.module into drupal's modules/ dir and made the DB_mysql changes as above. 5. Activated the module, added the openid block to the left navbar. Help here would be appreciated. I take it openid_login_form_submit() would be an appropriate place to add a check for banned servers? eg. Allowing the administrator to ban all OpenID users from spammers.com. Thanks, Ainsley
# I couldn't find Auth_OpenID_DatabaseConnection anywhere, which # Drupal_OpenID_DBConnection attempts to extend Well, I didn't expect anyone to actually try running the module; it's just for viewing and has been developed against an unreleased version of our PHP OpenID library. :) I guess what I am looking for (with regard to the code specifically) is "that should work and is acceptable", "don't do that, that's terribly awful", or "You'e almost there, but here are some things to consider." But I'll take a test run, too, for sure. :) # but I worked around this by requiring DB/mysql.php and extending # DB_mysql instead. This at least let me get as far as getting the # other server to ask if I trusted my test site. However, on returning # to my test site, I didn't seem to be any more logged in than I was # before. Could this be caused by the missing # Auth_OpenID_DatabaseConnection? # # <snip> # # Help here would be appreciated. Thanks for the detailed reply, and thanks for going to the trouble to get it to work. Your decision to extend DB_mysql was correct. Check to be sure that the openid_* tables are in your Drupal database. Did you get any kind of error when you return to your site from the OpenID server? (If you made it that far, things appear to be in working order.) When you return to your test site, do you get prompted to enter an email address for the new account? If so, does that succeed? # I take it openid_login_form_submit() would be an appropriate place # to add a check for banned servers? eg. Allowing the administrator to # ban all OpenID users from spammers.com. Yeah, that's right. Thanks! -- Jonathan Daugherty JanRain, Inc.
Stop me if you've heard this one before. I recently upgraded the server running my Drupal site, and the events calendar stopped working for everyone except user=1. I tracked down the problem to this (simplified) line of SQL: SELECT n.nid, e.event_start FROM {event} e INNER JOIN {node} n ON n.nid = e.nid This returns all my events if the user=1, and zero if the user is anyone else. However, if I rewrite the SQL as: SELECT n.nid, e.event_start FROM {node} n INNER JOIN {event} e ON n.nid = e.nid then it behaves as I would expect, returning all events regardless of who the user is. I did not have this problem on my old server, which was running mysql 4.0.20-max. The new server is running mysql 5.0.17. I suspect whatever is causing this is also at the root of my node_access_by_role issue (http://drupal.org/node/40623). I guess my next move is to install the devel module and see if I can find a difference between the sql actually being generated when user=1 vs user!=1. ps. It was great meeting you all in Vancouver. -- Tao Starbow Web Architect, CITRIS
Tao Starbow wrote:
Stop me if you've heard this one before.
I recently upgraded the server running my Drupal site, and the events calendar stopped working for everyone except user=1. I tracked down the problem to this (simplified) line of SQL: SELECT n.nid, e.event_start FROM {event} e INNER JOIN {node} n ON n.nid = e.nid This returns all my events if the user=1, and zero if the user is anyone else. However, if I rewrite the SQL as: SELECT n.nid, e.event_start FROM {node} n INNER JOIN {event} e ON n.nid = e.nid then it behaves as I would expect, returning all events regardless of who the user is.
I did not have this problem on my old server, which was running mysql 4.0.20-max. The new server is running mysql 5.0.17.
This is not a mysql issue, but a simple bug in event.module. The rewriting of the query fails as it isn't in the form the regexp expects (I did say that using regexps is evil, did I?). Please file a bug report for event.module so that I don't forget about it. A patch is also appreciated. The reason it doesn't happen for uid 1 is that no rewriting takes place for that user. Cheers, Gerhard
Tao Starbow wrote:
Stop me if you've heard this one before.
I recently upgraded the server running my Drupal site, and the events calendar stopped working for everyone except user=1. I tracked down the problem to this (simplified) line of SQL: SELECT n.nid, e.event_start FROM {event} e INNER JOIN {node} n ON n.nid = e.nid This returns all my events if the user=1, and zero if the user is anyone else. However, if I rewrite the SQL as: SELECT n.nid, e.event_start FROM {node} n INNER JOIN {event} e ON n.nid = e.nid then it behaves as I would expect, returning all events regardless of who the user is.
I did not have this problem on my old server, which was running mysql 4.0.20-max. The new server is running mysql 5.0.17.
I suspect whatever is causing this is also at the root of my node_access_by_role issue (http://drupal.org/node/40623). I guess my next move is to install the devel module and see if I can find a difference between the sql actually being generated when user=1 vs user!=1.
If the actual generated SQL works/fails as you describe in the simplified SQL above, I think you have found a bug in MySQL. INNER JOIN should be commutative, that is, it should not matter which order the two joined tables are listed, the results should be the same.
On Fri, Feb 10, 2006 at 01:01:12PM -0800, Jonathan Daugherty wrote:
# I couldn't find Auth_OpenID_DatabaseConnection anywhere, which # Drupal_OpenID_DBConnection attempts to extend
Well, I didn't expect anyone to actually try running the module; it's just for viewing and has been developed against an unreleased version of our PHP OpenID library. :) I guess what I am looking for (with regard to the code specifically) is "that should work and is acceptable", "don't do that, that's terribly awful", or "You'e almost there, but here are some things to consider." But I'll take a test run, too, for sure. :)
Ah, well, I don't know a lot about Drupal internals personally, but as I'm interested in getting OpenID going with it, I thought I could best help by trying it out and offering encouragement :)
Thanks for the detailed reply, and thanks for going to the trouble to get it to work. Your decision to extend DB_mysql was correct. Check to be sure that the openid_* tables are in your Drupal database. Did you get any kind of error when you return to your site from the OpenID server? (If you made it that far, things appear to be in working order.) When you return to your test site, do you get prompted to enter an email address for the new account? If so, does that succeed?
Yes, I have three openid_consumer_* tables, settings and associations each have one entry (settings has an auth_key, associations has an entry with the server_url I used. No error shown, in the logs I see some 'table already exists' messages, and a 'No colon on line 6:' from KVForm.php line 77. I did get prompted for an email address, but no account with that address is in my users table. After a bit more investigation it seems that it was a browser issue. Konqueror 3.5.1 doesn't like it somehow, but with Firefox it works OK. (Except for there being an extra 'openid/' in the returned-to url, which I can fix by removing it from the header("Location: "... line in openid_return() ). I'll try looking into the Konqueror problem myself. ~Ainsley
On Sat, Feb 11, 2006 at 02:02:25PM +0000, Ainsley Pereira wrote:
After a bit more investigation it seems that it was a browser issue. Konqueror 3.5.1 doesn't like it somehow, but with Firefox it works OK. (Except for there being an extra 'openid/' in the returned-to url, which I can fix by removing it from the header("Location: "... line in openid_return() ).
I'll try looking into the Konqueror problem myself.
Found it. In openid_email_form(), I changed: $form['#action'] = url(); to $form['#action'] = url('openid/get_email'); and it now works in Konqueror and elinks too. Hope that helps, Ainsley
Here is a link to the current module source, which is under fairly heavy development:
http://www.openidenabled.com/resources/downloads/php-openid/openid.module
Looks quite modern and Drupalish. Nice.
- The plugin declares a block hook and provides a one-field OpenID login form that appears in the left navbar. The module is not really an authentication module because it doesn't declare an appropriate authentication hook (username@server syntax won't work for OpenID). Various other callbacks in the module handle the OpenID authentication steps and set $user when appropriate.
sure - your approach looks reasonable to me.
- If you log in with an OpenID and don't have a local Drupal account, an account is created for you with the appropriate authmap record. However, you'll be prompted for an email address upon successful OpenID authentication *before* the Drupal account is created. (My goal here is to make sure any kind of profile info needed is collected before the OpenID-auth'd user is allowed into Drupal.)
you might make this extra step optional. i think it is a hassle to provide an email address for a random site. current drupal auth creates accounts without an email address. drupal does not require email address if the account is created via code (the web ui requires email address)
- My major concern is how to blend OpenID with existing accounts so users can choose to use OpenID for their accounts.
I think we're going to have to require that the user be logged into his current drupal account in order to do this. If so ... Typical distributed auth modules in Drupal let a user edit his specifics for the remote site from his profile page. OpenID could provide an url textfield on the user profile page (see hook_user('form')). It could use hook_user('validate') to check the provided if needed. Thus we give a way for existing users to add openID to their account. How much is involved in implementing the server side ofopenID? Can it be a Drupal module? One feature I like about current Drupal is that every site is instantly a client and a server for DA.
Anyone working on SSO (single sign-on) might want to take a look at the YADIS (Yet Another Distributed Identity System) work that's happening at http://yadis.org/ YADIS is a blend of LID (the Lightweight Identity System by Johannes Ernst), OpenID (by Brad Fitzpatrick et al at Live Journal) and XRI (eXtensible Resource Identifiers being developed by an OASIS standards committee. Sxip and mIDm are represented, too. By blending the best each of these initiatives has to offer, I believe authentication systems that are YADIS-aware have a positive chance of survival as the identity world continues to shake out. Note that the OpenID-enabled wiki has a section on YADIS, too: http://www.openidenabled.com/yadis/what-is-yadis =Fen
Looks quite modern and Drupalish. Nice.
Thanks!
However, you'll be prompted for an email address upon successful OpenID authentication *before* the Drupal account is created.
you might make this extra step optional. i think it is a hassle to provide an email address for a random site. current drupal auth creates accounts without an email address. drupal does not require email address if the account is created via code (the web ui requires email address)
Ah, alright. The only reason I did this was because if you create an account without an email address, you'll still be required to enter one on the account edit page to satisfy the form constraints. I assumed, therefore, that it's a required account property.
- My major concern is how to blend OpenID with existing accounts so users can choose to use OpenID for their accounts.
I think we're going to have to require that the user be logged into his current drupal account in order to do this. If so ...
Yeah, I was thinking that this could be implemented as a profile field that users can enter that says, "Let me also log into this account with the following OpenID." This sounds like what you're proposing. Please let me know if I'm way off base. :)
How much is involved in implementing the server side ofopenID? Can it be a Drupal module? One feature I like about current Drupal is that every site is instantly a client and a server for DA.
Server support will be pretty easy to add, and I'm pretty sure it can be added as a module. Thanks for your feedback! -- Jonathan Daugherty JanRain, Inc.
Yeah, I was thinking that this could be implemented as a profile field that users can enter that says, "Let me also log into this account with the following OpenID." This sounds like what you're proposing. Please let me know if I'm way off base. :)
yes, thats correct.
How much is involved in implementing the server side ofopenID? Can it be a Drupal module? One feature I like about current Drupal is that every site is instantly a client and a server for DA.
Server support will be pretty easy to add, and I'm pretty sure it can be added as a module.
Cool. Are you planning on implementing this? Would be great.
Server support will be pretty easy to add, and I'm pretty sure it can be added as a module.
Cool. Are you planning on implementing this? Would be great.
Absolutely; I wanted to test the community water first and see if there were any important points or discussion I missed. -- Jonathan Daugherty JanRain, Inc.
What's the status of this module? I'd like to begin using it on my personal site. Robin On 2/13/06, Jonathan Daugherty <cygnus@janrain.com> wrote:
Server support will be pretty easy to add, and I'm pretty sure it can be added as a module.
Cool. Are you planning on implementing this? Would be great.
Absolutely; I wanted to test the community water first and see if there were any important points or discussion I missed.
-- Jonathan Daugherty JanRain, Inc.
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org Public Key: http://shurl.org/key/devlinks@gmail.com ( http://gmking.org, a gamers dream, looking for admins )
Quoting Robin Monks <devlinks@gmail.com>:
What's the status of this module? I'd like to begin using it on my personal site.
You can get version 1.0 of the OpenID Drupal module here. It requires PHP OpenID 0.9.2 or greater. http://www.openidenabled.com/software/drupal -- Jonathan Daugherty JanRain, Inc.
On Tue, 2006-03-07 at 11:14 -0800, Jonathan Daugherty wrote:
Quoting Robin Monks <devlinks@gmail.com>:
What's the status of this module? I'd like to begin using it on my personal site.
You can get version 1.0 of the OpenID Drupal module here. It requires PHP OpenID 0.9.2 or greater.
Is this GPL? If so, what are the chances of it being submitted on drupal.org so it shows up on the modules page? (relevant info from the handbook: http://drupal.org/node/7765 ) -- brian@brianpuccio.net GPG Key ID 0xBBD2401F
participants (10)
-
Ainsley Pereira -
Boris Mann -
Brian Puccio -
Chris Johnson -
Fen Labalme -
Gerhard Killesreiter -
Jonathan Daugherty -
Moshe Weitzman -
Robin Monks -
Tao Starbow