Thanks for your quick replies On Nov 30, 11:55 pm, Ivo van Dongen <[EMAIL PROTECTED]> wrote: > Atm I don't really see your use case. Could you explain as what you are trying > to accomplish?
Basically, I'm considering using webical to publish information to specific people (like communicating release schedules for various products to our customers). This way, instead of mailing back and forth various versions of the schedule, the latest version is accessible to everyone in convenient formats. Allowing (some) users to modify the calendar online is a nice extra, and using java/wicket imho is an advantage over projects like phpicalendar. > > - who cannot subscribe themselves to calendars > > Why would you want to restrict users to subscribe to calendars? Because the available calendars are not really public, and we don't have authorization (yet) on the lower layers. I guess this is a nice-to-have - in our case I think managing authorization externally might be overkill, but as we trust our users some degree of 'authorization by obscurity' might be acceptable. > > - who can read, but not write (some) calendars > > As the calendars are hosted externally and are not controlled by webical > you can restrict access at the webdav layer if you want. In our case the calendars are not hosted externally - the point is to (partially) expose our internal calendars :). Configuring the authorization at the webdav layer might be an option, i'd have to take a look at that. If the logged-in user does not have write access to the selected calendar, is that detected by webical? Of course UI for calendar manipulation (pluses, 'add event...' etc) should disappear. > I think that if you want to implement a strict access control in webical > you would need a bit of an overhaul of the current design. The reasoning > now is that all resources are controlled and regulated externally. This > has the advantage that webical can be extermely pluggable, but the > disadvantage that access control has to be implemented somewhere else. > One way to do this is to couple webical and your webdav server to a > central ldap server for authentication for example (this was our own > business case). While that's an elegant architecture that should certainly remain supported, using an LDAP server seems rather heavyweight (no pun intended) for our use case. I'll try and take a look what options are available for doing the access control at the webdav layer. Arnout --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "webical-developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/webical-developers?hl=en -~----------~----~----~----~------~----~------~--~---
