Status of OpenID Consumer in Bugzilla

Martin Atkins mart at degeneration.co.uk
Fri Jul 1 09:59:52 UTC 2005


Rob Lanphier wrote:
> *  Where should the OpenID URI be stored?

LiveJournal does this by having a separate identity map table. Every new 
OpenID user gets a userid magically allocated and an entry placed into 
the map table which is essentially a (userid, identity) pair. This seems 
reasonable since it doesn't inflate any other tables and add needless 
indexes for sites which aren't using OpenID.

If you're eventually going to need to separate out email addresses 
anyway, perhaps it would be a good idea to have a "user" table and an 
"identity" table. The "user" table would just have a numeric userid that 
no-one ever sees, while the identity table would store one or more ways 
that user can log in. A type field which can be either "email" or 
"openid" can differentiate the two. Not sure where you'd put the 
password in the email case, though. Need to think about this more.

This would obviously be separate from the contact email address used 
when a user adds himself to CC: or whatever, as many OpenID users will 
probably still want to recieve email. Users would also have to choose a 
primary "display" identity, which dictates which of the identities will 
be used on the website to identify a user. I imagine that some 
installations will want the ability to mandate a contact email address, too.

> *  Should user log in using email or by OpenID?

Ideally in the long term Bugzilla shouldn't need to know email 
addresses, I think. However, I realise that right now the email address 
is essentially Bugzilla's primary key so you can't really get rid of 
them that easily. Automatically allocating a gibberish email address 
wouldn't fly because users would then be unable to opt to recieve email 
without changing it.

> *  Should email verification process still occur?

No. As above, ideally Bugzilla shouldn't need my email address unless I 
want to be contacted through it, in which case I'll provide it when I've 
logged in. The address I'm identified by on LiveJournal's bugzilla 
installation doesn't actually work anymore, but I've done nothing about 
it because I don't want email from Bugzilla anyway. I don't really see 
why I should have to provide it if I'm not going to use it as a login 
identifier, especially on LiveJournal's Bugzilla where email isn't used 
as a primary means of contact.

> *  Should a confirm hash style verification (ala Mailman or GForge) be
> created, as opposed to mailing a password to the user?

Given that I don't want email verification at all, I think I can ignore 
this one. ;)

> *  How should createaccount.cgi modification be done?

I don't really know enough about the Bugzilla code to answer this, but 
what you've written on the wiki (about making a separate create_account 
function) seems like a good idea in general anyway.

> I'd like some other opinions on this, as well.  Since I'm not personally
> going to be running this in production (I'm just doing this to learn how
> OpenID and BZ work), it'd be good to hear from someone who will be
> running in production.

My idea of how I'd like this to work in an ideal world is as follows:
* OpenID identities rather than email addresses are used as the user 
identifier in the interface. (or, more likely, allow both)
* To log in with OpenID, I just supply my OpenID URL and no password.
* For migration purposes, existing users should be able to log in by 
email address and then do an OpenID login to add a new identity to that 
account.

In the interests of getting a working version out quickly, though, I'd 
accept as a short term solution just binding an OpenID identity to an 
existing email-bound account. That way I won't have to remember my 
password. :)


(I should probably note, since this is also going to a mailing list 
where I'm a stranger, that despite the LiveJournal references here I'm 
not a LiveJournal staffer and the opinions here are mine alone rather 
than any kind of Six Apart-endorsed wishlist.)




More information about the developers mailing list