[SebastianKrupinski]

Summary

• Resolves: Support webcal http auth & store credentials calendar#70

• Credentials in the user info of a subscription source URL were stored in plain text and returned to clients as part of the source. They were also used without percent-decoding, so Basic auth failed for passwords containing characters such as '@', ':' or '#'.

• On create and update, split the user info off the source, percent-decode it and store it encrypted in the new calendarsubscriptions.credentials column. Sending back an unchanged source without user info keeps the stored credentials. Existing subscriptions are migrated. Credentials are decrypted when listing a user's subscriptions and used for Basic auth when the feed is refreshed.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[SebastianKrupinski]

/backport to stable35

[SebastianKrupinski]

/backport to stable34

[SebastianKrupinski]

/backport to stable33

[SebastianKrupinski]

Yes there are better ways to do this then creating the crypto library with "Server::get(ICrypto::class)".

But since this is only needed for 2 operations I didn't think complicating this fix by injecting the class in the constructors was worth it, as it would require modifying event more files from the server.php to console commands

[theroch]

@SebastianKrupinski
When exporting and importing the user account, the login credentials are lost (UserMigration/CalendarMigrator.php:218ff)

• The export only writes the "source," and the login credentials are no longer stored there. After an import, authentication fails, and the subscription no longer works.
• Previously, the login credentials were exported in plain text. That wasn’t ideal, but the subscription remained usable.
• This should be deliberately decided in the PR: either reintroduce the login credentials into the URL or document this behavior.

[SebastianKrupinski]

@SebastianKrupinski When exporting and importing the user account, the login credentials are lost (UserMigration/CalendarMigrator.php:218ff)

* The export only writes the "source," and the login credentials are no longer stored there. After an import, authentication fails, and the subscription no longer works.

Hi @theroch

You are correct we do not export the credentials field at the moment, I was on the fence on how to handle this, as you said exporting the credentials in plan text is not ideal.

And there is no way to export them encrypted. Well there is by it would only work on the same system.

[theroch]

@SebastianKrupinski
It is not possible to me to contribute directly to this PR.
I've added my suggestions as patch files.
You have to apply them in the right order, starting with 0001.

0001-perf-dav-decrypt-subscription-credentials-only-when-.patch
0002-fix-dav-handle-malformed-subscription-credentials.patch
0003-fix-dav-ignore-credentials-when-checking-for-duplica.patch
0004-fix-dav-allow-removing-subscription-credentials.patch

[DerDreschner]

You are correct we do not export the credentials field at the moment, I was on the fence on how to handle this, as you said exporting the credentials in plan text is not ideal.

It is not ideal, but the way we currently handle it in other places. This would be fixed by nextcloud/user_migration#1031

[SebastianKrupinski]

It is not ideal, but the way we currently handle it in other places. This would be fixed by nextcloud/user_migration#1031

@DerDreschner that definitely solves the issue. I'll make the changes so the credentials get exported and your PR solves our issue.

[DerDreschner]

I'll make the changes so the credentials get exported and your PR solves our issue.

@SebastianKrupinski It's not a PR, only an issue I created once I've worked on other user migration exports 😅 Need to be done by @come-nc as maintainer or someone else.

[SebastianKrupinski]

@SebastianKrupinski It's not a PR, only an issue I created once I've worked on other user migration exports 😅 Need to be done by @come-nc as maintainer or someone else.

Oh. lol. I assumed you where working on it