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