Kozea / Radicale

A simple CalDAV (calendar) and CardDAV (contact) server.
https://radicale.org
GNU General Public License v3.0
3.3k stars 429 forks source link

using PUT to add a single event overwrites the calendar #833

Open pmaziere opened 6 years ago

pmaziere commented 6 years ago

Hi,

I use radicale 1.1.1 in debian stretch, and I may not have understand how to add or update a calendar, so that's two reasons to ask for forgiveness in advance for my question.

I need to use curl in order to add an event in a calendar, and I do it this way:

curl -u user:password -X PUT -H 'Content-Type: text/calendar; charset=utf-8;'  https://localhost:5232/user/calendar/ --data-binary @single_event.ics

But radicale overwrites the current calendar and replaces it with this single event only. I would rather like to add this event to the existing calendar.

What am I doing wrong here ?

Thanks

m4tze commented 6 years ago

Same here for version 2.1.8! I first thought that pseudorandom number generator just outputs the same number but all existing files are deleted when uploading files.

m4tze commented 6 years ago

This seems to be caused by the following lines from __init__.py as create_collection deletes a collection under certain circumstances.

807     def do_PUT(self, environ, base_prefix, path, user):
[...]
895                     storage.check_and_sanitize_props(props)    
896                     new_item = self.Collection.create_collection(    
897                         path, items, props)
m4tze commented 6 years ago

Just in case anyone is looking for this, here is a possible solution from ##kozea:

15:16 < liZe> instead of using https://localhost:5232/user/calendar/, you probably want to use https://localhost:5232/user/calendar/random-uuid.ics instead

This works.

pbiering commented 2 days ago

Can confirm this happens still with 3.2.3, will investigate

pbiering commented 2 days ago

according to the code this looks like intended in case only directory is provided in PATH the collection is rewritten by the provided data.

One can think of preventing this by an already existing option which prohibits the explicit deletion of a collection:

# Collection protection against deletion
permit_delete_collection = True

Has anyone tried this with other CalDAV servers and is the result here the same?

pbiering commented 2 days ago

one can try this extension for a quick test, but potentially a new option should be introduced like

permit_write_collection = True

--- app/put.py.orig 2024-05-03 06:02:18.000000000 +0200
+++ app/put.py  2024-09-28 07:53:48.612798792 +0200
@@ -172,6 +177,8 @@
             if write_whole_collection:
                 if ("w" if tag else "W") not in access.permissions:
                     return httputils.NOT_ALLOWED
+                if not self._permit_delete_collection:
+                    return httputils.NOT_ALLOWED
             elif "w" not in access.parent_permissions:
                 return httputils.NOT_ALLOWED