Skip to content
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

Private events in shared calendars are visible for the public #1225

Open
Binarus opened this issue Mar 2, 2022 · 3 comments
Open

Private events in shared calendars are visible for the public #1225

Binarus opened this issue Mar 2, 2022 · 3 comments
Labels
feature need:support support/help/contribution is required
Milestone

Comments

@Binarus
Copy link

Binarus commented Mar 2, 2022

At first, thanks for Radicale! I found it exceptionally easy to deploy on a Windows Server, and it works great in general. However, we're having the following problem:

We have multiple Thunderbird users and have created one calendar per user in Radicale. The objective is to let every user write and read his own calendar and let every user read the calendars of all other users. This works so far.

Problem

But when a user marks an event as "Private", other users still can see that event, including all details. This should not be the case.

For example, in Thunderbird, when creating an event, there is a "Privacy" dropdown button which can be used to mark the event to be "Public Event", "Show Time and Date only" or "Private Event". However, even when we choose "Private Event" there, the event with all details is visible for all other users.

I believe that this problem is due to Radicale, not to Thunderbird.

I have got that impression because I have seen similar issue reports for OwnCloud where it was explained that the problem was due to certain parts of CalDAV data not being evaluated correctly by the backend, or being ignored; OwnCloud was fixed to correct this a short time later.

There seems to be a "CLASS" field in CalDAV data, and I can imagine that Radicale ignores that field as well. Is there any way to get around it , or can it be fixed?

Please note that I don't have much experience with CalDAV yet, so my statement that the problem is due to Radicale may be wrong. In that case, I'd be grateful if somebody could shed some light on the matter.

Thank you very much in advance!

Steps to reproduce:

  • Install Radicale and configure it correctly, using the owner_write right type.
  • In Radicale, create two users (user A and user B)
  • In Radicale, create one calendar for user A and one calendar for user B
  • Connect user A's Thunderbird installation with user A's and user B's calendar, and connect user B's Thunderbird installation with user A's and user B's calendar
  • Let user A create an event, using Thunderbird, making sure that the event is assigned to user A's calendar created above (there is an appropriate dropdown field in Thunderbird's event creation dialog), and making sure that the event is marked as Private (using the Privacy dropdown field besides the lock symbol in the area below the menu bar in Thunderbird's event creation dialog)
  • Observe that user B can view that private event in user A's calendar, including all details, which actually is a problem.
@Binarus
Copy link
Author

Binarus commented Mar 28, 2022

Really nobody? Not even a "Won't Fix"?

@alqu
Copy link

alqu commented May 25, 2022

Hm, this sounds like a new feature.

What you are looking for is the property "CLASS".
In an event it could look like
CLASS:CONFIDENTIAL, CLASS:PRIVATE like the example from the spec below. Default is CLASS:PUBLIC.

The following is an example of the "VEVENT" calendar
component used to represent a meeting that will also be opaque to
searches for busy time:

    BEGIN:VEVENT
    UID:[email protected]
    DTSTAMP:19970901T130000Z
    DTSTART:19970903T163000Z
    DTEND:19970903T190000Z
    SUMMARY:Annual Employee Review
    CLASS:PRIVATE
    CATEGORIES:BUSINESS,HUMAN RESOURCES
    END:VEVENT

The documentation for that property is here: https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.1.3 .

I looked into the code and did not find a place where this property is respected in any way.

This would be a cool new feature!
Thanks for finding this behaviour.

@pbiering pbiering added this to the 4.x milestone Oct 29, 2024
@pbiering pbiering added the need:support support/help/contribution is required label Oct 29, 2024
@pbiering
Copy link
Collaborator

radicale so far has no mechanism included to honor information in ICS for the ACL layer - also not planned so far because this can turn somehow difficult without storing the user on server side into ICS in an extra attribute and honor this later on filtering on handout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature need:support support/help/contribution is required
Projects
None yet
Development

No branches or pull requests

3 participants