Mailing List Archive

Creator Permissions for Shared Resources
Hi everybody,

with the information in the wiki I was able to set up a working DAViVal
server, but now I have difficulties with the permissions for a shared
resource.

I'd like to implement the following permissions for a calendar:
a) public read access
b) authenticated users (or users of a specified group) should be able to
create new events
c) only (and this is where I'm stuck) the creator of an event should be
able to write and delete their own events.

Is this possible within the DAViCal permission system?


Regards,

Volker

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general
Re: Creator Permissions for Shared Resources [ In reply to ]
On Tue, 2011-08-30 at 14:44 +0200, Volker Schmidts wrote:
> Hi everybody,
>
> with the information in the wiki I was able to set up a working DAViVal
> server, but now I have difficulties with the permissions for a shared
> resource.
>
> I'd like to implement the following permissions for a calendar:
> a) public read access
> b) authenticated users (or users of a specified group) should be able to
> create new events
> c) only (and this is where I'm stuck) the creator of an event should be
> able to write and delete their own events.
>
> Is this possible within the DAViCal permission system?

There's a little bit of logic to handle that last case, but I expect it
is little-used and needs some better regression testing around it to be
confident that it works as intended.

The rest is relatively normal, though for fully public access it is
mandatory to use the /public.php/... URL rather than /caldav.php/... -
this is intended to reinforce security by providing a true read-only
path for public access, separate to the normal path for logged-in
access.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
This fortune is false.
------------------------------------------------------------------------