[CalendarServer-users] Three questions about principals
Wilfredo Sánchez Vega
wsanchez at wsanchez.net
Thu Dec 14 20:48:20 PST 2006
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
More information about the calendarserver-users
mailing list