Hello all. It's Saturday morning and I've convinced myself that: a) we're going to fully embracing Drupal, which means a few grumbles ;) b) I really need a way to (easily) bridge user authentication between Drupal `userid` and several other SQL db's user entries c) and so I'd like to begin writing my first Drupal shareable code d) our 2-week tests with running pMachine inside Drupal are a success I am a generally confident PHP programmer, but I must admit that I am only at about 50% confidence with my knowledge of Drupal's APIs. Therefore, I'd like to start on this [ (b) ] basic code project in order that I might solve an immediate need as well as become more confident with those API's, as they exist in 4.7. If there are others who find that they might need a similar piece of code (see more full description below), then I would very much like to start a collaboration with you. ================================================================= Project: Generic User Authentication Look-up Bridge Framework Project Description: I wish to create a basic, super-admin-only set of PHP functions to bridge the Drupal user's table to (any) other SQL table. The Drupal `userid` will be looked up in any of the named DB's and will considered valid if both `userid` and `password` are the same in both places. Functionality would be modular, allowing the addition of application-specific bridges for common OSS user-based tools (i.e., pMachine, Olate Download, etc.) Project Hopes: 1) Simple, flexible design. 2) Drop-In Install, Single-Page Management. 3) Eventual addition of 'Authenticate and Migrate User' functionality. ================================================================= Please contact me via email if this is something that you have an interest in working on. (Please, hold off on the "I'd like this too, but I have no way to help" emails until a bit later, okay? ;) I am open to the possibility that I'm a dreamer and that I this dog won't hunt. Please gently discourage, as appropriate. -- Gary
Hi Gary, You mean you would like to reinvent authentication modules? http://cvs.drupal.org/viewcvs/drupal/contributions/modules/authentication/ Gabor Gary (Lists) wrote:
Hello all.
It's Saturday morning and I've convinced myself that:
a) we're going to fully embracing Drupal, which means a few grumbles ;)
b) I really need a way to (easily) bridge user authentication between Drupal `userid` and several other SQL db's user entries
c) and so I'd like to begin writing my first Drupal shareable code
d) our 2-week tests with running pMachine inside Drupal are a success
I am a generally confident PHP programmer, but I must admit that I am only at about 50% confidence with my knowledge of Drupal's APIs.
Therefore, I'd like to start on this [ (b) ] basic code project in order that I might solve an immediate need as well as become more confident with those API's, as they exist in 4.7.
If there are others who find that they might need a similar piece of code (see more full description below), then I would very much like to start a collaboration with you.
================================================================= Project: Generic User Authentication Look-up Bridge Framework
Project Description:
I wish to create a basic, super-admin-only set of PHP functions to bridge the Drupal user's table to (any) other SQL table.
The Drupal `userid` will be looked up in any of the named DB's and will considered valid if both `userid` and `password` are the same in both places.
Functionality would be modular, allowing the addition of application-specific bridges for common OSS user-based tools (i.e., pMachine, Olate Download, etc.)
Project Hopes:
1) Simple, flexible design. 2) Drop-In Install, Single-Page Management. 3) Eventual addition of 'Authenticate and Migrate User' functionality. =================================================================
Please contact me via email if this is something that you have an interest in working on. (Please, hold off on the "I'd like this too, but I have no way to help" emails until a bit later, okay? ;)
I am open to the possibility that I'm a dreamer and that I this dog won't hunt. Please gently discourage, as appropriate.
-- Gary
"Gabor Hojtsy" wrote:
Hi Gary,
You mean you would like to reinvent authentication modules?
Nope. "Chris Johnson" wrote:
More generally, changes should also occur to allow authenticating the user against a configurable table. This would require slightly more extensive changes in user_load() and user_save(), but should still be straight-forward.
Gary, how does this fit with what you are planning?
Fits right in, Chris. It sounds like we have some of the same needs, particularly with hooking to intranet application layers which all have their own authentication process. I want a single wrapper, single log-in (one that actually works, not the Drupal distributed auth stuff, which doesn't work.) "Chris Johnson" wrote:
It would still be nice to be able to specify the hash algorithm used in Drupal's own users table, perhaps even in a manner similar to how Bèr allows it for external tables in this module.
Yes. This is key...unless one can synchronize everything at some other level. Which...why? That's why there's PHP. ;) "Bèr Kessels" wrote:
Op zaterdag 15 april 2006 13:43, schreef naudefj:
Before you start, please see if you cannot use (or extend) the "SQL Authentication" module - http://drupal.org/node/50946
I am the maintaner for that, feel free to contact me ahead (as in: before you come up with patches) with ideas and proposals.
Will do, Naudefj, but I'm not sure this module will do exactly what I need. -- Gary
Hi Gary, Before you start, please see if you cannot use (or extend) the "SQL Authentication" module - http://drupal.org/node/50946 Best regards. Frank On Saturday 15 April 2006 13:29, Gary (Lists) wrote:
Hello all.
It's Saturday morning and I've convinced myself that:
a) we're going to fully embracing Drupal, which means a few grumbles ;)
b) I really need a way to (easily) bridge user authentication between Drupal `userid` and several other SQL db's user entries
c) and so I'd like to begin writing my first Drupal shareable code
d) our 2-week tests with running pMachine inside Drupal are a success
I am a generally confident PHP programmer, but I must admit that I am only at about 50% confidence with my knowledge of Drupal's APIs.
Therefore, I'd like to start on this [ (b) ] basic code project in order that I might solve an immediate need as well as become more confident with those API's, as they exist in 4.7.
If there are others who find that they might need a similar piece of code (see more full description below), then I would very much like to start a collaboration with you.
================================================================= Project: Generic User Authentication Look-up Bridge Framework
Project Description:
I wish to create a basic, super-admin-only set of PHP functions to bridge the Drupal user's table to (any) other SQL table.
The Drupal `userid` will be looked up in any of the named DB's and will considered valid if both `userid` and `password` are the same in both places.
Functionality would be modular, allowing the addition of application-specific bridges for common OSS user-based tools (i.e., pMachine, Olate Download, etc.)
Project Hopes:
1) Simple, flexible design. 2) Drop-In Install, Single-Page Management. 3) Eventual addition of 'Authenticate and Migrate User' functionality. =================================================================
Please contact me via email if this is something that you have an interest in working on. (Please, hold off on the "I'd like this too, but I have no way to help" emails until a bit later, okay? ;)
I am open to the possibility that I'm a dreamer and that I this dog won't hunt. Please gently discourage, as appropriate.
-- Gary
Op zaterdag 15 april 2006 13:43, schreef naudefj:
Before you start, please see if you cannot use (or extend) the "SQL Authentication" module - http://drupal.org/node/50946
I am the maintaner for that, feel free to contact me ahead (as in: before you come up with patches) with ideas and proposals. I am esp interested in making this modle more 'general'. For example postgresql is theoretically supported, but I cannot test it. In theory one should be able to authenticate over a network too (using a remotely SQL server) this too has not been tested, nor verified. I have also not tested it against any third party tools, with odd encodings for the passwords. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
On 15 Apr 2006, at 3:45 PM, Bèr Kessels wrote:
I am esp interested in making this modle more 'general'. For example postgresql is theoretically supported, but I cannot test it. In theory one should be able to authenticate over a network too (using a remotely SQL server) this too has not been tested, nor verified.
Currently Drupal can't make both a postgres and a mysql connection within the same session, but I have a patch for that, I will be re-rolling in the next 2 weeks. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
naudefj wrote:
Hi Gary,
Before you start, please see if you cannot use (or extend) the "SQL Authentication" module - http://drupal.org/node/50946
Best regards.
Frank
I've just reviewed Bèr Kessels' sql_auth.module, and it looks like it can handle many use cases of authentication from external sources. Thanks for pointing it out. It would still be nice to be able to specify the hash algorithm used in Drupal's own users table, perhaps even in a manner similar to how Bèr allows it for external tables in this module. One of the biggest challenges, it seems, is simply learning what is available out there and what the capabilities and limitations are for all those contrib modules. There's just so many of them, it's tough to be familiar with them all. This is a good problem to have, one might say. ..chrisxj
On 15 Apr 2006, at 6:19 PM, Chris Johnson wrote:
One of the biggest challenges, it seems, is simply learning what is available out there and what the capabilities and limitations are for all those contrib modules. There's just so many of them, it's tough to be familiar with them all. This is a good problem to have, one might say. I think lullabot has the right idea with this.
I found the flickrstickr screencast / review very informative. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op zaterdag 15 april 2006 18:19, schreef Chris Johnson:
I've just reviewed Bèr Kessels' sql_auth.module, and it looks like it can handle many use cases of authentication from external sources. Thanks for pointing it out.
The choices for hashing algorythms is not from my head/hand. Drupal users md5 and that is supported. Am I missing your point? I (personally) use to athenticate against otehr drupal sites on my host. It works fine. Optionally you might be very interested in getting rid of that @server part that is now hardcoded into core. A patch for that is here: http://drupal.org/node/29147 It will most probably be one of the first patches to get into the 4.8/HEAD branch. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Gary (Lists) wrote:
b) I really need a way to (easily) bridge user authentication between Drupal `userid` and several other SQL db's user entries
================================================================= Project: Generic User Authentication Look-up Bridge Framework
Project Description:
I wish to create a basic, super-admin-only set of PHP functions to bridge the Drupal user's table to (any) other SQL table.
The Drupal `userid` will be looked up in any of the named DB's and will considered valid if both `userid` and `password` are the same in both places.
Functionality would be modular, allowing the addition of application-specific bridges for common OSS user-based tools (i.e., pMachine, Olate Download, etc.)
Project Hopes:
1) Simple, flexible design. 2) Drop-In Install, Single-Page Management. 3) Eventual addition of 'Authenticate and Migrate User' functionality. =================================================================
I was just thinking about the need for things similar to this for enterprise-wide use of Drupal, and for making life easier for my extranet users at my employer, where I am busily converting our existing web applications to Drupal. Here's one part of what I think needs to happen. Note that Drupal already has some capabilities for various kinds of plug-in authentication. But the ability to use other SQL databases and their user entries is a missing and needed capability. I could easily hack the user.module to do what I need. But I don't want to have to re-port my changes every release of Drupal. What needs to happen is user.module be modified to accept a plug-in user authentication method, which can be locally customized, just like sites/defaults/settings.php allows for various other pieces of Drupal. Perhaps that is even the correct place do fit this scheme in. In my case, I have a table of existing usernames and passwords. I would just import them all into drupal.users except for one major problem: Drupal uses md5() password hashing and my existing table uses crypt(md5) hashing. That's right -- they both use the md5 algorithm, but the resulting strings are vastly different, and as far as we can tell, there's no way to translate them. At the moment I'm thinking that the user_load(), user_save() and user_pass_rehash() functions be re-written so as to call a configurable hashing algorithm. That would allow me to change the algorithm in my installation from md5() to crypt(). More generally, changes should also occur to allow authenticating the user against a configurable table. This would require slightly more extensive changes in user_load() and user_save(), but should still be straight-forward. Gary, how does this fit with what you are planning? ..chrisxj
Are you talking about making sqlauth a core module? I hope not. It is fien where it is. It does what you describe below, just fine. In case you find any missing (but badly needed) features, the module is open for suggestions and improvement. Op zaterdag 15 april 2006 18:07, schreef Chris Johnson:
I was just thinking about the need for things similar to this for enterprise-wide use of Drupal, and for making life easier for my extranet users at my employer, where I am busily converting our existing web applications to Drupal.
Here's one part of what I think needs to happen. Note that Drupal already has some capabilities for various kinds of plug-in authentication. But the ability to use other SQL databases and their user entries is a missing and needed capability.
I could easily hack the user.module to do what I need. But I don't want to have to re-port my changes every release of Drupal. What needs to happen is user.module be modified to accept a plug-in user authentication method, which can be locally customized, just like sites/defaults/settings.php allows for various other pieces of Drupal. Perhaps that is even the correct place do fit this scheme in.
In my case, I have a table of existing usernames and passwords. I would just import them all into drupal.users except for one major problem: Drupal uses md5() password hashing and my existing table uses crypt(md5) hashing. That's right -- they both use the md5 algorithm, but the resulting strings are vastly different, and as far as we can tell, there's no way to translate them.
At the moment I'm thinking that the user_load(), user_save() and user_pass_rehash() functions be re-written so as to call a configurable hashing algorithm. That would allow me to change the algorithm in my installation from md5() to crypt().
More generally, changes should also occur to allow authenticating the user against a configurable table. This would require slightly more extensive changes in user_load() and user_save(), but should still be straight-forward.
Gary, how does this fit with what you are planning?
..chrisxj
-- [ End user Drupal services and hosting | Sympal.nl ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
No, actually I was just thinking of possibly making small modifications to core to allow site admin-selectable encryption or hashing algorithms for the password, i.e. sort of a hook_hash() call. Other flexibility can all be added via a module, such as yours. Core just seems like the right place that kind of thing, but it could be added to sql_auth easily enough, I guess. In general, I am thinking about what kind of core changes are needed to support -- but not implement -- modular authentication schemes that single-signon and enterprise-wide usage might need. Maybe it will turn out that there are no core changes needed at all (though I do think user.module really needs refactoring), and everything can be done via modules, sql_auth among them. I'm just looking at the big picture because I'm interested in fitting Drupal into the enterprise environment, and because someone else brought this topic up and volunteered to do some work on it. ..chrisxj Bèr Kessels wrote:
Are you talking about making sqlauth a core module? I hope not. It is fien where it is. It does what you describe below, just fine. In case you find any missing (but badly needed) features, the module is open for suggestions and improvement.
Op zaterdag 15 april 2006 18:07, schreef Chris Johnson:
In my case, I have a table of existing usernames and passwords. I would just import them all into drupal.users except for one major problem: Drupal uses md5() password hashing and my existing table uses crypt(md5) hashing. That's right -- they both use the md5 algorithm, but the resulting strings are vastly different, and as far as we can tell, there's no way to translate them.
At the moment I'm thinking that the user_load(), user_save() and user_pass_rehash() functions be re-written so as to call a configurable hashing algorithm. That would allow me to change the algorithm in my installation from md5() to crypt().
More generally, changes should also occur to allow authenticating the user against a configurable table. This would require slightly more extensive changes in user_load() and user_save(), but should still be straight-forward.
Gary, how does this fit with what you are planning?
..chrisxj
participants (6)
-
Adrian Rossouw -
Bèr Kessels -
Chris Johnson -
Gabor Hojtsy -
Gary (Lists) -
naudefj