Support webcal http auth & store credentials

[tcitworld]

Ideally :

• Have a checkbox "Provide credentials" beneath the url input field
• Show login and password beneath when it's checked
• Save credentials in the app. Secured enough ?
• Perform the proxy request and provide these credentials in the headers

What do you think ? @georgehrke @raghunayyar

[raimund-schluessler]

Regarding security/storing of credentials @LukasReschke should have look too I guess.

[georgehrke]

Well, you can already store credentials by putting them in the url with user:password@url, The problem is, that a user with whom the calendar is shared is will see the credentials. But as the webcal is fetched by the browser, you would not be able to share password protected webcal calendars (without sharing the auth as well)

[tcitworld]

I wonder if webcal calendars should be shared anyway, since you can just give the link to other people.

[georgehrke]

Sharing it is still way easier than telling someone to copy and paste that url into the new subscription field.

[tcitworld]

Well, you can already store credentials by putting them in the url with user:password@url

Right now ? Doesn't work for me, maybe because it seems http:// gets added on front.

[Tanarri]

I have also a problem, that I have to put ht eusername and password in the URL. ...and I have a non standard.port for my cloud.

This result in a URL für webdav: webdav://username:password/example.to:1234/cloud/remote.php/dav/calendar.ics

Outlook can't get the calendar. Error: "Der Internetkalender kann in Outlook nicht überprüft oder hinzugefügt werden. Setellen sie sicher, dass der Hyperlink ein gültiger Kalenderhyperlink ist.

Any suggestions? Or is this not supported (credentials + special port)

[georgehrke]

It's supposed to be user:pass@host:port/path

[treiher]

It doesn't work if I add https:// on front. Is only HTTP supported?

[fabwu]

I would like to subscribe to another Nextcloud calendar so I tried to subscribe with the following URL:

http://USERNAME:PASSWORD@HOST/remote.php/dav/calendars/USERNAME/CALENDARNAME?export

The first request works without any problems but any further requests are sent without a password. When I check the WebCal-Address it looks like this:

http://USERNAME@HOST/remote.php/dav/calendars/USERNAME/CALENDARNAME?export

Is there any security mechanisms which prevent that the password is remaining in the URL?

[tcitworld]

@wuethrich44 Not that I know of, but you should publish the calendar on the other end and then subscribe to it's public url.

[fabwu]

@tcitworld Ok that could be an approach but I don't have admin rights in the other server so I can't make the calendar public.

[tcitworld]

You don't need admin rights, just regular user access that you seem to have.

[treiher]

As stated in Issue #287 it should be possible to retrieve a WebCal calendar via HTTPS. For me it does not work, if I need authentication at the same time.

If I subscribe to https://USERNAME:PASSWORD@HOST/url/to/calendar the App changes the URL after creation to https://USERNAME@HOST/url/to/calendar, which obviously ends in a The remote server did not give us access to the calendar (HTTP {403} error).

Am I doing something wrong? How can I subscribe to a calendar with authentication and HTTPS?

[fabwu]

I've observed the same behavior. I use the following link to share the calendar:

[elgaard]

For me , the password is intact as source in the oc_calendarsubscriptions table. But not in the url used for the proxy.

[laeubi]

Maybe the calender can check for the 401 code and then ask the user for user/password?

Beside this it would be cool if subscribing has an option to sync the remote calendar into a local one so one is able to share this calendar with others by using a local one...

[georgehrke]

Maybe the calender can check for the 401 code and then ask the user for user/password?

Yes, that's what this ticket is about :)

Beside this it would be cool if subscribing has an option to sync the remote calendar into a local one so one is able to share this calendar with others by using a local one...

This would be an issue that belongs into the server repository. See: https://github.com/nextcloud/server/issues/1497 https://github.com/nextcloud/server/issues/1600

[pepea28]

For me , the password is intact as source in the oc_calendarsubscriptions table. But not in the url used for the proxy.

@elgaard It's because the method buildof the sabre\uri library contains :

$authority = $parts['user'] . '@' . $authority;

and should maybe be :

$authority = $parts['user'] . ':' . $parts['pass'] . '@' . $authority;

I'v tried and i was able to import my calendar.

[tcitworld]

@pepea28 Would you care to open a PR to the https://github.com/sabre-io/uri/ repository ?

[rugk]

So what is the state of this issue? (i.e. that the password is removed when it is requested by the proxy) I see none of your PRs are merged, @tcitworld…

Or is there at least any workaround one can try?

[rugk]

FYI the Nextcloud "news" app does have a similar UI as proposed in the OP (with a field for username/password).

[protree]

I also need this feature. Could the according PRs please be merged?

[ChristophWurst]

I also need this feature. Could the according PRs please be merged?

What PRs?

[tcitworld]

