Proposal: add authentification to calendar subscriptions #1346
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed that the calendar subscriptions do not allow services like baikal / davis that have calendars set to private.
For these calendars, even setting
?exportdoes not allow the user to access the calendars unless they are made public. While this can be used for calendars with non-sensitive data, this is not really an option for calendars containing sensitive data.By default, these calendars are accessible using a set auth method.
In this PR, I added a basic auth to the calendar subscription, as this is the method used in our instance. It has been tested with a davis setup and works fine with private calendars.
This PR contains an issue where the calendar subscription area closes when clicking in areas. I have not figured out the reason for that.