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 22:05:14 GMT
Well, I think it's the natural place for this separation.  I think it will
take a bit of work to remove the hard-coded assumptions that there is only
one user neighborhood, and we'll need to figure out how to best represent
users from different neighborhoods in the UI, but I definitely think it's
doable.

On the login side, I assume we'll have a separate LDAP login page, so the
normal login page can continue to assume the existing Users neighborhood,
while the new login page(s) can use the appropriate neighborhood, or
provide a UI for the user to select, as appropriate.

As for indicating the neighborhood / source to the end user, I think /.'s
somewhat recent addition of social login has a good solution: for users
other than the normal Users neighborhood, we could have a small icon that
we display next to the username to indicate where they're from, even if
their username otherwise conflicts.

The more I think about it, the more I think this is the right approach.


On Tue, Oct 1, 2013 at 4:04 PM, Roberto Galoppini <
roberto.galoppini@gmail.com> wrote:

> 2013/10/1 Cory Johns <johnsca@gmail.com>:
> > 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.
>
> While I believe for people not familiar with neighborhoods this might
> sound hard to get, I believe your approach makes a lot of sense to me.
>
> Roberto
>
>
> >
> > 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