You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2013/09/19 23:38:59 UTC
usernames on forge-allura.a.o - for ASF committers and for everyone
else
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
<><
Re: usernames on forge-allura.a.o - for ASF committers and for everyone
else
Posted by Dave Brondsema <da...@brondsema.net>.
Yesterday I talked with Cory and other SourceForge developers in person about
some ideas we have for social auth (login with facebook, twitter, etc). We
thought about applying the multiple-user-neighborhoods idea in that context too,
but thought it'd be better to have just one uniform set of usernames.
What we could do for both ASF logins and social auth logins is to track the
remote auth (facebook, LDAP proxy, etc) on the user record, so that's where the
association is stored. And then if a username is already taken, prompt the user
to pick a new allura username.
That would mean for the forge-allura.a.o s that everyone uses their preferred
username, there is no namespacing to separate username types, but the database
stores which login system is used. And then in the rare case of an ASF
committer whose username was taken by someone else on Allura, then they'll have
to pick a different Allura username, but it'll still be tied back to their ASF
committer credentials.
On 10/2/13 6:16 PM, Dave Brondsema wrote:
> On 10/1/13 6:05 PM, Cory Johns wrote:
>> 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.
>
> Yep, I agree. I think its worth exploring. Even if it's some work, having
> /u/johndoe and /asf/johndoe as separate accounts is probably worth it in the
> long run to avoid username-munging.
>
>>
>> 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.
>
> Yes, that's my assumption also. I think once we know how we'll set things up,
> we can ask Infra to make a certain URL invoke LDAP authentication before the
> request gets to Allura itself.
>
>>
>> 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.
>
> That should work fairly well for regular links and text. The other place where
> we use usernames is in drop-downs (e.g. ticket assignment). That'll probably
> take a bit more work there.
>
>>
>> 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 <jo...@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 <jo...@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 <da...@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
>>>>>> <><
>>>>>>
>>>>>
>>>>>
>>>
>>
>
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: usernames on forge-allura.a.o - for ASF committers and for everyone
else
Posted by Dave Brondsema <da...@brondsema.net>.
On 10/1/13 6:05 PM, Cory Johns wrote:
> 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.
Yep, I agree. I think its worth exploring. Even if it's some work, having
/u/johndoe and /asf/johndoe as separate accounts is probably worth it in the
long run to avoid username-munging.
>
> 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.
Yes, that's my assumption also. I think once we know how we'll set things up,
we can ask Infra to make a certain URL invoke LDAP authentication before the
request gets to Allura itself.
>
> 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.
That should work fairly well for regular links and text. The other place where
we use usernames is in drop-downs (e.g. ticket assignment). That'll probably
take a bit more work there.
>
> 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 <jo...@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 <jo...@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 <da...@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
>>>>> <><
>>>>>
>>>>
>>>>
>>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: usernames on forge-allura.a.o - for ASF committers and for
everyone else
Posted by Cory Johns <jo...@gmail.com>.
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 <jo...@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 <jo...@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 <da...@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
> >>> <><
> >>>
> >>
> >>
>
Re: usernames on forge-allura.a.o - for ASF committers and for
everyone else
Posted by Roberto Galoppini <ro...@gmail.com>.
2013/10/1 Cory Johns <jo...@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 <jo...@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 <da...@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 <da...@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
>>> <><
>>>
>>
>>
Re: usernames on forge-allura.a.o - for ASF committers and for
everyone else
Posted by Cory Johns <jo...@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.
On Tue, Oct 1, 2013 at 2:05 PM, Cory Johns <jo...@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 <da...@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 <da...@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
>> <><
>>
>
>
Re: usernames on forge-allura.a.o - for ASF committers and for
everyone else
Posted by Cory Johns <jo...@gmail.com>.
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 <da...@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 <da...@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
> <><
>
Re: usernames on forge-allura.a.o - for ASF committers and for everyone
else
Posted by Dave Brondsema <da...@brondsema.net>.
Yes, we've had some thread on the infra mailing list already. They sounded in
favor of LDAP + local, and said an authenticating proxy in front of Allura
should be easy to do (then Allura just trusts that to determine ASF logins)
On 10/2/13 4:36 PM, Rich Bowen wrote:
> Also probably important to ensure that Infra is looped in early in the process,
> so that they can advise us as to what's easy/hard/impossible before we invest a
> lot of time in it.
>
> --Rich
>
> On 10/01/2013 11:47 AM, Dave Brondsema 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 <da...@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
<><
Re: usernames on forge-allura.a.o - for ASF committers and for everyone
else
Posted by Rich Bowen <rb...@rcbowen.com>.
Also probably important to ensure that Infra is looped in early in the
process, so that they can advise us as to what's easy/hard/impossible
before we invest a lot of time in it.
--Rich
On 10/01/2013 11:47 AM, Dave Brondsema 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 <da...@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
>>> <><
>
>
--
Rich Bowen
rbowen@rcbowen.com
Shosholoza
Re: usernames on forge-allura.a.o - for ASF committers and for everyone
else
Posted by Dave Brondsema <da...@brondsema.net>.
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 <da...@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
<><
Re: usernames on forge-allura.a.o - for ASF committers and for
everyone else
Posted by Daniel Hinojosa <dh...@slashdotmedia.com>.
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 <da...@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
> <><
Re: usernames on forge-allura.a.o - for ASF committers and for everyone
else
Posted by Dave Brondsema <da...@brondsema.net>.
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
<><