Package: cyrus-caldav
Version: 2.4.17+caldav~beta10-13~dfd2
Severity: normal
Tags: patch
Due to strict interpretation/implementation of HTTP Auth RFC having private
calendars
from multiple accounts accessed by the same instance of a client (e.g. Icedove)
fails
with "403 Forbidden" for any accounts accessed after the first.
This issue is why Mozilla added the about:config option
calendars.network.multirealm
option (which apparently is also apparently iCal's default behavior).
In short it is required to have HTTP Auth occur for different URI's not just
different
server names because calendars are not differentied by server name but instead
by
URI.
This attached patch is a hack that that re-requests HTTP Auth if the current
http userid
does not match the userid in the calender URI and HTTP header does not have a an
Authorization field.
Description: Fix CalDAV/CardDAV for multiple user's calendars from same client
Workaround for accessing different users' collections on the same server
with same hostname. Without this fix, this fails because HTTP auth is
only done once. This is the same issue that had Mozilla Lightning add
the calendar.network.multream option.
Basically interpretation of RFC's such that HTTP Auth is only done once
hostname:port reqardless of the URI causes CalDAV/CardDAV to fail when
one does not have a unique hostname:port per user and access to multiple
users' calendars is done from the same client, unless one opens up the
ACLS so that the calendars are all accessible from a single user (in
addition to the owner of the calendar)
This workaround forces an authentication request if the userid does not
match the user portion of the calendar/addressbook URI. It does require
that the client know enough to not use the same authorization for the
different calenders (e.g. Mozilla Lightning with multirealm enabled
or, apparently, iCal)
Index: cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
===================================================================
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.new.orig/imap/httpd.c
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
@@ -919,6 +919,9 @@ static void cmdloop(void)
const struct namespace_t *namespace;
const struct method_t *meth_t;
struct request_line_t *req_line = &txn.req_line;
+ char collection_userid[MAX_MAILBOX_BUFFER];
+ char *user_loc;
+ int has_authorization = 0;
/* Reset txn state */
txn.meth = METH_UNKNOWN;
@@ -1200,6 +1203,7 @@ static void cmdloop(void)
/* Perform authentication, if necessary */
if ((hdr = spool_getheader(txn.req_hdrs, "Authorization"))) {
+ has_authorization = 1;
if (httpd_userid) {
/* Reauth - reinitialize */
syslog(LOG_DEBUG, "reauth - reinit");
@@ -1244,6 +1248,33 @@ static void cmdloop(void)
}
}
+ /* Workaround for accessing different users' collections on the same
server
+ with same hostname. Without this fix, this fails because HTTP auth
is
+ only done once. This is the same issue that had Mozilla Lightning
add
+ the calendar.network.multream option.
+ Basically interpretation of RFC's such that HTTP Auth is only done
once
+ hostname:port reqardless of the URI causes CalDAV/CardDAV to fail
when
+ one does not have a unique hostname:port per user and access to
multiple
+ users' calendars is done from the same client, unless one opens up
the
+ ACLS so that the calendars are all accessible from a single user (in
+ addition to the owner of the calendar)
+ This workaround forces an authentication request if the userid does
not
+ match the user portion of the calendar/addressbook URI. It does
require
+ that the client know enough to not use the same authorization for
the
+ different calenders (e.g. Mozilla Lightning with multirealm enabled
+ or, apparently, iCal)
+ */
+ if (!has_authorization && httpd_userid) {
+ user_loc = strstr(txn.req_uri->path, "/user/");
+ if (user_loc != NULL) {
+ user_loc += 6;
+ strlcpy(collection_userid, user_loc, strcspn(user_loc, "/"));
+ if (strcmp(collection_userid, httpd_userid)) {
+ *httpd_userid = 0;
+ }
+ }
+ }
+
/* Request authentication, if necessary */
switch (txn.meth) {
case METH_GET:
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/5 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cyrus-caldav depends on:
ii cyrus-common 2.4.17+caldav~beta10-13~dfd2
ii dpkg 1.17.22
ii libc6 2.19-13
ii libcomerr2 1.42.12-1
ii libdb5.3 5.3.28-7~deb8u1
ii libical1 1.0-1.1
ii libkrb5-3 1.12.1+dfsg-16
ii libsasl2-2 2.1.26.dfsg1-12
ii libsqlite3-0 3.8.7.1-1
ii libssl1.0.0 1.0.1j-1
ii libwrap0 7.6.q-25
ii libxml2 2.9.1+dfsg1-4
ii zlib1g 1:1.2.8.dfsg-2+b1
cyrus-caldav recommends no packages.
cyrus-caldav suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
