On Sun, Jun 20, 2010 at 7:14 PM, Ethan Jewett <[email protected]> wrote: > Just catching up here, but I seem to remember that originally if you tried > to log in with an OpenID that was not associated with an account, it created > an account and prompted you for several pieces of information, including the > username you would like to use. Once you chose a username, it was not > possible to change it, but the username was not defaulted to the OpenID. > This was pretty nice functionality, but if we're going to container-based > authentication anyway then I agree it's not worth recreating. > > Interesting related question: What is our behavior going to be if someone > logs in with a valid container-based account that does not have a user set > up in ESME? I think we would want to do something like what we originally > did with OpenID: prompt for first name, last name, and username.
Excellent question - I hadn't thought about that. Maybe, we can have common routine for both cases. > > Ethan > > On Mon, Jun 14, 2010 at 5:25 AM, Richard Hirsch <[email protected]>wrote: > >> I agree with Vassil. If I remember correctly, users created via OpenID had >> their openid urls as their user ids which messed up our UI. >> >> The one idea I had was to add the OpenID to the sign-up page and created a >> JIRA item for this. I looked at the code in the ProfileMgr that dealt with >> this in the profile and decided that adding the openID to the sign-on page >> was non-trivial and thus placed the jira item in the backlog. >> >> On Mon, Jun 14, 2010 at 12:16 PM, Vassil Dichev <[email protected]> >> wrote: >> >> > > And my question still remains the same ;-) >> > > Should we use time on this right now, or would it be easier to remove >> the >> > field in the UI for now? >> > >> > Sorry for not following up on this: I had the impression that OpenID >> > worked as intended and the user is not supposed to create a user >> > through OpenID. This would mean that the username would be >> > autogenerated and currently you cannot edit the username. This is not >> > a hard requirement, but do we want to make the username editable? It >> > might make some implications for using existing pools, actions, etc. >> > (not that they're bound to the username, but an attacker might use it >> > for phishing/social engineering). >> > >> > Another drawback of OpenID user auto-creation is that a user will not >> > have a password initially, and might not ever choose to set it. I'm >> > not sure this is desirable, considering that OpenID might not always >> > be available and there's no other way to log in. >> > >> >> Good point - the necessity of having two logins is feature :-> >> >> >> > Finally, from usability point of view if you think you have associated >> > an OpenID URL with an existing account, but you're not, then logging >> > in with OpenID will create a new account you do not want. This is >> > especially tricky considering that we treat these as different URLs: >> > >> > http://host/path/ >> > http://host/path/index.html >> > http://host.domain.com/path/ >> > >> > So is OpenID actually broken? If it's not, there's no point in fixing it. >> > >> >> I also agree with Anne that in the long-term, we will probably have >> container-based authentication, so investing more time in OpenID probably >> isn't ideal. >> >> > >> > Vassil >> > >> >
