[geeklog-devtalk] Remote Authentication ;-)

[Blaine Lang]

This is sounding like a major change and effects all plugins and core 
features. I'm not looking forward to all the work this is going to create 
for me and my plugins. I'm not against it but don't fully appreciate the 
benefits and see how many users/sites actually want this feature or use it.

This is where having the ability to vote on new features and their priority 
would be handy.

I've been trying to follow this discussion which is hard is made harder in 
email vs a forum so maybe I'm missing something.
A few questions:

1) Will this help address having alternative authentiation like NTLM or AD 
autentication ?
2) Will there be records created for all remote users as well?
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.
4) Will site admin's have the ability to moderate and approve new users 
still?
5) Will site admin's have the ability to selectively block remote services 
or disable reg users for a particular remote service

I can't even begin to think of how many places I access the users table 
directly today in all my plugins and don't fully see yet the impact this 
change will have.
I hope we take a deep breath on this one before adding - but maybe I'm 
missing something.

Regards,
Blaine


----- Original Message ----- 
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devtalk at lists.geeklog.net>
Sent: Thursday, February 03, 2005 4:57 PM
Subject: Re: [geeklog-devtalk] Remote Authentication ;-)


Mike,


>When I log in to my server as a remotely authenticated user, then I have no

>garentee that the username is unique.


Right.

Technically, this wouldn't be a problem, though as Geeklog uses the UID
internally anyway. So once you're past the authentication, it doesn't
matter how many Mikes there are - Geeklog can safely tell them apart.

Obivously, however, the users of the sites may have a problem then.



>My prefered solution is to register the remote users as

>username at remoteservice which clearly marks their accounts as something 

>else,

>to users who are reading who commented.


Btw, making the usernames look like email addresses isn't a good idea
since this will cause innocent bystanders who happen to have that email
address to get more spam.



>I could display (blogger account) or (livejournal account) or @blogger.com

>by spitting out the remote authentication details perhaps. But how many

>places in core would I have to make the change? How many plugin authors

>would have to update their modules (forum, journal, staticpages (in core of

>course)...)


Okay, I see the following ways to approach the problem:

1) Accept duplicate usernames
   + easy to implement ;-)
   - confusing

2) Add indication of service to the username
   + easy to implement
   - may break other plugins / add-ons or layouts(!)
   - no guarantee of unique username, at least for short usernames
     (mike AT blogger.com has 16 characters and may already exist)

3) Ask user to select a new unique username
   - annoying, might as well ask them to register ...

4) Like 1) but provide a display function
   + flexible
   - displaying the username has to be changed everywhere

Despite the extra work involved, my vote would be for #4. This would tie
in nicely with a feature request to optionally display the full name
instead of the username, which is somewhat half-implemented in CVS at the
moment. If we would use COM_getDisplayName everywhere, we could provide
hooks (or templates) to format the actual name that is display in
whatever way you prefer.

I think that at least all the important plugins would be updated in no
time after the 1.3.12 release. The others would still display the
"traditional" username and we'll see how much confusion that really causes.

This actually needs some more thoughts about which functions to provide,
as COM_getDisplayName currently does an SQL request which is unnecessary
if you already have all the information available and only need to know
which to display. So we'll probably end up with 3 or 4 similar functions
from which you can choose the one that fits your code.

Please note that this is only my opinion at this point in the discussion.
I'm open for other arguments or solutions.



>I guess there is already an index on username?


Actually, no. But that would be easy to add (and would make sense anyway).



>My other question I had to ask, was about adding to a custom group. I've 

>not

>spent much time around the group/feature stuff to be honest. How would you

>suggest doing this? Just a new core group with a name? Do I need to add any

>features to it? Or would that all come from Authenticated User?


No special features required. Just create a new core group and add all
remotely authenticated users to it.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/

_______________________________________________
geeklog-devtalk mailing list
geeklog-devtalk at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devtalk