CalDav Proxy

935 views
Skip to first unread message

Dam

unread,
Sep 17, 2012, 6:38:37 AM9/17/12
to sabredav...@googlegroups.com
Hello everyone!

I try to subscribe to a calendar but it takes authentication.
So I looked rights, and I found the proxy. Therefore I put the calendar read-only.

So I did like this:

Principals:

id    uri                                                        username   e-mail                    displayname   vcardurl
 
22   principals/yeste64                                 yeste64      em...@email.com   yeste64          NULL
23   principals/yeste64/calendar-proxy-read   NULL          NULL                     NULL              NULL
24   principals/yeste64/calendar-proxy-write   NULL         NULL                      NULL             NULL
25   principals/mik                                       mik            em...@email.com    mik                NULL
26   principals/mik/calendar-proxy-read          NULL         NULL                      NULL             NULL
27   principals/mik/calendar-proxy-write         NULL          NULL                      NULL             NULL


Groupmembers:

id   principal_id   MEMBER_ID

2   23                25


Calendars:

id   principaluri             displayname   uri   CTAG   description   calendarorder   calendarcolor   timezone   components
 
7   principals/yeste64   NULL             1     2          NULL           0                     NULL              NULL        VEVENT, VTODO


But when I try to access http://localhost:8888/sabreDav/server.php/calendars/yeste64/ connected as "mik" I get this error:

<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
   <s:exception> Sabre_DAV_Exception_NotFound </ s: exception>
   <s:message>
       Could not find node at path: principals/yeste64/calendar-proxy-read
   </ s: message>
   <s:sabredav-version> 1.6.4 </ s: sabredav-version>
</ d: error>

When I'm connected as "yeste64" all works well.

Thank you for you help

Evert Pot

unread,
Sep 17, 2012, 6:44:41 AM9/17/12
to sabredav...@googlegroups.com
Hi Dam,

Are you using:

Sabre_DAVACL_PrincipalCollection

or:

Sabre_CalDAV_Principal_Collection

The second is specific for caldav, and has correct support for the proxy principals.

Evert
> --
> You received this message because you are subscribed to the Google Groups "SabreDAV Discussion" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/sabredav-discuss/-/RkbeiBuR3FYJ.
> To post to this group, send email to sabredav...@googlegroups.com.
> To unsubscribe from this group, send email to sabredav-discu...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sabredav-discuss?hl=en.

Dam

unread,
Sep 17, 2012, 7:00:37 AM9/17/12
to sabredav...@googlegroups.com
Thank you for the speed and efficiency of your answer!

In fact I used "Sabre_DAVACL_PrincipalCollection." I now use "Sabre_CalDAV_Principal_Collection" and everything works perfectly.

Thank you very much once again Evert! :)

Evert Pot

unread,
Nov 17, 2012, 11:25:30 AM11/17/12
to sabredav...@googlegroups.com
Hi Pierre,

On Nov 17, 2012, at 1:27 PM, Pierrot <goog...@zapilou.com> wrote:

