Apache/Web iCal Server

http and iCal are common standards that should be used together to create a calendar server. So far, I have not seen anyone do this effectively. Furthermore, most people seem to be concentrating on Windows calendar solutions or 'Windows to other platform' solutions. We have some ideas for a platform independent calendar server.

The server side is completely web technology. The files are pulled from the server through http(s). The files are pushed back to the server using https. Each calendar user would have two data stores--public and private. For now, the user would need to maintain two separate calendars to differentiate public/private data--This issue will be dealt with in the 2nd release--what release? We dont have any files yet. ;)

The client side is any program that supports iCal and https. The mozilla calendar project, korganizer(in kde), Evolution, Apple's iCal support ics files on remote servers.   The mozilla calendar runs on multiple platforms (including windows) and is the ideal client. 

Security Issues

One of the caveats of placing ical files on a public server so that others can read them is that it may include private data.  Even though some ical programs will not display the private data belonging to others it is still easily readable for those who know to look at the file directly.  This private data needs to be removed for public consumption.  I have written some test scripts which strip out private data from ical files.  This is similar to the freebusy feature of some calendar programs with the exception that the resulting public file is a real ics file that can be treated just like other ics files.  Most calendar programs can display multiple files at the same time so that multiple people's calendars could easily be seen at once with this method.

To facilitate both public and private access to the files the web server would be configured to hand out the public version in non encrypted sessions and the private version when the users accesses the same location with ssl.

There are two levels of security in this spec: private, and public.  It would be nice to allow for groups as well but that requires more overhead and should be dealt with later.

Technical details

Setup Apache:

• - Valid user accounts maintained in an htpasswd file located in /etc/http/auth/calendar.passwd.
• - Data maintained in "user" accounts located under /var/www/calendars/
• - Public Data accessed via http://calendarserver/user/calendar.ics
• if user does not want public calendar exported. file is created ...user/nopublic. When script sets nopublic also needs to check for public calendar and delete.
• - Private Data accessed via https://calendarserver/user/calendar.ics
•   modperl handler will write to private/user/calenar.ics.
• - Private access realized through HTTPS and .htaccess limiting PUT/etc.
• - public access to calendar file would parse private calendar, strip private date, copy file to http://.....public/user/calendar.ics
• use caching to speed up process
  

How to setup the same location being served from both HTTP and HTTPS?
  Ultimately a modperl program will handle this because apache authorization is not fine grained enough to keep people from overwriting each other's calendars when they have access to them.

- .htaccess file in private directory

	<LIMIT PUT POST etc.>
	  require-user user
	</LIMIT>
      

	<LIMIT GET etc.>
	  require-user user other-user
	</LIMIT>
      

Write some helper scripts:
- addCalUser

1. set ownership of user files to apache
2. initialize files and .htaccess file for access to:
/var/www/calendar/$user/public_html/public/calendar.ics
/var/www/calendar/$user/public_html/private/calendar.ics
3. add user:password to /etc/httpd/auth/calendar.passwd