librelist archives

Re: [radicale] Courier and shared calendars?

From:

Guillaume Ayoub

Date:

2012-02-20 @ 11:57

Le lundi 20 février 2012 à 10:57 +0000, Duncan Hill a écrit :
> Hello! 

Hello!

> Just found this project, and after doing a few gyrations to get python
> 2.6 installed on my crufty CentOS server, I've got it up and running
> complete with Courier auth support. 

Nice!

> Something that has me head-scratching is how to do a shared calendar
> between one or more authenticated users (perhaps it's not possible)
> when using Courier as the auth. 

That's not possible now, with Courier or any other authentication
method :/.

> With public_users and private_users untouched, the username 'private'
> will access the default shared calendar. Users who authenticate via
> Courier will get their personal, owner-authed calendars. If I add
> these users to private_users, then I think (I haven't fully tested)
> that the namespace is going to collide due to the path used by
> Radicale to determine if a calendar is shared or personal. 

You're right again: the names can collide if one of your users has the
same name as the values of public_users or private_users. That's really
bad, but that's the cost of simplicity :).

> Is there a solution in Radicale for this right now? It's easy enough
> to create a dedicated user account that several people can share, so I
> have a workaround. I'd love to be able to say something like: 
> shared_calendars = { 'shared1': ['user1', 'user2'], 'shared2':
> ['user3', 'user4']} 
> and have Radicale handle the authentication aspect automatically. 

That would definitely be cool. The solution seems to be easy, but it's a
bit more complicated.

Some features (user groups, read-only access, storage rights…) look easy
to add, but are in fact really hard to handle "the good way". For
example, managing user groups with your syntax is OK for Courier
authentication, but it's really strange for PAM: groups are managed in
PAM, why would I manage other groups in Radicale?

The central problem is the management of rights. The iCal format and the
CalDAV protocol have a complex right management described in the
normalization papers, but it's really (too?) hard to include in
Radicale. Being small and simple is *the* main goal of Radicale, and
managing rights would need more code that the code that is already in
Radicale.

Handling authentication and simple rights in Radicale was maybe an
error: it leads to the problems you wrote about, and it always has
serious limitations when you don't handle it "the good way". The good
way, now, if you want a real right management, is to put Radicale behind
a real HTTP server, and let your HTTP server manage the rights. That's
more complex to configure, just because that's a more complex problem to
solve.

After all, your workaround (creating an false user and sharing the
password between different users) may not be that bad :).

If you need help to find a solution to your specific problem, feel free
to ask anything, I promise that I'll be less pessimistic that in this
answer!

Regards,
-- 
Guillaume

Le 20/02/2012 12:57, Guillaume Ayoub a écrit :
> The central problem is the management of rights

You mean Digital Rights Management? ;)

(Sorry.)