https://github.com/nextcloud/3rdparty/pull/143

[ChristophWurst]

It turns out that you can now actually use user:password with https links. I'm unable to reproduce the issue where sabre strips the password for https but not for http.

So the remaining part is storing the auth values separately but also the sharing. Even if we have a separate storage for credentials, you would currently have to expose them to the sharees so they are able to sync. Unless they have to submit their own password, but that kind of defeats the purpose of sharing. So that one make https://github.com/nextcloud/server/issues/1600 a lot more complex.

[tcitworld]

That's odd, I don't see how this could work since not much has changed since then. Will try to reproduce.

Even if we have a separate storage for credentials, you would currently have to expose them to the sharees so they are able to sync.

Subscriptions are exposed as regular calendars inside this app because they are cached on server, so we could make sure they don't expose auth information (currently probably accessible through href and default displayname). We could do the same for any CalDAV client as long as the subscription URI contains credentials. In that case, we wouldn't need to worry about storing the auth values separately or how to handle sharing.

See https://github.com/nextcloud/server/blob/decb70b9ac6048e72305154af841271902f6b10c/apps/dav/lib/CalDAV/CalendarHome.php#L107-L116

[ChristophWurst]

Okay, so you would allow sharees to see the cached calendar, but they will be unable to refresh it, right?

[tcitworld]

No one can refresh the cached calendar subscriptions right now anyway.

This is either defined by the calendar data itself through REFRESH-INTERVAL or X-PUBLISHED-TTL icalendar keys, or fallback to the value defined by the calendarSubscriptionRefreshRate app setting (defaults to one week).

[ChristophWurst]

Oh, then I simply read an outdated comment about the sync happening just in the browser. Thanks for the clarification.

[endo34]

Didn't see an answer while scrolling this thread: what if my username is an email address? The Webcal log-in should be:

user@example.com:password@http://example.com/webdav

I think the email ampersand (@) confuses NextCloud. I get an error that says:

