Closed Bug 294608 (bz-openid) Opened 19 years ago Closed 12 years ago

Support OpenID as a an account source and login verification method

Categories

(Bugzilla :: User Accounts, enhancement, P1)

2.19.3
enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mkanat, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [roadmap 4.0])

Attachments

(3 files, 1 obsolete file)

OpenID is a new distributed authentication system. Basically, people can set up
any particular site as an "authentication server," and then if they're logged
into that server, they can automatically log themselves in to any service that
supports OpenID.

That is, the concept is like, "If I'm logged into bugzilla.mozilla.org, I can
log into bugzilla.redhat.com."

Info about OpenID is at http://www.danga.com/openid/

This would solve people's request for a "central Bugzilla account database."
To be fair, this probably actually has two parts: An OpenID client, and an
OpenID server.

The OpenID client would probably be easiest. Each deserves a separate bug, once
somebody actually starts working on them. This bug should become one of those
two bugs, but I'm not sure which one yet, until I think more about the
implementation.

The client, at least, depends on the login-name/email-address separatation, I think.
Depends on: 218917
I think that the most useful thing right now would be to get a working client,
and then the server could be something else.

This was based on some discussion over here:

http://www.livejournal.com/users/brad/2120086.html?thread=10381974#t10381974
Summary: OpenID support for Bugzilla → Support OpenID as a an account source and login verification method
Feel free to assign this bug to me.  I'm working on it, and have the raw
mechanism working (nothing remotely usable in production).  I've started a wiki
page to work on open issues:

http://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin

Please direct comments there.
I think we should *always* use profiles.extern_id, but we can make that field
longer if need be.
Assignee: user-accounts → robla
Target Milestone: --- → Bugzilla 2.22
Version 0.1.0 of BZ/OpenID consumer support. Tested against BZ/CVS -
2005-07-01.  Verify/OpenID.pm is the only other required file, which I will
attach next.
Attachment #188009 - Flags: review?(mkanat)
New OpenID Auth/Verify plugin.	Use with patched CGI login method
Attachment #188010 - Flags: review?(kiko)
Attachment #188009 - Flags: review?(mkanat) → review?(kiko)
One thing I don't see in your patches is a check in checksetup.pl that
Net::OpenID::Consumer, and possibly LWPx::ParanoidAgent are actually installed...
This version does proper checking for required modules, addressing problem
observed by Colin Ogilvie
Attachment #188009 - Attachment is obsolete: true
Attachment #188469 - Flags: review?(kiko)
Attachment #188009 - Flags: review?(kiko)
Comment on attachment 188469 [details] [diff] [review]
Patch to existing BZ files needed to add OpenID support (v0.1.1)

>Index: index.cgi

>-#!/usr/bin/perl -wT
>+#!/usr/bin/perl

huh???
Comment on attachment 188469 [details] [diff] [review]
Patch to existing BZ files needed to add OpenID support (v0.1.1)

