Setup for Apple Users

From Davical
Revision as of 16:28, 7 July 2014 by Gorka (talk | contribs) (Described database problems with iOS 7 queries)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Template:TOCrightThe applications used on Apple devices can be made to configure simply if you set your server configuration up to cater to them:

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 [1] that clientside the path should omit the trailing '/home' or '/home/'.

Notable Issues

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 psql):

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>); 

Replace <'/user/collection'> with a valid collection name already existing in your database.

Replace <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"/>' 

Replace <YYY> with a valid integer value from "user_no" column in the "usr" table

Example:

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.

References

<references/>