On Sun, Jan 11, 2009 at 6:36 AM, Gianluca Sforna <giallu@...> wrote:
> On Sun, Jan 11, 2009 at 7:46 AM, Victor Boctor <vboctor@...> wrote:
> > 1. A user should be able to associate multiple OpenIDs with the same
> > account. This is supported in the current implementation that is based
> > RpxNow.
> Yeah, SF is doing the same (though I can't really understand why
> that's really useful). This can be implemented in different ways, the
> easiest would be to allow the openid field in the user table to be a
> comma separated list of OpenIDs. If needed, we can come up with a
> separate table storing the IDs and their association with the users.
[Victor] This is useful if users change OpenID providers. I would rather
have a mapping table with id, openid_url, user_id.
> > 2. Can we trust the email address associated with the OpenID? i.e. is it
> > already verified? Should we send a confirmation email on sign up?
> I think we can, every OpenID provider I registered with verify the
> email. However, it is completely up to us to decide if we want to
> revalidate the address.
[Victor] The risk is if an attacker create their own provider. I think in
this case we are exposed. The question is whether we want to re-validate
email address or have a set of trusted providers. I think we will be more
OpenID compliant if we go with the former.
> > 3. We should not match OpenIDs with existing accounts via email address,
> > should allow the users to create an association, e.g. like your
> > below. Or there are alternative options.
> I am not sure, the only site I use where openid is used for
> authentication purposes is sf.net, and they implement the manual
> association step. All the others are blogs where the openid is used to
> add comments instead of captcha or registration.
> > I would be interested in getting access to an instance with your changes
> > patch.
> Ok, my laptop is now online at http://giallu.selfip.org. You can
> register an new account and try it out; I'll leave it online for the
> next 12 hours, then it will be back again when I'm at home.
[Victor] The main issue with your interface is that the users don't get any
clue of what they need to type. Two main challenges:
1. What are OpenIDs? For example, a lot of people won't know the Yahoo,
Gmail, etc are OpenIDs.
2. What is the mask to use? One of the advantages of RpxNow is that it
provides a widget that gives hint about supported providers that creates a
url from a user name.
Other sites provide a list of the famous providers next to the login with
username.myopenid.com or whatever.
Checkout http://stackoverflow.com which uses RpxNow as well as providing the
When I tried your site I got the following:
SYSTEM WARNING: Zend_Loader::include_once(Zend/Uri/Http.php) [
failed to open stream: No such file or directory
SYSTEM WARNING: Zend_Loader::include_once()
Failed opening 'Zend/Uri/Http.php' for inclusion
> I can't make anything more stable right now, since my home machine is
[Victor] That's fine, let us know when a more stable one is available.
> > Preferences related to implementation details:
> > 1. Implement so that it is easy to migrate to a plugin when auth plug-ins
> > are available. Paul was considering to work on this soon based on some
> > previous work done by him and John.
> Yeah. I need to note here that if we go the Zen_OpenID route, then the
> next logical step would be to try out the Zend_Auth component, which
> is sort of pluggable and support, out of the box, HTTP, Digest, LDAP
> and of course OpenID auth schemes.
[Victor] I agree that it would be best if we design the auth plugin support
and provide a plugin that works with Zend_Auth or Pear one. This way we get
support for multiple auth. This will also mean that we have the right
events to support plugins that implement such auth mechanisms without
dependency on such frameworks.
> > 2. The advantage of RpxNow is simpler implementation / no db changes.
> > However, using Zend and talking no dependency would be fine.
> I can see the value in the "no db changes" part, but overall I'm not
> sure about the "simpler implementation". Anyway, let's judge by
> yourself as soon as I manage to push this stuff somewhere...
[Victor] I think it is less risk to have a raw open id support (i.e. the
approach you are taking). However, we have to provide the hints to the user
as I suggested above. I see the widget as a major usability improvement.
> All in all, this means you are ok with replacing the rpxnow based
> solution? I'm asking because I am probably going to work elsewhere if
> this has no chance of being pushed now.
[Victor] Yes, I'm ok with moving towards a raw implementation. My target is
for 1.2 to have Open ID support. I believe RpxNow can give us support to
more than OpenID, but this can be added as a plugin later. I see that
OpenID will help remove the barrier for entry for a lot of users to try
MantisBT / report issues for us and projects using MantisBT as their bug
> Gianluca Sforna
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> mantisbt-dev mailing list