Misbehavior cyrus caldav and evolution. Calendar is readonly.

[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