Please enter a valid link (starting with http://, https://, webcal://, or webcals://)

[rugk]

If that is supposed to be a HTTP Auth (with username0email), the syntax is however indeed wrong. Correct would be http://user@example.com:password@example.com/webdav. The protocol of course has indeed to come first.

[endo34]

Of course- thank you. The problem remains that the @ is causing nextcloud to interpret the username as the service url. Probably a more clear explanation is:

http://username@username.com:password@service-address.com/webdav

Any suggestions?

[rightsaidfred99]

Is it safe to expose a password like this??

Edit: it works....but only 10% of my events show. There are so many missing events it's not quite usable. Is this still unsupported as the issue has been open several years?

[rugk]

Is it safe to expose a password like this??

Well… it's stored next to the URL in the DB or wherever it is shown (AFAIK when hovering over the calendar in the app you can also see the URL or so). As such, that needs to be taken into account. The (calendar) devs or so may also not be aware that there can be sensitive information embedded. Other than that, it's not more or less safe than a separate input for username and password. Remember HTTPS URLs are encrypted. Having that URL in your browser history would potentially be worse in most threat models… :upside_down_face:

[mkrecek234]

@tcitworld HTTP Authentication does not seem to work reliably - I cannot add a calendar subscription in Nextcloud with such a link (which perfectly works in Google Chrome to download the ics files).

https://u.ser%40hadomain.de:smallBig%3B2@mail.hadomain.de/SOGo/dav/u.ser@hadomain.de/Calendar/personal.ics

I get Authentication failed in Nextcloud log, as it seems not to store the credentials properly. (FYI the URLs was anonymised)

[simonspa]

Subscribing to https://myuser:mypass@example.com/some/webcal.ics for me results in

{"reqId":"q8VoNa4IIlJhW3a4ZI24","level":2,"time":"2023-01-12T11:33:03+01:00","remoteAddr":"","user":"--","app":"dav","method":"","url":"--","message":"Subscription 52 could not be refreshed due to a network error","userAgent":"--","version":"25.0.2.3","exception":{"Exception":"GuzzleHttp\\Exception\\ClientException","Message":"Client error: `GET https://example.com/some/webcal.ics` resulted in a `401 Unauthorized` response","Code":401,"Trace":[{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Middleware.php","line":69,"function":"create","class":"GuzzleHttp\\Exception\\RequestException","type":"::","args":[{"__class__":"GuzzleHttp\\Psr7\\Request"},"*** sensitive parameters replaced ***",null,[],null]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/Promise.php","line":204,"function":"GuzzleHttp\\{closure}","class":"GuzzleHttp\\Middleware","type":"::","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/Promise.php","line":153,"function":"callHandler","class":"GuzzleHttp\\Promise\\Promise","type":"::","args":[1,"*** sensitive parameters replaced ***",null]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/TaskQueue.php","line":48,"function":"GuzzleHttp\\Promise\\{closure}","class":"GuzzleHttp\\Promise\\Promise","type":"::","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/Promise.php","line":248,"function":"run","class":"GuzzleHttp\\Promise\\TaskQueue","type":"->","args":[true]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/Promise.php","line":224,"function":"invokeWaitFn","class":"GuzzleHttp\\Promise\\Promise","type":"->","args":[]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/Promise.php","line":269,"function":"waitIfPending","class":"GuzzleHttp\\Promise\\Promise","type":"->","args":[]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/Promise.php","line":226,"function":"invokeWaitList","class":"GuzzleHttp\\Promise\\Promise","type":"->","args":[]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/promises/src/Promise.php","line":62,"function":"waitIfPending","class":"GuzzleHttp\\Promise\\Promise","type":"->","args":[]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Client.php","line":187,"function":"wait","class":"GuzzleHttp\\Promise\\Promise","type":"->","args":[]},{"file":"/var/www/nextcloud/lib/private/Http/Client/Client.php","line":218,"function":"request","class":"GuzzleHttp\\Client","type":"->","args":["get","https://example.com/some/webcal.ics",["/home/data/nextcloud/files_external/rootcerts.crt",30,[10],{"__class__":"GuzzleHttp\\HandlerStack"},[false],"And 3 more entries, set log level to debug to see all entries"]]},{"file":"/var/www/nextcloud/apps/dav/lib/CalDAV/WebcalCaching/RefreshWebcalService.php","line":217,"function":"get","class":"OC\\Http\\Client\\Client","type":"->","args":["https://example.com/some/webcal.ics",[[10],{"__class__":"GuzzleHttp\\HandlerStack"},[false],["myuser","mypass"]]]},{"file":"/var/www/nextcloud/apps/dav/lib/CalDAV/WebcalCaching/RefreshWebcalService.php","line":89,"function":"queryWebcalFeed","class":"OCA\\DAV\\CalDAV\\WebcalCaching\\RefreshWebcalService","type":"->","args":[[52,"examplecom-1","principals/users/myuser","https://myser:mypass@example.com/some/webcal.ics",1673519570,"And 9 more entries, set log level to debug to see all entries"],[]]},{"file":"/var/www/nextcloud/apps/dav/lib/BackgroundJob/RefreshWebcalJob.php","line":115,"function":"refreshSubscription","class":"OCA\\DAV\\CalDAV\\WebcalCaching\\RefreshWebcalService","type":"->","args":["principals/users/myuser","examplecom-1"]},{"file":"/var/www/nextcloud/lib/public/BackgroundJob/Job.php","line":78,"function":"run","class":"OCA\\DAV\\BackgroundJob\\RefreshWebcalJob","type":"->","args":[["principals/users/myuser","examplecom-1"]]},{"file":"/var/www/nextcloud/lib/public/BackgroundJob/Job.php","line":64,"function":"start","class":"OCP\\BackgroundJob\\Job","type":"->","args":[{"__class__":"OC\\BackgroundJob\\JobList"}]},{"file":"/var/www/nextcloud/apps/dav/lib/BackgroundJob/RefreshWebcalJob.php","line":108,"function":"execute","class":"OCP\\BackgroundJob\\Job","type":"->","args":[{"__class__":"OC\\BackgroundJob\\JobList"},{"__class__":"OC\\Log"}]},{"file":"/var/www/nextcloud/cron.php","line":152,"function":"execute","class":"OCA\\DAV\\BackgroundJob\\RefreshWebcalJob","type":"->","args":[{"__class__":"OC\\BackgroundJob\\JobList"},{"__class__":"OC\\Log"}]}],"File":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Exception/RequestException.php","Line":113,"message":"Subscription 52 could not be refreshed due to a network error","exception":[],"CustomMessage":"Subscription 52 could not be refreshed due to a network error"},"id":"63bfe1ee9ecca"}

[RokeJulianLockhart]

For this, some kind of stock credential manager would be necessary, surely. I realize that this would be a lot to implement, but I'd love to be able to store and manage these credentials from Bitwarden.

[pannal]

Bump. Just tried this with an existing Horde Kronolith installation. For reference: DAVx⁵ works perfectly with this on Android.

User/password auth doesn't exit (or work via URL) in Nextcloud Calendar.

There is the option to add external storage for WebDAV and it works with Horde WebDAV ICS connectors or remote CalDAV ones (connects and shows a green checkmark). Why can't this app make use of the credentials stored there? That'd maybe be a quicker way to implement this. Add a CalDAV URL as external storage including credentials, then add the same URL as external read-only (why read-only btw?) calendar to the Calendar app, without credentials, using the credentials stored in Nextcloud for this URL.