defparams.pl no longer exists
Attachment #188469 - Flags: review?(kiko) → review-
It's going to be a while before I get to fixing this up.  Regarding the need to
turn off taint checking (Frédéric Buclin's comment on 2005-08-13), that's a
problem in the OpenID perl library.  Fixing the OpenID perl library will make it
so that taint checking can stay on in Bugzilla.

If there's someone itching to get this done, I'm happy to hand this off to a
suitable maintainer.
The trunk is now frozen to prepare bugzilla 2.22. All enhancement bugs are retargetted to 2.24 or --- depending on how active the assignee is.

If I understand Rob correctly in comment 11, he isn't sure to have time to fix it for 2.24. So retargetting to ---. Feel free to get it back to 2.24 when you are working on it again.
Target Milestone: Bugzilla 2.22 → ---
Comment on attachment 188010 [details]
OpenID support, derived from LDAP verify plugin.

This module should satisfy the new Auth structure, see bug 300410.
Attachment #188010 - Flags: review?(kiko) → review-
I've not looked at this code in a couple of years, and don't plan to fix it up.  Reassigning to "nobody" to make it clear that I'm not working on it anymore.
Assignee: robla → nobody
Assignee: nobody → nobody
Adding support for OpenID would be a great way to assist in the spam problem that has started popping up in Bugzilla instances. This feature would allow Bugzilla software to decentralize the login problem and let people help each other deal with spammers instead of each Bugzilla administrator needing to deal with it on their own. OpenID combined with whitelisting would be very effective, especially if multiple open source projects share their whitelists with each other. Take a look at Simon Willison's blog on Social Whitelisting with OpenID for more info: http://simonwillison.net/2007/Jan/22/whitelisting/

It would be great if one of the bugzilla developers would be willing to work on this bug so it OpenID support could be built-in to a future version of Bugzilla.
Even VeriSign support now OpenID and run a server for authentication's.
I think it is really required to add this feature as a standard Sign In technologies in Bugzilla and even on mozilla.org (or are their other requests running? 

See: https://pip.verisignlabs.com/
  Yeah, this is becoming pretty important and widely demanded. We should roadmap it for 4.0, if nobody gets it for 3.2.
Priority: -- → P1
Target Milestone: --- → Bugzilla 4.0
Nice ;)

I opened a "high level" bug on this issue cause not only Bugzilla is affected.
See https://bugzilla.mozilla.org/show_bug.cgi?id=400598
Depends on: 413617
Okay, I figured out how to do this!

If OpenID is enabled, we provide an additional box beneath the login form for their OpenID.

We create a user based on a special pattern: openid_(random_string)@(the OpenID domain used). Or, if the emailregex doesn't allow @, we don't include the @ part. The user has a '*' password in the DB (meaning he can't log in via password), and has email disabled. On his account preferences screen, instead of password & email, we have a button to "upgrade to full account", and a box for an email addresss which is then confirmed by a token, and you give a password.

We convert extern_id to being a max of 255 characters (if it isn't already) and store the OpenID URL in there. 255 characters *should* be enough for any OpenID URL that I know if, and any longer string isn't indexable (and we definitely don't want to be doing a table scan on the profiles table).
(In reply to comment #20)
> any longer string isn't indexable (and we definitely
> don't want to be doing a table scan on the profiles table).

According to MySQL docs, as of 4.1.2, the maximum index prefix length is storage-engine dependent, and is 767 bytes for InnoDB, 1000 bytes for MyISAM:

http://dev.mysql.com/doc/refman/4.1/en/create-index.html

According to the Bugzilla website, MySQL 4.1.2 or higher is required for the latest version, so actually you should be able to allow the ID's to be somewhat longer while still being able to index them fully, if you wanted.

Having a short prefix won't much reduce the value of the index for retrieval anyway, AFAIK.  MySQL can use the prefix to cut down the result set and go directly to the relevant rows.  Otherwise they wouldn't be of much use.  :)  You can't, of course, use them for covering indexes, and I imagine not for sorting (although maybe MySQL is cleverer than I think).

Disclaimer: I know nothing about Bugzilla, only something about MySQL.
(In reply to comment #21)
> According to MySQL docs, as of 4.1.2, the maximum index prefix length is
> storage-engine dependent, and is 767 bytes for InnoDB, 1000 bytes for MyISAM:

  Yes, but the maximum varchar size in MySQL 4.1 is 255.

  There are also other problems with indexing TEXT-type fields in other DBs.
why you like to disable email? 
IMHO it is possible to request a email address from the open id provider.
I think you can even request data as required (openid.ax.required) attribute and email is even part of the simple registration schema. (http://www.axschema.org/types/#sreg).

(In reply to comment #23)
> why you like to disable email? 

  Because I want people to be able to log in without having to *validate* their email address. We can still get it from OpenID but it has to be validated.
Assignee: nobody → user-accounts
I can't see the rationale behind creating a "special" users for OpenID. They are the same users, but without notification email set. What we change is only authentication method. Users without emails just can't login with email and can't receive notifications, but there is no problem to add notification email (after confirmation, of course) or make this email primary (turn on password-based authentication). The user account stays the same - no need for differentiation between "full" and "OpenID" accounts. What is really needed is to find places where authorization email is used as user account identifier, estimate the impact and replace it with something more generic. "Something" could be links (URIs, XRIs or whatever) like "mailto:..." or "openid:..." to give additional information about full user name in the comment.

I do not know anything about Bugzilla architecture and hence can't say if it is technically feasible.
Blocks: gsoc
Whiteboard: [roadmap 4.0]
The current URL, http://www.danga.com/openid/ forwards to http://openid.net/.  The field should be updated.
This is most necessary. I believe this should be bumped from 'enhancement' to 'bug' status. This is perhaps the most important impediment preventing users from reporting bugs more frequently. When I find a bug in a piece of software I usually don't file it because of the hassle I have to go through to create yet another bugzilla account, except if I care _really_ deeply about it or am in particularly generous mood. In fact, I've created three accounts today (counting this one) and I'm fed up. I've done a quick survey of my password wallet and it seems I have at least twelve different bugzilla accounts, and I'm rather sure I have more that neither I nor the wallet remembers. This maybe a personal account and anecdotal evidence, but I firmly believe that I'm not the only one that feels this way.
(In reply to comment #27)
Nobody writes Perl these days. That's most unfortunate.
  This is basically what we should be doing, and it requires far fewer changes in Bugzilla than other OpenID solutions (because it always uses email addresses):

  http://googlecode.blogspot.com/2009/11/hybrid-onboarding.html
Alias: bz-openid
Depends on: 593522
  I've filed bug 593522 to address supporting Hybrid Onboarding, which is something that I think we'd do before supporting generic OpenID. (Since hybrid onboarding works with email addresses, meaning we wouldn't have to do change anything about Bugzilla's architecture to support it.)
Completely agree w/Rafal.  If there's one thing I'm fed up with it's being forced to create and register a new account at every web site I want to participate in.  

Reducing the friction involved in the bug reporting process is going to make it a lot easier for end users to get involved.
[DO NOT ADD "ME TOO! COMMENTS THAT CREATE BUGMAIL.
To show your support, see "vote" above.]
Hi

This patch adds an OpenID user verification provider, and if enabled, changes the big login screen to allow you to enter an OpenID URL instead of username/password. Internally there is no big changes, the database stays exactly the same as before. The OpenID URL is queried for the user's email using both the AX and SREG extensions, we require at least 1 to succeed. The email is then supplied as the bz_username, and happy days.

So far I've tested it with my GMail account and it works :-). Please test with other OpenID providers.

Still need to change the small login bar, add a dependency on LWPx::ParanoidAgent, test with a new email address, consider a way to limit which OpenID providers are allowed, etc.
Attachment #573422 - Flags: review+
Comment on attachment 573422 [details] [diff] [review]
OpenID hybrid onboarding patch

you probably meant to request a review, not grant it :)
Attachment #573422 - Flags: review+ → review?
6 and a half years and 48 votes after this P1 enhancement was opened, and 8 days after the second independent attempt at a patch by me was attached, this seems to be going nowhere slowly?

Please review.
(In reply to Damjan Jovanovic from comment #35)
Pinging is totally fine (and sometimes needed), but comments in a demanding style are not very helpful. While contributions are very welcome please keep in mind that maintainers are volunteers and might be off for holidays or just busy in real life. Also see the "No obligations" section under https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - Thanks!
most of damjan's patch looks really good; however there's been some debate about if openid support for bugzilla is better suited as an extension rather than into the core.

there is now a bugzilla extension for browserid, which provides a similar goal to openid, this could be used as a basis for an openid extension (http://bzr.mozilla.org/bugzilla/extensions/browserid/).

by making it an extension, the development cycle will be decoupled from bugzilla's, allowing for quicker deployment for sites which want this feature.

things haven't been decided yet, please bear with us as we talk this out.
update: yes, an extension seems to be the best way forward with open-id support in bugzilla.  the trail is currently being blazed by the browserid extension, and once that's done we should be in a good position to figure out how best to tackle an openid extension.
I've been working on an extension for OpenID support; I've made the current code available on Github[1]. This is my first attempt at building extension and a bit of templating for it has been borrowed from the Browser ID extension. Development of it was provoked by management at the organization I work with, but has slowed down due to real-life work. I'm very open to suggestions and updates; so feel free to suggest.


1: https://github.com/jalcine/bugzilla-openid.
(In reply to Jacky Alcine from comment #39)
> I've been working on an extension for OpenID support

excellent jacky; i'm extremely happy that you've got your code to a point where you're able to make it public!


as per comment 38, we won't be supporting openid directly within the bugzilla core, however we'll continue to provide support to jacky and his openid extension.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Quick question, by having this bug marked as WONTFIX, does it mean Jacky's extension cannot be hosted at some point here? http://bzr.mozilla.org/bugzilla/extensions/
Andrés: It is WONTFIXed for the software "Bugzilla". This does not refer to the Bugzilla installation "bugzilla.mozilla.org" which has its own product in this bugtracker.
Andre: I'm not talking about BMO, I'm talking about storing Jacky's extension in Bugzilla's VCS along with the other extensions, for easier discovery.
Target Milestone: Bugzilla 4.4 → ---
(In reply to Andre Klapper from comment #42)
> Andrés: It is WONTFIXed for the software "Bugzilla". This does not refer to
> the Bugzilla installation "bugzilla.mozilla.org" which has its own product
> in this bugtracker.

bugzilla.mozilla.org would not be a good choice in product as we will not be installing and supporting the OpenID extension on BMO at any point. 

That being said, I would love to see this hosted at bzr/bugzilla/extensions and I can help set up a repo for the code there if you do not have permission to do so.

dkl
Comment on attachment 188469 [details] [diff] [review]
Patch to existing BZ files needed to add OpenID support (v0.1.1)

-    SendSQL("SELECT realname FROM profiles WHERE userid = $userid");
-    $vars->{'realname'} = FetchSQLData();
+    SendSQL("SELECT realname, extern_id FROM profiles WHERE userid = $userid");
+    ($vars->{'realname'}, $vars->{'openid_uri'}) = FetchSQLData();

This portion adds a new option to the user to have a OpenID url to correspond with their account, no? (Do excuse my naiveness).
Attachment #573422 - Flags: review?
(In reply to Jacky Alcine from comment #45)
> Comment on attachment 188469 [details] [diff] [review]
> Patch to existing BZ files needed to add OpenID support (v0.1.1)
> 
> -    SendSQL("SELECT realname FROM profiles WHERE userid = $userid");
> -    $vars->{'realname'} = FetchSQLData();
> +    SendSQL("SELECT realname, extern_id FROM profiles WHERE userid =
> $userid");
> +    ($vars->{'realname'}, $vars->{'openid_uri'}) = FetchSQLData();
> 
> This portion adds a new option to the user to have a OpenID url to
> correspond with their account, no? (Do excuse my naiveness).

after installing this extension called bugzilla-openid and enabling it by the following instructions and steps, some errors came out when logging in with openid authentication on my own bugzilla site, which are "Can't locate object method "email" via package "Net::OpenID::VerifiedIdentity" at /loader/0x9d6ab78/Bugzilla/Extension/OpenID/Auth/Login.pm line 73."

And ideas on it?

a. Instructions for getting bz-openid installed along with bugzilla site
$ git clone git://github.com/jalcine/bugzilla-openid.git
$ sudo -u www-data cp -rf bugzilla-openid/* /home/www-data/bugs.example.org/extentions/OpenID

b. Steps for enabling bz-openid on bugzilla site
Login with "admin account" ==> "Administration" ==> "Parameters" ==> "User Authentication" ==> "user_info_class with "OpenID,CGI" ==> "Save Changes"

Login with "admin account" ==> "Administration" ==> "Parameters" ==> "OpenID" ==> "openid_enabled with "on" and "openid_can_register" with "on" ==> "Save Changes"
This is not the right place to talk about issues with this patch. This patch has not been accepted to be implemented in the core code of Bugzilla and the bug has been rejected as wontfix, so there is no point in discussing about it here.
You need to log in before you can comment on or make changes to this bug.