On 8/30/06, Ted Leung <[EMAIL PROTECTED]> wrote:
What happens to clients like iCal, etc if we password protect collections or if we require accounts in order to access calendar collections?
the way the server works now, a collection can be accessed by: * the owner of the collection, providing his username and password * everybody else, providing a ticket let's assume that when you share your calendar with chandler, the "magic" read-write url that is produced is <http://osaf.us/home/twl/calendar/?ticket=deadbeef>. let's further assume that when julie clicks that link, she gets a web page showing the calendar and/or providing urls for subscribing to the calendar with dav, webcal and atom. the question is - how do collection passwords fit into this workflow? for the "magic url", it's easy. instead of getting the calendar page, julie gets a page prompting her to enter the collection password. when she submits that, she gets the calendar page. but what about dav, webcal and atom access? do those protocols require the collection password too? because the collection password is not a standard authentication scheme (remember, we're authenticating with ticket+collection password, not basic or digest authen), there's no way for cosmo to tell ical to ask the user for the collection password like it can do for basic authen with a 401 response. so either the subscription urls that are provided on the calendar page have to include both the ticket and the collection password, or we don't use the collection password for protocol access. seems to me that including the collection password in the dav/webcal/atom url would defeat the purpose of the feature, but i dunno. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
