Re: Misbehavior cyrus caldav and evolution. Calendar is readonly.

2015-01-28 Thread Ken Murchison

Hi Stephan,

Thanks for your work on this.  I am actually at a calendaring conference 
at the moment, but I will look at this later in the week and do some 
Evolution testing myself.




On 01/28/2015 12:21 PM, Stephan wrote:

Hi,

I am aiming to run cyrus with caldav and carddav support. On the 
client side I am using evolution.


First step was compiling cyrus-imapd-2.4.14-caldav-beta10. After some 
configuration issues I managed to connect to my test calendar via 
browser/url and evolution. But I failed in doing some calendar entry 
because evolution tells me calendar is readonly.


I like your approach, so I tried to figure out whats going on. After 
verification of access rights with cryadm/lam I started with some 
wireshark-analysis. Which clarified for me that evolution obtains 
calendar access rights by doing an OPTION request.


This page showed me how it should look like :
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2014-June/037418.html

I recognized that PUT (ALLOW_WRITE in cyrus code) is missing in my 
optionslist. While reviewing the code I found that


http_caldav.c/caldav_parse_path(...)

helps to determine values returned by the OPTION request. Path is 
splitted into

* collection
* resource

Where resource pointer is responsible for setting the ALLOW_WRITE 
option :


caldav_parse_path(...)
...
  done:
/* Set proper Allow bits and flags based on path components */
if (tgt->collection) {
...
if (tgt->resource) {
if (!tgt->flags) tgt->allow |= ALLOW_WRITE;
tgt->allow |= ALLOW_DELETE;
tgt->allow &= ~ALLOW_WRITECOL;
}
...

When evolutions wants to determine calendar access rights it requests 
an collection but no resource. Because it wants to know about 
calendars access at all not some specific resource. But collection 
case doesn't set the ALLOW_WRITE flag. I guess that makes evolution 
mark calendar as readonly and prevents users from writing it.


I worked arround quickly by :

caldav_parse_path(...)
...
tgt->collection = p;
tgt->collen = len;

p += len;
if (!*p || !*++p) {
/* Make sure collection is terminated with '/' */
if (p[-1] != '/') *p++ = '/';
if (!tgt->flags) tgt->allow |= ALLOW_WRITE;
...
}

But evaluation of this is difficult to me. I am new to imap and your 
source. So I don't know if I missconfigured the build or misinterpret 
something. What do you say ?


Thank you in advance.

Stephan





--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University



Misbehavior cyrus caldav and evolution. Calendar is readonly.

2015-01-28 Thread Stephan

Hi,

I am aiming to run cyrus with caldav and carddav support. On the client 
side I am using evolution.


First step was compiling cyrus-imapd-2.4.14-caldav-beta10. After some 
configuration issues I managed to connect to my test calendar via 
browser/url and evolution. But I failed in doing some calendar entry 
because evolution tells me calendar is readonly.


I like your approach, so I tried to figure out whats going on. After 
verification of access rights with cryadm/lam I started with some 
wireshark-analysis. Which clarified for me that evolution obtains 
calendar access rights by doing an OPTION request.


This page showed me how it should look like :
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2014-June/037418.html

I recognized that PUT (ALLOW_WRITE in cyrus code) is missing in my 
optionslist. While reviewing the code I found that


http_caldav.c/caldav_parse_path(...)

helps to determine values returned by the OPTION request. Path is 
splitted into

* collection
* resource

Where resource pointer is responsible for setting the ALLOW_WRITE option :

caldav_parse_path(...)
...
  done:
/* Set proper Allow bits and flags based on path components */
if (tgt->collection) {
...
if (tgt->resource) {
if (!tgt->flags) tgt->allow |= ALLOW_WRITE;
tgt->allow |= ALLOW_DELETE;
tgt->allow &= ~ALLOW_WRITECOL;
}
...

When evolutions wants to determine calendar access rights it requests an 
collection but no resource. Because it wants to know about calendars 
access at all not some specific resource. But collection case doesn't 
set the ALLOW_WRITE flag. I guess that makes evolution mark calendar as 
readonly and prevents users from writing it.


I worked arround quickly by :

caldav_parse_path(...)
...
tgt->collection = p;
tgt->collen = len;

p += len;
if (!*p || !*++p) {
/* Make sure collection is terminated with '/' */
if (p[-1] != '/') *p++ = '/';
if (!tgt->flags) tgt->allow |= ALLOW_WRITE;
...
}

But evaluation of this is difficult to me. I am new to imap and your 
source. So I don't know if I missconfigured the build or misinterpret 
something. What do you say ?


Thank you in advance.

Stephan