810194 - iCalendar bug list is inaccessible to external tools when login is required

Status: RESOLVED DUPLICATE of bug 381088

(Bugzilla :: Query/Bug List, defect)

Description

[posita]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Steps to reproduce:

Our bugzilla installation requires logins for all users. We did the following:

1. log into bugzilla
2. perform a named/saved search
3. copy the "iCalendar" URL at the bottom of the page (i.e., <http://[dom]/issues/buglist.cgi?[...]&ctype=ics>)
4. log into Google calendar (i.e., <https://www.google.com/calendar/>)
5. go to "Other calendars" -> "Add by URL"
6. paste the URL copied from step #3 into the "URL:" field and click the "Add Calendar" button


Actual results:

You will be presented with a "Settings Error": "The address that you provided did not contain a calendar in a valid iCal or GData format."


Expected results:

Not sure on this one. I do not know for sure, but I *suspect* that if Bugzilla supported the RFC 1945 Basic Authentication Scheme (sometimes referred to as "HTTP Auth"; see <http://tools.ietf.org/html/rfc1945>), Google calendar, and other ICS consumers would be able to interact with Bugzilla. However, because Bugzilla's logins are proprietary (and HTML form based), tools trying to access the ICS links are presented with the HTML login page and they do not know how to proceed.

Comment 1

[posita]

Incidentally, the same problem applies to other machine-readable forms like the atom feed (i.e., <http://[dom]/issues/buglist.cgi?[...]&ctype=atom>). If Bugzilla requires logins, newsreaders have no visibility into the Atom-formatted lists because the login mechanism is proprietary.

Comment 2

[Frédéric Buclin]

(In reply to Matthew Bogosian from comment #0)
> Not sure on this one. I do not know for sure, but I *suspect* that if
> Bugzilla supported the RFC 1945 Basic Authentication Scheme (sometimes
> referred to as "HTTP Auth"; see <http://tools.ietf.org/html/rfc1945>),
> Google calendar, and other ICS consumers would be able to interact with
> Bugzilla.

Bugzilla does support HTTP Auth. Set the user_info_class parameter to Env and auth_env_email to REMOTE_USER.

Comment 3

[posita]

I'm sorry for not being clearer. Perhaps this is more of a documentation bug.

If <requirelogin> is <1>, then iCal and other formats are not really machine-accessible when using Bugzilla's own password database because of its proprietary bz_crypt mechanism. In other words, in order for REMOTE_USER to be populated, it has to be set before Bugzilla is invoked, in which case the web server, not Bugzilla, is doing the authentication. Even with something like mod_auth_mysql, the web server has no visibility into profiles.cryptpassword (unless it's provided via some API of which I am unaware).

If I were to follow the instructions in comment #2 verbatim, I would have locked myself out of Bugzilla (and have had to hand-edit my data/params file to get back in). In other words, don't go from this...

           'auth_env_email' => '',
           'requirelogin' => '1',
           'user_info_class' => 'CGI',

...to this...

           'auth_env_email' => 'REMOTE_USER',
           'requirelogin' => '1',
           'user_info_class' => 'Env',

...without also setting up HTTP Auth in your web server (e.g., via .htaccess in Apache) *AND* migrating your user/password database out of Bugzilla's profiles table. This may be beyond the scope of some installations and may frustrate users' abilities to change/recover their own passwords without additional infrastructure.

My apologies if this seems remedial, but other admins looking for a quick fix may be confused by prior comments.

There is something strange to me about providing iCal or RSS feeds for configurations where machines cannot have repeatable access to them. Those formats are generally for technologies that automate continuous updates without prompting from a user. Downloading a single iCal file seems to be of marginal value. Again, this may be more of a documentation issue than an implementation issue....

Comment 4

[Frédéric Buclin]

OK, so you are describing the same issue as in bug 381088. I suggested a workaround there a few years ago.

This bug has nothing to do with the way passwords are encrypted.

Comment 5

[posita]

My apologies for not finding the earlier bug, but that does seem to capture the same issue.

FYI, Google calendar chokes on the workaround. I have no idea why (wget works). The page displays the uninformative error:

Failed to add imported calendar at http://[dom]/issues/buglist.cgi?[...]&ctype=ics&Bugzilla_login=[user]&Bugzilla_password=[password] for [Google login]