6.0.0-beta1
▾
Tasks
New Task
Search
Photos
Wiki
▾
Tickets
New Ticket
Search
dev.horde.org
Toggle Alerts Log
Help
1/10/26
H
istory
A
ttachments
C
omment
W
atch
Download
Comment on [#4193] Allow publishing via iCalendar
*
Your Email Address
*
Spam protection
Enter the letters below:
.__ .__ .___. .. . [ __| \ | |\ / [_./|__/ | \__| \/
Comment
> This patch makes it possible for iCalendar clients (tested with Apple > iCal and KDE Kontact/KOrganizer) to publish their calendars to > Kronolith using the ics.php. The logic was taken largely from the > data.php import routine. > > > > Notes: > > 1) The calendar is published with an HTTP PUT. This requires server > administrators to allow PUT to the file ics.php before this will > work. Here is an example Apache httpd.conf stanza: > > <Files "ics.php"> > > <LimitExcept GET PUT> > > Order Allow,Deny > > Allow from all > > </LimitExcept> > > </Files> > > This block must either go in the .htaccess file in the kronolith > directory or inside a <Directory> block in the main httpd.conf > > > > 2) Apple's iCal assumes a that the calendar will be published to a > directory. To make this work with Kronolith, a little mod_rewrite > magic is necessary. > > The Kronolith directory must have Options +SymLinkIfOwnerMatch (this > is necessary for mod_rewrite): > > > > RewriteEngine On > > RewriteRule ^ics.php/(.*).ics$ ics.php?c=$1 [L,QSA] > > > > These two lines can go in either of the locations as above. > > When configuring the name of the calendar to publish in iCal set it > to the Kronolith calendar name. For regular user calendars this will > be their Horde login. For shared calendars it will be the long UUID > of the calendar. The name of the calendar from iCal's perspective is > what is passed to ical.php as the 'c' variable. > > > > Kontact/KOrganizer can use this same convention or can specify the > direct URL (such as ics.php?c=userid). Note also that Kontact > requires the Horde username and password to be embedded in the url > (http://user:pass@host/horde/kronolith/ics.php?c=userid). > > > > 3) Because HTTP PUT is used, the patch "tricks" Horde into thinking a > file was uploaded by the browser. Normal HTTP POSTs with > form-uploaded files get intercepted by PHP and stored into a > temporary location accessible later by the script. Instead this > patch does that work and populates the PHP global variables manually > as PHP would have done itself had it handled the file upload. There > may be a better way (I couldn't think of one at the time) but this > mechanism works very well. > > > > 4) iCalendar is NOT a synchronization protocol! Because of this each > time the calendar is updated the entire calendar is uploaded. If two > users are uploading calendar events a potential race condition exists > where the first user's updated events get deleted or replaced by the > second user. This should never occur if the calendar is only ever > updated by a single client at a time so I believe this is a useful > patch but the danger must be understood. If multiple clients are to > be used on the same calendar it's imperative that they take all > precautions to syncrhonize manually before publishing events. > > > > While there are potential pitfalls I think the patch still has value. > For many home or small-installation users the ability to publish a > calendar via readily accessible tools such as iCal or > Kontact/KOrganizer is an excellent way to keep track of calendar > events. For largers groups CalDAV, GroupDAV or CAP are much more > desirable (and complex) alternatives.
Attachment
Watch this ticket
N
ew Ticket
M
y Tickets
S
earch
Q
uery Builder
R
eports
Saved Queries
Open Bugs
Bugs waiting for Feedback
Open Bugs in Releases
Open Enhancements
Enhancements waiting for Feedback
Bugs with Patches
Enhancements with Patches
Release Showstoppers
Stalled Tickets
New Tickets
Horde 5 Showstoppers