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 doe
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 h
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,
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 user
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
inter
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 th
2013/10/1 Cory Johns :
> 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
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
d
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
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 e
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 neighbor
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 usern
12 matches
Mail list logo
