incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Johns <john...@gmail.com>
Subject Re: usernames on forge-allura.a.o - for ASF committers and for everyone else
Date Tue, 01 Oct 2013 18:09:19 GMT
And I don't see other solution because we can't get around the fact that we
need an additional piece of information, however we choose to have it
displayed or entered by the user.

How is the support for potentially having multiple user neighborhoods in
addition to /u/?  I suspect not great, but that does seem like it would be
reasonable, if practical.


On Tue, Oct 1, 2013 at 2:05 PM, Cory Johns <johnsca@gmail.com> wrote:

> Dave,
>
> Ok, so the issue is that we'll have multiple sources of users, none of
> which are authoritative and which are not mutually unique.  So, to identify
> a user, we now need to know the user account's source in addition to its
> identifier (username).  We need to determine how to represent that
> internally, and how to present it to the user.
>
> Overloading the username to also include the source is probably the
> easiest to implement, since the code currently assumes unique usernames,
> but it means the user is exposed to an implementation detail that changes
> their chosen, public-facing username.  If we go this route, we'll want to
> make sure it's quite clear that the Allura username does not match the
> source username, else the user could get confused when the username they
> log in with doesn't match what is displayed on the page or is in the URL of
> their profile, etc.
>
> Another option would be to store the source separately, but then all of
> the code that assumes a unique username would need to be updated to be
> unique on username + source.  Also, the problem still remains on the
> front-end that we need to know where the user came from, both when logging
> in as well as when indicating a user on the site (e.g., when displaying the
> author of a ticket, we'd have to include the source, or people will end up
> impersonating other users, whether intentionally or accidentally).  But the
> UI could be made better than simply altering the username and expecting the
> user to remember it in whatever new format we decide.  (E.g., there could
> be a "Source" button or drop-down during login, and some sort of source
> icon displayed next to a username any time it is used.)
>
> NB: This issue applies to any additional source of user accounts, such as
> OpenID, social auth, etc.
>
>
> On Tue, Oct 1, 2013 at 11:47 AM, Dave Brondsema <dave@brondsema.net>wrote:
>
>> Either "johndoe_" for non-ASF-committer accounts that anyone could
>> register, or
>> "asf-brondsem" for all ASF committers (backed by LDAP).  Or something
>> along
>> those lines, to keep the Apache LDAP users distinct from the accounts
>> registered
>> locally on forge-allura.apache.org (particularly to avoid username
>> conflicts)
>>
>> On 10/1/13 11:28 AM, Daniel Hinojosa wrote:
>> > I'm concerned about "username fiddling." Would you be able to provide
>> > real examples of what this looks like?
>> >
>> > I care about this as we all tend to pick a persona across platforms;
>> > if this change forces a change in persona (username), that could have
>> > a negative impact on user perception.
>> >
>> > Thank you,
>> >
>> > d.
>> >
>> > --
>> > Daniel Hinojosa
>> > Community Manager, Slashdot Media
>> > p: 415.890.3608
>> > e: d@slashdotmedia.com
>> > facebook: http://facebook.com/d.Slashdotmedia
>> > skype: hinojosad
>> >
>> >
>> > On Oct 1, 2013, at 8:17 AM, Dave Brondsema <dave@brondsema.net> wrote:
>> >
>> >> Any thoughts on this?  It seems complex to me, but I most of the
>> complexity is
>> >> in the dual-login setup, which I think really is important.  The
>> username
>> >> fiddling probably won't be too much additional work.
>> >>
>> >> On 9/19/13 5:38 PM, Dave Brondsema wrote:
>> >>> Before we move tickets over, I think we should have a good login
>> system that'll
>> >>> work long-term.
>> >>>
>> >>> I would like to support ASF committers logging in via ASF LDAP
>> (infrastructure
>> >>> can set up an auth proxy in front of Allura).  If Allura gains
>> popularity among
>> >>> other projects in Apache (and I hope it does), we could have a lot of
>> ASF users
>> >>> on it, and managing that through the official LDAP system will help
a
>> lot.
>> >>>
>> >>> I think we'll also want anyone to be able to create an account so
>> that they can
>> >>> report a bug, make a comment, etc.
>> >>>
>> >>> Setting up an auth provider which can handle both would be ideal.  A
>> problem,
>> >>> though is username conflicts.  Even if we prevent users from
>> registering with
>> >>> usernames that match existing ASF accounts, we could have a future
>> problem if a
>> >>> new ASF committer chooses a username that a "regular" person has on
>> Allura already.
>> >>>
>> >>> A possible solution is to "namespace" the usernames so that these two
>> are
>> >>> separate and can't conflict.  An underscore "_" is not allowed in ASF
>> usernames,
>> >>> so it could be automatically appended to all "regular" Allura
>> usernames (on
>> >>> forge-allura.a.o instance only of course).  Or we could put something
>> on all ASF
>> >>> committer usernames like an "asf-" prefix.  I prefer to keep the ASF
>> committer
>> >>> usernames unchanged since they will be the biggest potential users of
>> Allura, so
>> >>> I'd go with johndoe_ format for non-ASF accounts on our instance of
>> Allura.
>> >>>
>> >>> Messing with people's usernames is kind of ugly, but at least with
>> them
>> >>> separated we'll have a clear distinction between the types and thus
>> be able to
>> >>> make changes later, if needed.
>> >>>
>> >>> Thoughts, or better ideas?
>> >>>
>> >>> If we agree, we can begin working on this in a custom authentication
>> provider.
>> >>
>> >>
>> >>
>> >> --
>> >> Dave Brondsema : dave@brondsema.net
>> >> http://www.brondsema.net : personal
>> >> http://www.splike.com : programming
>> >>              <><
>> >
>>
>>
>>
>> --
>> Dave Brondsema : dave@brondsema.net
>> http://www.brondsema.net : personal
>> http://www.splike.com : programming
>>               <><
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message