[development] Generic Authentication Bridging

[Bèr Kessels]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060416/6e09c854/attachment-0001.pgp