[geeklog-devtalk] Remote Authentication ;-)

[Michael Jervis]

> Just like to add an option #5:


I've been thinking along the same lines overnight.

Dirk's proposal of #4 is a big change to so much. But I do agree that
username at blogger.com to login is a bit of a pain. Username
<select>blogger</select> works better.

But, the problem is when you get into the drupal/geeklog auth. I was
planning on setting up geeklog so people can auth from one geeklog instance
to another. Then you don't have a finite list of servers, unless you
configure one manualy. Then you have the problem that you are cutting out
much of the net if you don't know it's there. Which I guess helps keep
spammers out.

I suppose that would make this "Remote Service Based Authentication" rather
than my original vision (stolen ;-)) of authenticating via other sites in
general.

But having
Login:
Username []
Password []
Service [this site]
        [blogger]
        [livejournal]
Or Authenticate via Typekey (link)
Or Register

Is a good enough solution for me, it allows registration via the widest
range of services, it still allows the extension of the system to further
services. Which the custom buttons didn't I think.

TO addresss blaine's concerns:


> against it but don't fully appreciate the benefits and see 

> how many users/sites actually want this feature or use it.


I think typekey.com say it best (https://www.typekey.com/faq/): 
----
Prior to our creation of TypeKey, we were never completely sold on comment
registration for one major reason: most webloggers we spoke to (including us
at Six Apart) will not take the time to register for an individual account
on every weblog they read and comment on. While some will, the vast majority
said it was too much a barrier to the conversation and that they didn't want
to maintain tens or hundreds of logins. And even if they did register for
many different accounts on many different weblogs and chose just to use the
same easy to remember username/password, they did not feel comfortable
passing this information to the weblog owner.
----

This lowers the barrier for entry to non-anon comment posting across
weblogs.


> 1) Will this help address having alternative authentiation 

> like NTLM or AD autentication ?


No. NTLM Authentication and AD authentication would be implemented the way
you say you already did. They are omni-present network identities that would
negate the need to ever see the login form and hit login, as you are already
identified on the netwrok. NTLM/AD auth would work slightly differently.


> 2) Will there be records created for all remote users as well?


Yes. My current implementation already does so, I would argue strongly that
a future implementation should do, and it should be transparent to any other
code. As my implementation and Vincent's Option Five.


> 3) There are at least 6 tables currently updated for a new 

> user + any plugin function. How will this effect plugins 

> functions that are triggered on user add/edit/delete.


I call the standard USER_createAccount function, this is where calls to
custom/plugin user triggers are fired, and updates the 6 tables etc.



> 4) Will site admin's have the ability to moderate and approve 

> new users still?


Yes, USER_createAccount does this.


> 5) Will site admin's have the ability to selectively block 

> remote services or disable reg users for a particular remote service


My base implentation does this. You would remove Blogger.auth.class.php or
LiveJournal.auth.class.php to block that service, or toggle the config to
block all remote auths. When I was planning Drupal.auth.class.php I was
planning an array of allowed remote instances, optional, so it could be
removed to allow all. Not so sure now.

Personaly, I find it easier to follow this discussion on the mailing list,
but obviously Blaine doesn't, and the number or participants is low. Should
this be something opened to wider discussion on the forums at geeklog.net?

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/20050204/f4bf556b/attachment.bin>