Thanks for the notes, Cyrus. I'll ignore the name lookups for now
(until we get an Open Directory to LDAP connector, and then get
Linux's slapd to connect to CalendarServer somehow...)
On the other bugs, some observations:
2. Every login (i.e. open up iCal) generates the following in
caldavd, as
do any edits to events:
'No principal found for UID: david'
"Attempt to create clone
'/var/cache/CalendarServer/principals/__uids__/david' of resource
<DirectoryPrincipalUIDProvisioningResource:
/var/cache/CalendarServer/principals/__uids__>"
OK, so a while back we changed the way principal-URIs are defined so
that now principal-URIs are found in /principals/__uids__/. The
items in there are identified by their directory guid values. For
open directory those are "real" GUID values.
So, add <guid> elements in accounts.xml that have the same value as
the <uid> elements (making sure you do not duplicate values anywhere
across all types - users, groups, locations and resources).
Adding the <guid> tag seemed to help a bit - logins and edits do not
generate that dialog any longer, but adding/editing any event with a
resource or location still gives me a 403 error and a dialog.
Specifically:
access.log : "POST /calendars/users/david/outbox/ HTTP/1.1" 403 135
"-" "DAVKit/2.0 (10.5; wrbt) iCal 3.0"
./run -v : [CalDAV outbox POST] Originator:
mailto:[EMAIL PROTECTED] does not match authorized user: /
principals/__uids__/david/
at the same time as this dialog pops up:
Request Error
Access to "New Event from ical on david" in "calendar" in account
"Home Calendars" is not permitted.
The server responded:
"HTTP/1.1 403 Forbidden"
to operation CalDAVScheduleEventQueueableOperation.
I also noted your reply to James Hill's comments about mailto: and
fixed my own accounts.xml accordingly, so it's not necessarily a URI
issue.
Thanks again,
David Szego.
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-users
