Best practices to programatically manage principals/permissions on a Sabre CardDAV server ?

[Joe Terry]

Would appreciate any pointers and advice on the best practices to programatically manage principals/permissions on a Sabre CardDAV server ?

We want to be able to add principals, change their credentials, delete them, and I suppose manipulate address books and jcard blobs within. Would appreciate a discussion of that as well.

All while never touching the command line ... all from a distant client ...

Then perhaps we can talk about the good, bad and ugly of authentication for this SUPER client.

Thanks !

[Evert Pot]

Hi Joe,

On Monday, February 2, 2015 at 12:38:25 PM UTC-5, Joe Terry wrote:

Would appreciate any pointers and advice on the best practices to programatically manage principals/permissions on a Sabre CardDAV server
 

We want to be able to add principals, change their credentials, delete them, and I suppose manipulate address books and jcard blobs within. Would appreciate a discussion of that as well.

All while never touching the command line ... all from a distant client ...

Then perhaps we can talk about the good, bad and ugly of authentication for this SUPER client.

The default backends do not allow any sort of management of either principals or privileges.

The assumption is that in most cases people already have a system for principals/users
and simply need a way to reflect this in their caldav/carddav server.

Privileges (in the context of DAV) is widely regarded as 'too complex' / 'too flexible'. The
the result is that most implementations (not just sabredav) simple use the privileges system
to communicate privileges to the user, but don't use it to alter them.

Also, RFC3744 does not offer a standard way to create new principals.

It's eventually my goal to allow new principals to be created for 'principal backends' that
allow it, by coming up with a custom API for this.

So in the meantime I don't have a solid answer for you, at fruux we invented our own
API's to do most of this stuff.

If it helps, I can give you pointers on how someone would go about programmatically
create new principals, or how you would create an API to do this. I could also tell you
where to look when you want to override privileges.

So, let me know how I can help =)

Evert

[Joe Terry]

Hi Evert,

Thanks for the prompt reply.

As you say, we have our own system for managing users and of course each person should only have access to their own contacts and calendars via username/password but we will manage those same contacts and calenders from our custom cardDAV ... Super-client.

How would we limit each user with access to their own contacts and calendars to read-only, if we wish, with the ability, perhaps to adjust read-write status on a collection by collection ... property by property basis.

You are very nice to offer and of course we would like pointers on how someone would go about programmatically
creating new principals, removing them, modifying them, or how you would create an API to do this.

And the mechanism for communicating with the server in this case ?

And yes, I would like your opinion on the best way to override privileges for such a Superclient. So that the Super-client has read-write access to all collections/properties in the system.

Otherwise we feel that SabreDAV is a solid base for our system and will serve our clients well.

Did SabreDAV client ever get more development ?

Are their other clients out there, regardless of implementation langauge, that you can recommend as good learning tools ... "Best practices" ... to follow that inter-operate with SabreDAV well ?

Thanks for everything you and Fruux are doing for the WebDAV, Card and Cal DAV community.

I'm in Redondo Beach, California USA !!

It's about 75 degrees Fahrenheit ... this week ... Cheers !

On Monday, February 2, 2015 at 9:38:25 AM UTC-8, Joe Terry wrote:

Would appreciate any pointers and advice on the best practices to pragmatically manage principals/permissions on a Sabre CardDAV server ?

[Evert Pot]

On Wednesday, February 4, 2015 at 1:02:41 PM UTC-5, Joe Terry wrote:

Hi Evert,

Thanks for the prompt reply.

As you say, we have our own system for managing users and of course each person should only have access to their own contacts and calendars via username/password but we will manage those same contacts and calenders from our custom cardDAV ... Super-client.

How would we limit each user with access to their own contacts and calendars to read-only, if we wish, with the ability, perhaps to adjust read-write status on a collection by collection ... property by property basis.

The standard way in sabredav 2.1 is to create your own CalDAV PDO backend and return a {http://sabredav.org/ns}read-only property for the calendars that should be read-only.
Unfortunately that same feature does not exist yet for CardDAV (it was added to CalDAV to enable 'calendar sharing' support).

For CardDAV your only option is to subclass Sabre\CardDAV\AddressBook and return different values for getACL() and getChildACL().
Subclassing Sabre\CardDAV\AddressBook means you also need to subclass Sabre\CardDAV\UserAddressBooks and Sabre\CardDAV\AddressBookRoot because each of the classes in this chain creates the other.

 

You are very nice to offer and of course we would like pointers on how someone would go about programmatically
creating new principals, removing them, modifying them, or how you would create an API to do this.

And the mechanism for communicating with the server in this case ?

You can basically add any sort of custom API using the plugins guide:

http://sabre.io/dav/writing-plugins/

You could for instance define a new POST method on the principals collection.
The format of the body is up to you. At fruux we use json for new API's.

 

And yes, I would like your opinion on the best way to override privileges for such a Superclient. So that the Super-client has read-write access to all collections/properties in the system.

To do this, simply give this client a different username and password, and make sure its listed in the Sabre\DAVACL\Plugin::$adminPrincipals array.

Adding a principal to that array causes it to have *all* privileges across the server.
 

Otherwise we feel that SabreDAV is a solid base for our system and will serve our clients well.

Did SabreDAV client ever get more development ?

Hopefully in the future again :) We're working on a lot of projects at the same time, and sometimes other projects get pulled forward in spite of others.
Our bottleneck is time ;)

I'm hoping to ship a more advanced principals system in 2.2, with better support for groups.
 

Are their other clients out there, regardless of implementation langauge, that you can recommend as good learning tools ... "Best practices" ... to follow that inter-operate with SabreDAV well ?

iCal, BusyCal and emClient are all great clients. The first two are on mac, the latter on windows.

We also wrote a guide for people who are developing new clients:

http://sabre.io/dav/building-a-caldav-client/
 

Thanks for everything you and Fruux are doing for the WebDAV, Card and Cal DAV community.

I'm in Redondo Beach, California USA !!

It's about 75 degrees Fahrenheit ... this week ... Cheers !

Lucky you! 271 Kelvin in Toronto

Evert

[Joe Terry]

271 Kelvin ... That's like a sauna on some planets !

What is the best way to add plugins and potentially make code changes and have those code changes preserved through updates and point releases ?

Joet

On Monday, February 2, 2015 at 9:38:25 AM UTC-8, Joe Terry wrote:

[Evert Pot]

On Wednesday, February 4, 2015 at 7:54:58 PM UTC-5, Joe Terry wrote:

271 Kelvin ... That's like a sauna on some planets !

What is the best way to add plugins and potentially make code changes and have those code changes preserved through updates and point releases ?

Use composer for autoloading (and stop using the zip distribution if you still are).
Follow the "writing plugins" doc here: http://sabre.io/dav/writing-plugins/

Point releases in sabredav never break backwards compatibility (2.1.2 -> 2.1.3) but we always break some backwards compatibility in large releases (2.1.3 -> 2.2.0), which we do about twice per year.

When we do, we publish highly detailed documentation about the things that have changed, this can be found here:

http://sabre.io/dav/upgrading/

We would recommend anyone to keep up, but an old version of sabredav will be maintained for 12 months after the initial release of the next version.
Currently 1.8, 2.0 and 2.1 are all supported versions. 1.8 will drop off in May.

Cheers,
Evert