[geeklog-devtalk] Remote Authentication ;-)

[Vincent Furia]

Just like to add an option #5:

Make '@' or some other special character illegal in regular usernames.
 When people log on using remote authentication, have a username box
and a drop down box of available services (each service with a unique,
non-dotcom name; i.e. blogger).  The username goes into the database
as username at service (where '@' is whatever symbol we choose).

It seems like the best of all worlds.  I'd vote for '@' to be the
unique symbol as it is commonly read as the word 'at'.  Still, without
blogger.com it won't be an email address so we won't annoy anybody and
if we're lucky some spammer will harvest the address and waste a cycle
or two spamming a non-existent domain...

-Vinny


On Thu, 3 Feb 2005 22:57:19 +0100, Dirk Haun <dirk at haun-online.de> wrote:

> 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

>