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