New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CalDAV: support public sharing #22735

Closed
georgehrke opened this Issue Feb 29, 2016 · 18 comments

Comments

Projects
None yet
10 participants
@georgehrke
Copy link
Contributor

georgehrke commented Feb 29, 2016

The dav app should support publishing calendars as described in https://trac.calendarserver.org/browser/CalendarServer/trunk/doc/Extensions/caldav-sharing.txt

cc @DeepDiver1975

First we need to implement caldav sharing as below - after that being done we need to see where publishing is being hooked in

Steps to take to make this happen

  1. Add Sabre\CalDAV\SharingPlugin to v1 and v2 dav routes

  2. OCA\DAV\CalDav\Calendar has to implement interface IShareableCalendar (beware of meothod conflicts)

  3. Add interface SharingSupport to apps/dav/lib/CalDav/CalDasvBackend.php (beware there might be conflicts with existing method used by our own sharing) - mainly the

  4. Add sharing tests of the caldavtester project

    Update:

    looks like we need to reimplement Sabre\CalDAV\SharingPlugin - support for publish-url is missing

@gour

This comment has been minimized.

Copy link

gour commented Apr 17, 2016

👍

@crti

This comment has been minimized.

Copy link

crti commented Apr 17, 2016

can't wait to use this 👍

@DeastinY

This comment has been minimized.

Copy link

DeastinY commented Apr 19, 2016

Nice !

@thomasgraf

This comment has been minimized.

Copy link

thomasgraf commented Apr 22, 2016

is longingly expected 👍

@MasterFox

This comment has been minimized.

Copy link

MasterFox commented Apr 22, 2016

please integrate it soon - thx 👍

@owncloud owncloud locked and limited conversation to collaborators Apr 22, 2016

@georgehrke

This comment has been minimized.

Copy link
Contributor Author

georgehrke commented Jun 8, 2016

moving to 9.2

@georgehrke georgehrke modified the milestones: 9.2-next, 9.1-current Jun 8, 2016

@owncloud owncloud unlocked this conversation Jun 28, 2016

@tcitworld

This comment has been minimized.

Copy link
Member

tcitworld commented Jun 28, 2016

How would you see the publish-url format ? The files app uses a token name but maybe it isn't necessary here.

@georgehrke

This comment has been minimized.

Copy link
Contributor Author

georgehrke commented Jun 28, 2016

I'd go with a token as well.

@DeepDiver1975

This comment has been minimized.

Copy link
Member

DeepDiver1975 commented Jun 28, 2016

How would you see the publish-url format ? The files app uses a token name but maybe it isn't necessary here.

good question - I'd vote for using a token as part of the url.
We have to see how to generate and store the token because there is also a pre-publish-url which should hold the url even before the publishing was done.

@georgehrke

This comment has been minimized.

Copy link
Contributor Author

georgehrke commented Jun 28, 2016

Maybe some hash over calendar id and some dedicated (new) secret from config.php?

@DeepDiver1975

This comment has been minimized.

Copy link
Member

DeepDiver1975 commented Jun 28, 2016

Maybe some hash over calendar id and some dedicated (new) secret from config.php?

question is if we need only obscurity or real secret tokens

@lpirl

This comment has been minimized.

Copy link

lpirl commented Jun 28, 2016

Not quite sure if this issue has an effect on the following possibly desired feature:
It would be nice to be able to (re)generate the sharing URL upon request (as in: revoke access regarding the old URL, grant access by handing out the newly generated URL).

@DeepDiver1975

This comment has been minimized.

Copy link
Member

DeepDiver1975 commented Jun 28, 2016

Generating the token based on a hash should be fine - we will anyhow only expose calendars which are published.

We can expose public calendars in a dav resource of it's own like:

https://example.com/remote.php/dav/public-calendars/1234567890

the collection public-calendars will only allow enumeration in debug mode.

@tcitworld

This comment has been minimized.

Copy link
Member

tcitworld commented Jun 28, 2016

So it should be something like this ?

Table public-calendars

id token calendarid uri
uniqId a token the calendar shared url for pre-publish

Token should be something like md5($calendarId . SECRET_SALT);

@DeepDiver1975

This comment has been minimized.

Copy link
Member

DeepDiver1975 commented Jun 28, 2016

Before we talk about publishing we need to implement the sharing mechanisms and in a second step we add the publishing.

Both sharing and publishing information should go into the existing oc_dav_share table - we might need to add some columns - let's see

@tcitworld

This comment has been minimized.

Copy link
Member

tcitworld commented Jun 28, 2016

Does this mean that support for notifications/invites has to be brought ? I don't see much sharing mechanism to implements apart from the ones mentioned on top.

@DeepDiver1975

This comment has been minimized.

Copy link
Member

DeepDiver1975 commented Jun 28, 2016

Does this mean that support for notifications/invites has to be brought ?

Invites are optional as far as I can tell - regarding notifications I cannot really tell - this is something to find out while integrating this.

I suggest to develop this while testing with Apples iCal application - if at hand

@DeepDiver1975

This comment has been minimized.

Copy link
Member

DeepDiver1975 commented Sep 9, 2016

Case closed on the server side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment