Replies inline.

On Sun, Jan 11, 2009 at 6:36 AM, Gianluca Sforna <> wrote:
On Sun, Jan 11, 2009 at 7:46 AM, Victor Boctor <> 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 on
> 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, we
> should allow the users to create an association, e.g. like your suggestion
> below.  Or there are alternative options.

I am not sure, the only site I use where openid is used for
authentication purposes is, 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 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 or whatever.

Checkout which uses RpxNow as well as providing the hints.

When I tried your site I got the following:

SYSTEM WARNING: Zend_Loader::include_once(Zend/Uri/Http.php) [zend-loader.include-once]: failed to open stream: No such file or directory

SYSTEM WARNING: Zend_Loader::include_once() [function.include]: Failed opening 'Zend/Uri/Http.php' for inclusion (include_path='/var/www/mantis/mantisbt-public/core/:.:/usr/share/pear:/usr/share/php') 

I can't make anything more stable right now, since my home machine is dead...
[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 tracker.

Gianluca Sforna

Check out the new Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
mantisbt-dev mailing list