[CalendarServer-users] Principal URL vs. Alternate URIs
vs. Calendar User addresses
cdaboo at apple.com
Wed Nov 7 06:39:18 PST 2007
--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.
More information about the calendarserver-users