[geeklog-devtalk] Remote Authentication ;-)

[Michael Jervis]

> established.  He is therefore uid 6 also (but his password 

> may or may not work depending on the implementation, do we go 

> through the API to authenticate every time or just on the 

> first login?)


To save you a read, the logic is:

authenticated = standard local user login
If not authenticated and remote authentication enabled and remote service
specified then [1]
 authenticated = remote authentication attempt
End if
 
remote authentication attempt:
Local password = Load cached md5 of password for remote user
If hash(submitted passwod) = local password then
 return true
Else
 authenticated = API to remote server
 if authenticated and local password exists then
   update local password
   return true
 elseif authenticated the
   create local user
   return true
 else
   return false
 end if
End if

[1] - Can be changed to:
If remote service not specified then
Authenticated = standard local user login
Elseif remote authentication enabled
Authenticated = Remote authentication attempt
End if

Due to some changes, but I've not done that yet. Note to self really. Just
realised. ;-)


> I see that Blogger also told you my email address. And when I 

> typed in my password, it dawned on me that this is a great 

> way to collect other people's login credentials ...


The worst thing really, is that geeklog gets the users unencrypted
livejournal/blogger password. An unscrupulous admin could do interesting
things, by modifying the code to also store it plaintext for later use.
 

> How does Drupal handle that?


Willful ignorance is the best description I think. They just assume only
trust-worthy people would set up a site that allowed LJ/Blogger/etc auth.


> Sorry, forgot to point out one detail: Of course we have to 

> store the other site's username somewhere (Mike's 

> implementation actually does

> that) so that we can tell them apart.


Not anymore. I scrapped table 2 and didn't add a new column.

Now, if we really must trim the username to 16 chars (inc @service) then
I'll re-add a column to store original username. But then we're back to
really needing COM_displayName or whatever it was. I'd suggest having that
function do:

If function_exists('custom_format_username') Then
  return custom_format_username( username, full name, remote name, email,
uid );
else
  If show username then
    Return username
  Else if show full name
    Return full name
  End if
End if

Where custom_format_username (or something more suitable) is a function
admin's can define in lib-custom.php. Downside of this of course is that we
have to change the entire of core to use COM_displayName, and hope plugin
writers upgrade for consistency. Although displaying username still won't be
too bad as MOST of the time it'll be unique.

I guess calling COM_displayName is a neat feature to have, as then you have
the username/full name/other toggle in core ready to go for that feature
request, but, I /still/ think a 60 char username field with no trimming of
remote users is the best solution.

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3030 bytes
Desc: not available
Url : <http://eight.pairlist.net/pipermail/geeklog-devtalk/attachments/20050205/4d16d62e/attachment.bin>