esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Broken OpenID
Date Sun, 20 Jun 2010 17:14:06 GMT
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.


On Mon, Jun 14, 2010 at 5:25 AM, Richard Hirsch <>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 <>
> 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
> >
> >
> > 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message