[development] Generic Authentication Bridging
chris at tinpixel.com
Mon Apr 17 03:01:03 UTC 2006
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
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.
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
> 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
>> Gary, how does this fit with what you are planning?
More information about the development