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.galopp...@gmail.com> wrote: > 2013/10/1 Cory Johns <john...@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 <john...@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 <d...@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 <d...@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 : d...@brondsema.net > >>> >> http://www.brondsema.net : personal > >>> >> http://www.splike.com : programming > >>> >> <>< > >>> > > >>> > >>> > >>> > >>> -- > >>> Dave Brondsema : d...@brondsema.net > >>> http://www.brondsema.net : personal > >>> http://www.splike.com : programming > >>> <>< > >>> > >> > >> >
