Calendar: Public user modifying a calendar which is shared through a public link

[n0whereRuoxi]

Hi! I wonder if there is a way for public user to modify a calendar which is shared through a public link?
But it seems that the authentication token stands in our way.
How can we whitelist the public access?
I am thinking about passing the OC.requesttoken to the public user in a secure way.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[georgehrke]

Hey,

I read about your project to extend the calendar app on IRC. Really cool! :)
How many credit points do you get and what's the dead line?

Ideally we would allow multiple public shares to achieve feature parity with the files app.
This would also make implementing https://github.com/nextcloud/server/issues/1440 easier for us.
(cc @schiessle)

[n0whereRuoxi]

@georgehrke The DDL is this friday. So we are running out of time.
We just figured out a workaround: we store the event changes that a public user want to make in a DB table, then when the NC user logs in, a script check the DB table and excute those changes through CalDev.

[jsc144]

Credit wise, this project will essentially determine if we pass the class or not. The deadline for turning in functionality is this friday. However we would still be working on the project and performing user acceptance tests until Mid-May.

To further touch on what n0whereRuoxi was saying, here is a a document detailing the work flow with the back end tasks and the DB schema for the 1-1 meeting scheduling we are tasked with implementing.

https://docs.google.com/document/d/10UnAedl2pkmcOZDFBOJxqRUgy9qFLOmQIEZ5lGs3yv4/edit?usp=sharing

[georgehrke]

@georgehrke The DDL is this friday. So we are running out of time.
We just figured out a workaround: we store the event changes that a public user want to make in a DB table, then when the NC user logs in, a script check the DB table and excute those changes through CalDev.

Hm :/

I'm afraid this sounds like a real hack and i don't think we will take it into upstream.
I'd love to guide you to a proper solution, but it's not really feasible to implement till Friday.

[jsc144]

Id prefer to think of it as an extension. We took great care in not reducing the functionality of nextcloud calendar and obscuring data that users may view as private. Perhaps after friday we could work together on developing an extension frame work for nextcloud calendar?

[n0whereRuoxi]

@georgehrke how much work do you think there is to implement that in your way? Just wondering

[georgehrke]

At least 2 - 3 weeks, probably more depending on your knowledge of the source code, how much time you are able to work on it each day, etc.

[erinmgriffith]

I am new to Nextcloud, but I have a client that wants an interactive booking calendar on his site that reads and writes to a nextcloud calendar. I have played around using cURL to read from the calendar but have been unable to figure out a way to write. I also haven't seen much documentation on the subject- even though it seems like it would be a fairly common one.

Is this approximately the kind of functionality you are working on? If not is there a direction you could point me in or some common knowledge that I am not privy to? Any advice would be great or help I could give.

[n0whereRuoxi]

@erinmgriffith Do you mean #39 #805 ?

[erinmgriffith]

805 yes- but I don't need the autopopulation for the sender part. Any ideas for a relatively light quick, even hacky if necessary, solution that I could build up more later?

[n0whereRuoxi]

@erinmgriffith The way we achive writing was elaborated in #805, if you wanna move there to discuss. The problem of our solution is that the process is not strictly through a CalDev request, which is a more standard way. So, yes, we have a hacky way.

[jsc144]

@erinmgriffith You can disable auto population in our implementation by selecting an identical source and destination layer. Do you plan on keeping your work open source?

[erinmgriffith]

Sure I would keep open source if anything good came from it. I am not that experienced working with
Nextcloud or CALDav (this is my first experience with it at all)- so I don't know how much I could possibly have to contribute.

[erinmgriffith]

Do you have the DB table stored on Nextcloud or somewhere else? And how are you managing to write through the CALDav?

[jsc144]

Well I bring up the open source part because I assume your client will want the meeting scheduling functionality to continue to work with new updates to nextcloud server and nextcloud calendar (even if s/he doesnt know it yet). So does our professor.

Our solution should be fairly easy to maintain as the functionalities are fairly modular and simple. We are in the process of making a few UI changes that we want done before making a pull request. We are not sure if the pull request will be approved yet, but we do have a vested interest in contributing to the nextcloud calendar community and maintaining the functionality of the calendar app along with what we've implemented.

[jsc144]

And yes, we do use a separate DB table. What are the features that your client wants?

[erinmgriffith]

Just a basic booking calendar. Where i will create a calendar interface on his site that reads from the nextlcloud calendar and writes updates to the calendar when a user scheduling an appointment. The more obvious solution of just linking the calendar via iframe is out because he has had big problems displaying on chrome browsers- which makes up a large share of the visitors.

[jsc144]

So you want to essentially create a way for any public user to write to the calendar if they have a certain link. The problem with this is that the authentication for such an http request is performed using a nextcloud authentication token that a user gets when logging in. You could make a public anonymous user that you just auto login everytime a user goes to a link. But this would also give that user access to your nextcloud server and other calendars that are shared. We chose to avoid that route, because messing with built-in security protocols is a good recipe for headache.

Here's how we implemented it, the sender creates a calendar with their available timeslots, clicks meeting scheduling, selects a destination calendar, and shares the link created with the recipient. The recipient then selects a timeslot, enters a name or email in the description and the event autopopulates into the destination calendar with the recipients name or email in the events description.

The advantage here is that the public non NC users (well all users really) dont have access to any other calendar layers than the ones they have the links for. To remove a link's access, you simply unshare the calendar.

[erinmgriffith]

So the sender- meaning my client- creates a Nextcloud calendar and sends the link to a user via what method? How does the autopopulation occur?

[jsc144]

You could either use an iframe or email a link. Autopopulation occurs when the sender loads/refreshes the calendar app.

[erinmgriffith]

Thanks for your input.

[jsc144]

You should make sure your functionality adheres to caldav or else your pull request wont be approved. I hold that ours does, even if its in a hot-fix way because the protocol is ensured through our database methods.

[erinmgriffith]

What link are you using to load in the iframe or email if not the CALDav link provided in the calendar website? Where do you get it?

[erinmgriffith]

Nevermind, realized what you were talking about- but still cannot figure how you are performing a write operation to the calendar at all. The shared links I have seen do not seem to allow any editing of any of the event fields.

[jsc144]

We check the data were storing in the database and submit a request with the senders authentication token. Do you plan on providing support for the way we have implemented meeting scheduling?

[erinmgriffith]

Support in what sense? If you mean continual support and maintenance, for my client then yes, if necessary.
So basically you are not actually writing to the calendar itself, but referencing it to check against your database that has essentially a copy of the calendar data? Am I right?

[jsc144]

Cool, We keep a copy of an event id so the sender can define specific free time zones, but youre essentially right

[jsc144]

IMO it makes more sense to think of the otoConfirmations as flags that trigger the autoupdate process rather than full on copies of the event. The otoConfirmations store the eventID which we search for in the source layer. If this event exists, we "move" it to the appropriate calendar and alter its description.

[erinmgriffith]

Thank you so much for all of your help. I really appreciate. I think we will be moving onto using an app more suited to this purpose, like Calendly, due to time constraints, but I hope that I can look into this further later. Good luck on this and I hope it gets approved.

[georgehrke]

Duplicate of https://github.com/nextcloud/calendar/issues/632