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.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 >>>>> <>< >>>>> >>>> >>>> >> > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
