I am a little confused as to how I publish calendars onto the server. I've got the server running and am trying to publish a .ics file from Chandler. It won't let me put the path as /calendars/users/admin or any of the users. the only way i can get read/write access is if i put the path as / I think i'm supposed to do something to configure the principals, but i'm not sure what.
Hi Brett, --On December 8, 2006 4:01:19 PM +0000 Brett Moreton <brett.moreton@student.manchester.ac.uk> wrote:
I am a little confused as to how I publish calendars onto the server. I've got the server running and am trying to publish a .ics file from Chandler. It won't let me put the path as /calendars/users/admin or any of the users.
the only way i can get read/write access is if i put the path as /
I think i'm supposed to do something to configure the principals, but i'm not sure what.
If you are using the trunk server, note that the principal and calendar paths have changed a little. Now the path to user calendars is '/calendars/user/xxx' - note that it is 'user' not 'users' (plural) as previously. Same goes for 'group' and 'resource' and the principal hierarchies. -- Cyrus Daboo
What is the purpose of group and resource principals having a password? Is there a way to configure the repository, so that anonymous access is allowed (to make some public calendars accessible to anyone) but without exposing the identities of all users and groups through the /calendars/ and /principals/ hierarchies? I think, I vaguely understand the purpose of resources in VEVENTs. But what is the purpose of resource *principals*? (Without knowing any better, I would probably model some resources as calendars with an appropriate ACL, e.g., if I would like to keep an eye on free/busy times of a room.)
Hi Frank, --On December 9, 2006 7:53:56 PM +0100 Frank Strauß <strauss@ibr.cs.tu-bs.de> wrote:
What is the purpose of group and resource principals having a password?
Whilst there may not be "humans" directly posing as a group or a resource, and "automated system" might. e.g,. a meeting room has a little hardware device with LCD screen on its door. This device is a calendar client that displays the current bookings for the room by accessing the CalDAV calendar for the resource. The device is programmed to login as the resource. (I've actually seen hardware devices like that, though they did not have CalDAV support).
Is there a way to configure the repository, so that anonymous access is allowed (to make some public calendars accessible to anyone) but without exposing the identities of all users and groups through the /calendars/ and /principals/ hierarchies?
You can edit repository.xml to include a "/calendars/public" hierarchy and add DAV:all, DAV:read inheritable privileges for that. Note that you could use WebDAV protocol to create the collection and set the ACLs via a client, but the "inheritable" option is a private extension we have and not exposed.
I think, I vaguely understand the purpose of resources in VEVENTs. But what is the purpose of resource *principals*? (Without knowing any better, I would probably model some resources as calendars with an appropriate ACL, e.g., if I would like to keep an eye on free/busy times of a room.)
A resource needs to have a principal associated with it if it is to partake in scheduling operations (i.e. you want to book a meeting room at the same time you send out an invite to attendees). Since CalDAV scheduling operations rely on principal properties (e.g., schedule-inbox-URL, calendar-user-address-set etc) there has to be a principal for every "schedulable" entity on the server. -- Cyrus Daboo
Cyrus Daboo wrote:
Hi Frank,
--On December 9, 2006 7:53:56 PM +0100 Frank Strauß <strauss@ibr.cs.tu-bs.de> wrote:
What is the purpose of group and resource principals having a password?
Whilst there may not be "humans" directly posing as a group or a resource, and "automated system" might. e.g,. a meeting room has a little hardware device with LCD screen on its door. This device is a calendar client that displays the current bookings for the room by accessing the CalDAV calendar for the resource. The device is programmed to login as the resource.
(I've actually seen hardware devices like that, though they did not have CalDAV support).
Ah, thanks for the inspiration: We actually have a panel PC at an iMac pool of our institute, which primarily controls a self-made door unlocking mechanism upon user authentication against our user directory. I could imaging to allow people to access a room calendar via this panel PC, also. Furthermore, I just read parts of RFC 3744. I think now I better understand why the term "principal" was introduced, instead of talking about users. Thanks! However, I still cannot imagine what kind of entity could act as a group principal. Can you help my imagination?
Is there a way to configure the repository, so that anonymous access is allowed (to make some public calendars accessible to anyone) but without exposing the identities of all users and groups through the /calendars/ and /principals/ hierarchies?
You can edit repository.xml to include a "/calendars/public" hierarchy and add DAV:all, DAV:read inheritable privileges for that. Note that you could use WebDAV protocol to create the collection and set the ACLs via a client, but the "inheritable" option is a private extension we have and not exposed.
Thanks. Ok. My question was related to the ACLs of the "magically" provisioned /principals/ and /calendars/ hierarchies (whithout making the whole store anonymously unaccessible).
I think, I vaguely understand the purpose of resources in VEVENTs. But what is the purpose of resource *principals*? (Without knowing any better, I would probably model some resources as calendars with an appropriate ACL, e.g., if I would like to keep an eye on free/busy times of a room.)
A resource needs to have a principal associated with it if it is to partake in scheduling operations (i.e. you want to book a meeting room at the same time you send out an invite to attendees). Since CalDAV scheduling operations rely on principal properties (e.g., schedule-inbox-URL, calendar-user-address-set etc) there has to be a principal for every "schedulable" entity on the server.
Thanks a lot for the explanation.
Hi Frank, --On December 9, 2006 9:32:29 PM +0100 Frank Strauß <strauss@ibr.cs.tu-bs.de> wrote:
However, I still cannot imagine what kind of entity could act as a group principal. Can you help my imagination?
As an example: consider a project management system that creates a 'group' for each project and automatically assigns members to the group. The project management system would use a group calendar to display the project timelines, tasks etc and could access and manage those as the group principal. Members of the group would be able to see the shared group calendar etc -- Cyrus Daboo
On Dec 9, 2006, at 11:09 AM, Cyrus Daboo wrote:
Whilst there may not be "humans" directly posing as a group or a resource, and "automated system" might. e.g,. a meeting room has a little hardware device with LCD screen on its door. This device is a calendar client that displays the current bookings for the room by accessing the CalDAV calendar for the resource. The device is programmed to login as the resource.
(I've actually seen hardware devices like that, though they did not have CalDAV support).
I was talking to David about this recently... In our implementation, there isn't actually any way to authenticate (via HTTP) as a non-user principal. You will be able to authorize as such using the über-user (we need to call that something other than proxy, which already means something else) and X-Authorize-As. Changing this would require that you enter something more complicated than your user name into an HTTP auth dialog, for example. I think this is fine, though, once we add the planned proxy (that other meaning) groups, since you can add a user principal to the write proxy group for a non-user principal and then do the things you need to do.
Is there a way to configure the repository, so that anonymous access is allowed (to make some public calendars accessible to anyone) but without exposing the identities of all users and groups through the / calendars/ and /principals/ hierarchies?
You can edit repository.xml to include a "/calendars/public" hierarchy and add DAV:all, DAV:read inheritable privileges for that. Note that you could use WebDAV protocol to create the collection and set the ACLs via a client, but the "inheritable" option is a private extension we have and not exposed.
We've kill off repository.xml, so that's no longer an option. Frank filed a ticket on that: http://trac.macosforge.org/projects/calendarserver/ticket/103 Anonymous users should be able to edit the calendars also? If not, who gets to? Absent any agents which let you set ACLs over the wire, we probably want some useable defaults here. -wsv
[This message is a replacement to my MKCOL and "public" questions...] I am a little confused about the question what types of resources may reside where in the hierarchy of a WebDAV/CalDAV server and as a consequence what methods are allowed at which places. Currently my impression is that the CalendarServer poses some additional constraints on the hierarchy in addition to the few rules given by the CalDAV I-D: There is the /principals/ collection, which should probably remain completely untouched by the user. Right? There is the /calendars/ collection, which is auto-provisioned with users, groups and resources. Each of these principals' homes again has an auto-provisioned hierarchy (I'd like to keep all the sched stuff aside for now, it would confuse me too much at this point :-)). Not only the names of these DAV resources are auto-provisioned, but also their properties and access control configuration. Question: Can these things be changed, i.e., access control, displayname, etc.? It seems unpossible to create calendar collections outside of /calendars/<type>/<name>/. I think this is a unpleasant restriction. Imaging a small instituion where not only users have their own private calendars, but also a few shared calendars, e.g.: * calendars with anonymous read access to announce events to any interested people even those that don't belong to the institution and have no account, * calendars managed by only one person to make some type of personal schedule visble to his fellows, i.e. readable for a group principal, * calendars managed by a group of staff members and visible to the same group (or also other groups) in order have a shared overview. E.g., at our institute we have a weekly seminar with 1 to 3 student talks each week. The supervisors can fill in their students' talks as long as slots are free, without the need for real scheduling operations. I think in many cases the number of such calendars is limited and can be put in a single directory, so that they can easily be found by all users. I'm not sure whether such calendars should be put in /calendars/ or into sibling directories, I'd prefer /calendars/ so that /calendars can be used as a URL-prefix for really all calendars. If the number of calendars increases, people might wish to setup their own little hierarchy of shared collections, e.g. "public", "staff", "students". But in any case it would be a pain to browse through large numbers of /calendars/<type>/<name>/ directories to find calanders people would like to subscribe. So, as Cyrus explained on 2006-12-12:
repository.py/xml has been removed in favor of a more "static" repository layout. This is now provisioned in the tap.py file. We would like to see an admin tool that is able to create additional resources with ACLs et,c as repository used to do, as a replacement for that.
This makes perfect sense to me. :-)
participants (4)
-
Brett Moreton
-
Cyrus Daboo
-
Frank Strauß
-
Wilfredo Sánchez Vega