[CalendarServer-users] Principal URL vs. Alternate URIs vs. Calendar User addresses

Frank Strauß strauss at ibr.cs.tu-bs.de
Wed Nov 7 07:05:03 PST 2007

Hi Cyrus,

Cyrus Daboo wrote:
> Hi Frank,
> --On November 7, 2007 3:24:19 PM +0100 Frank Strauß
> <strauss at ibr.cs.tu-bs.de> wrote:
>> When I use URIs like the "Principal URL" for ACL configuration, it seems
>> to work as expected. However, it would be nice, if more verbose
>> addresses like "/principals/users/brandt/" would also work.
>> I think a mapping from any of the alternate addresses to the UUID could
>> and should be done before it gets applied to an ACL. What do you think?
> The principal-URL is the identifier used for ACL operations as per the
> WebDAV ACL spec. Our principal-URLs are guaranteed to be unique as they
> are GUIDs for each principal. Thus, of a login id (short name, uid) is
> re-used for a different user (as can happen over time as users come and
> go) the new user will have a different principal-URL and thus won't be
> able to access any of the data for the old user that may still be around.
> So on our system, principals are all listed under /principals. Within
> that we have users, groups, resources and locations which contain
> resources named for the uid/short name of each principal of the
> corresponding type - those are not guaranteed to be unique over time.
> Then we also have __uids__ in /principals. That contains a list of all
> the unique principal resources.
> It is certainly painful to have to type in the __uids__ variant by hand
> - but really your tool should/could do the mapping from the more
> friendly "short name" principal path to the principal-URL for you. i.e.
> you type in /principals/users/cdaboo, and your tool maps that to the
> principal-URL property on that resource. Same thing when viewing ACLs,
> the tool can map the principal-URL path to anyone of the alternate-URIs
> - or perhaps even better to the displayname property.

Thanks for your quick response. I understand and support the concept of
keeping such a "mapping comfort" from the core CalDAV server
functionality and leave it to the client side. I was just a little
confused by the fact that the server accepts principal URIs other than
/principals/__uids__/* in ACL configuration operations.



More information about the calendarserver-users mailing list