> Hello,
>
> I am trying to implement the same kind of setup on a Baïkal server (based on SabreDAV, http://baikal.codr.fr/ ). I prepared all the mySQL magic, but I am now wondering how I should proceed to have a user connect to calendar from iCal (OSX 10.8):
> I tried (literally) dozens of urls, the closest I came to succes was:
>
> - use the "subscribe to calendar" menu
> - url: https://user2:pw...@domain.tld/cal.php/calendars/user1/token-id-of-calendar (user2 being a groupmember for user1/calendar-proxy-read)
>
> This one is giving me a -1 error in OSX, something about a unforeseen error ... all other urls I tried gave me more understandable errors, like "unknown calendar", etc ..

Once caldav-proxy is setup correctly, you don't need to configure a secondary account. You can reach the proxy account through the window menu, or by going into your account settings and clicking the 'delegation' tab.

If neither of those things work (the delegation list is empty), then something is not setup correctly.

Evert

Pierrot

unread,
Nov 17, 2012, 12:15:37 PM11/17/12
to sabredav...@googlegroups.com
Hello,
Wow, that was fast. I am happy to report that my setup was indeed correct, because I was able to see that delegation right away and all calendars were added !

I went in there yesterday, but that was before setting up the proxy, so in my mind, that method had already been tested and had already failed :-(

But (there is always a "but"), I tried to reproduce from within OSX 10.8 Reminders ... just to discover that there are no account info with a delegation tab in reminders .... is there a way to reproduce a similar setup in reminders ?

Anyway, many thanks for your answer !

Pierre. 


Evert

Evert Pot

unread,
Nov 17, 2012, 2:12:04 PM11/17/12
to sabredav...@googlegroups.com
Unfortunately that feature was removed in 10.8. So there's no way to do the same thing there..

Evert

Pierrot

unread,
Nov 17, 2012, 4:32:42 PM11/17/12
to sabredav...@googlegroups.com
Hello,


Le samedi 17 novembre 2012 20:12:09 UTC+1, Evert Pot a écrit :

Unfortunately that feature was removed in 10.8. So there's no way to do the same thing there..

Sometimes Apple is really going backwards ... so I downloaded BusyCal which is doing really well in that area, playing nice with Baïkal and SabreDav, seeing delegation for both events and todos for a reasonable price (until 12/31). I'll test for a while ... 
Thanks a lot for your help !!
Pierre.

 

Evert

Evert Pot

unread,
Nov 18, 2012, 1:48:08 PM11/18/12
to sabredav...@googlegroups.com
Reminders does have support for a 'Sharing' feature though, which is arguably much better/cooler than delegation.

Evert

Pierrot

unread,
Nov 18, 2012, 6:14:34 PM11/18/12
to sabredav...@googlegroups.com
Hi
Ok, interesting info. But iirc, Baïkal has first to upgrade its SabreDAV version and to implement sharing which is not done yet. I was considering installing SabreDAV without Baïkal but after doing some reading, I feel like I am missing some step by step guidance to proceed. Baïkal is a no-brainer install and it's working right out of the box. I also considered DaviCAL but SabreDAV seemed more interesting.
In any case, if you have a link to a very detailed how-to for setting up a caldav/cardav server, I might give a try an then ... maybe go back to Reminders although Busycal has, in my opinion, a better cal+rem interface in a single software.
Thanks again for your work and answers.
Pierre.
 

Evert

Evert Pot

unread,
Nov 19, 2012, 7:55:12 AM11/19/12
to sabredav...@googlegroups.com
Definitely don't have a very detailed link. SabreDAV is primarily intended as a development library, and baikal fills a bit of the 'user experience' void, that I'm not interested in solving yet.

The issue with sharing is that, although the hooks are there in SabreDAV, it doesn't come with an implementation yet. \I didn't see a good way to do this, without breaking some design principals. In the future I hope to solve this by adding a dependency injection container.

If you want to see sharing in action though, we have support for it here: https://fruux.com/

Evert

pheraph

unread,
Dec 6, 2013, 7:22:57 AM12/6/13
to sabredav...@googlegroups.com
Hi,

I am writing here as I don't know if this is an issue with SabreDAV or Baïkal. I followed the wiki and added some proxy entries to test the calendar delegation and it works with my setup (Baïkal + OSX 10.9/iOS 7). The problem is: it works a little bit too well. My account gets read-/write-access to calendars the given user shouldn't get. As I can trigger this behavior it should be fairly easy to fix (either witin Baïkal or SabreDAV).

These are the delegation I see on Mac OS (for my user with the ID=1):

And these are the (hopefully relevant parts) of the database:

users
id username    
1  raphael
7  nochmal
8  wiedermal


principals
id uri

7 principals/raphandrea/calendar-proxy-write
13
principals/nochmal/calendar-proxy-write
16 principals/wiedermal/calendar-proxy-write

groupmembers
id principal_id member_id
3  13           7
4  16           1
5  7            1

Although user raphael (1) is granted access only to "nochmal" and "wiedermal", it gets access to "raphandrea", too. Now when I remove the row with id=5
from "groupmembers":

groupmembers
id principal_id member_id
3  13           7
4  16           1

The delegation looks correct:


The same happens when I change the table the following way:

groupmembers
id principal_id member_id
3  13           7
4  16           1
5  8            1

So I think at some point the principal_id and the user_id are mixed up. Can some reproduce that behavior with either Baïkal or SabreDAV?

All the best,
Raphael

Evert Pot

unread,
Dec 8, 2013, 5:42:40 PM12/8/13
to sabredav...@googlegroups.com
Hi!

Please start a new thread for a new problem :)



On Friday, December 6, 2013 7:22:57 AM UTC-5, pheraph wrote:
Hi,

I am writing here as I don't know if this is an issue with SabreDAV or Baïkal. I followed the wiki and added some proxy entries to test the calendar delegation and it works with my setup (Baïkal + OSX 10.9/iOS 7). The problem is: it works a little bit too well. My account gets read-/write-access to calendars the given user shouldn't get. As I can trigger this behavior it should be fairly easy to fix (either witin Baïkal or SabreDAV).

These are the delegation I see on Mac OS (for my user with the ID=1):


[snip]

Thanks for the detailed information, but in this case I think the problem is straightfoward. In the groupmembers table, both the principal_id and member_id refer to principals. They _never_ refer to users.

The users.id field is never used in the entire codebase (as far as I'm aware).

principal_id should refer to the parent (in the case of calendar-proxy, this is always a 'proxy principal'), member_id should refer to the id of the principal of the user.

Your principals table should for every user have 3 principals:

1. The base principal: principals/username
2. The write principal: principals/username/calendar-proxy-write
3. The read principal: principals/username/calendar-proxy-read

Hope this helps,

Evert

pheraph

unread,
Dec 9, 2013, 5:45:12 AM12/9/13
to sabredav...@googlegroups.com

Thanks for the detailed information, but in this case I think the problem is straightfoward. In the groupmembers table, both the principal_id and member_id refer to principals. They _never_ refer to users.

Thanks Evert for your answer! As you have pointed out I have to use the principal id for the member_id-field. D'oh. Now it works as described.
Reply all
Reply to author
Forward
0 new messages