Setup for Apple Users
The applications used on Apple devices can be made to configure simply if you set your server configuration up to cater to them:
- Running an SSL server on port 8443 (CalDAV and CardDAV), or a plain HTTP server on port 8008 (for CalDAV) and 8800 (for CardDAV).<ref>Well known TCP and UDP ports used by Apple software products</ref>
- Running from the root of the server
- Using mod_rewrite to translate request URLs
If you install DAViCal in a subdirectory, or run it on a port other than 8443 (SSL) or 8008 and 8800 (unencrypted) then clients using the Apple devices will need to go into the advanced settings and configure the full URL, as detailed in the installation instructions for iCal and iPhone (the iPod instructions are the same as for the iPhone).
The use of mod_rewrite for URL Rewriting is explained in the Apache Config section.
If that's all set up...
When your server is properly configured with all of the above, it should be possible for users to configure iCal or iPhone by entering only:
- The server hostname
- The username
- The password
and the client should auto-discover all the rest.
It has been reported  that clientside the path should omit the trailing '/home' or '/home/'.
Unable to login when using HTTP
It has been reported that the Apple apps won't talk to DAViCal over HTTP, only over HTTPS. The assumption is that it won't use basic auth to login over an encrypted link (which HTTP is).
If you encounter this problem, please try using SSL.
Different database layout expected for iOS 7 queries
Should be resolved in 1.1.2
Symptoms: Users aren't able to connect to any of their existing collections. Instead iOS will create new collections that it names after a 128bit hex number scheme that then shows up in the administration interface.
Cause: iOS 7 REQUIRES separate collections for VEVENT a VTODO components (otherwise it completely ignores the existing collections).
Solution: You need to manually set the
supported-component-set for existing collections to VEVENT (and move the remaining data to new VTODO collection).
For existing collections insert the following SQL statement (e.g. with
INSERT INTO property (dav_name, property_name, property_value, changed_by) VALUES (<'/user/collection/'>, 'urn:ietf:params:xml:ns:caldav:supported-calendar-component-set', <XXX>, <USERID>);
<'/user/collection'> with a valid collection name already existing in your database.
<XXX> with the calendar component type (e.g., VEVENT,VTODO, etc.) that your resources can contain:
- for "event" only collections use:
'<comp name="VEVENT" xmlns="urn:ietf:params:xml:ns:caldav"/>'
- for "todo" only collections use:
'<comp name="VTODO" xmlns="urn:ietf:params:xml:ns:caldav"/>'
- for "todo" and "event" collections (all data in one collection) use:
'<comp name="VEVENT" xmlns="urn:ietf:params:xml:ns:caldav"/><comp name="VTODO" xmlns="urn:ietf:params:xml:ns:caldav"/>'
<YYY> with a valid integer value from "user_no" column in the "usr" table
INSERT INTO property (dav_name, property_name, property_value, changed_by) VALUES ('/bob/calendar/', 'urn:ietf:params:xml:ns:caldav:supported-calendar-component-set', '<comp name="VEVENT" xmlns="urn:ietf:params:xml:ns:caldav"/>', 42);
You could also use:
$c->default_calendar_components = array( 'VEVENT', 'VTODO', 'VJOURNAL', 'VTIMEZONE', 'VFREEBUSY', 'VAVAILABILITY' );
... it sets the default supported components for all collections without
urn:ietf:params:xml:ns:caldav:supported-calendar-component-set property, but it is not the best idea for environment with iOS clients because iOS always creates separate calendars for events and todos.
iCal handles principal grants, not collection grants
So you need to restrict access at the collection level after granting broader access at the principal level, and users may still see delegated calendars that they cannot actually read and/or write to.
Lookback on iPhone
If you get a blank calendar on an iPhone the standard fix seems to be to set the look back for 'Only last two weeks of events' (you still see all future events, of course). I have no idea why this might be the case, but changing that setting has so frequently fixed the problem that it has to be mentioned... Should be resolved in 0.9.9.5.