On Sun, Jan 11, 2009 at 7:46 AM, Victor Boctor <firstname.lastname@example.org> wrote:Yeah, SF is doing the same (though I can't really understand why
> 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
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.
I think we can, every OpenID provider I registered with verify the
> 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?
email. However, it is completely up to us to decide if we want to
revalidate the address.
I am not sure, the only site I use where openid is used for
> 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.
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.
Ok, my laptop is now online at http://giallu.selfip.org. You can
> I would be interested in getting access to an instance with your changes /
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.
SYSTEM WARNING: Zend_Loader::include_once(Zend/Uri/Http.php) [zend-loader.include-once]: failed to open stream: No such file or directory
I can't make anything more stable right now, since my home machine is dead...
Yeah. I need to note here that if we go the Zen_OpenID route, then the
> 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.
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.
I can see the value in the "no db changes" part, but overall I'm not
> 2. The advantage of RpxNow is simpler implementation / no db changes.
> However, using Zend and talking no dependency would be fine.
sure about the "simpler implementation". Anyway, let's judge by
yourself as soon as I manage to push this stuff somewhere...
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.
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