App Passwords: photo backup preset hands out an API Bearer token instead of WebDAV details

kayg commented

2026-10-02 13:35:12 +00:00

Owner

Owner report (2026-10-02)

The App Password preset "Photo upload · PhotoSync" created a Bearer token with scope API · upload only · Home: Photos/ and said "Send this in the Authorization header as a Bearer token". A phone photo-backup app does not know the calternal API. It speaks WebDAV with a server address, a username and a password. The owner: "this does not make sense? it says upload via the API as if photosync knows the calternal API?"

Cause

apps/web/src/routes/settings/account/AppPasswordsGroup.svelte requestForPreset: the photos preset maps to { protocol: 'api', access: 'upload_only' }. The WebDAV server already has the right access level: DavFilesAccess::UploadOnly in crates/calternal-dav/src/files.rs (PROPFIND lists names so the app can skip files it already sent; PUT and MKCOL create; no GET, no replace, no delete; lock class not advertised).

Fix

The photo-backup preset grants webdav · upload_only below the chosen Home folder (default Photos/).
The ready panel shows the same copy-ready rows as the Files preset: Server (the WebDAV URL that opens at the chosen folder), Username, Password. No "Bearer token", no "Authorization header". Click-to-copy on the monospace value (#723) if merged; otherwise the existing Copy pill.
One plain sentence of help: "In your photo backup app, add a WebDAV server with these details. It can add new photos to but cannot see, change or delete anything else."
Preset label without a product name: "Photo backup from your phone". Product names stay out of UI, code and comments.
Do not repeat the section intro paragraph inside the ready panel.
Existing photo passwords created with api · upload_only keep working; list them as they are.

Tests

Unit: the preset request has scopes [{protocol:'webdav', access:'upload_only'}] and the home prefix.
e2e like a User: create the preset, read Server/Username/Password from the panel, then with those values over real WebDAV: PROPFIND the folder (names only), MKCOL 2026/10, PUT a HEIC and a MOV, PUT the same name again (refused, no overwrite), GET (refused), DELETE (refused), PUT outside the folder (refused). The uploaded photo then appears in Photos.
Screenshots of the ready panel, macOS emulation, both themes.

## Owner report (2026-10-02) The App Password preset "Photo upload · PhotoSync" created a **Bearer token** with scope `API · upload only · Home: Photos/` and said "Send this in the Authorization header as a Bearer token". A phone photo-backup app does not know the calternal API. It speaks WebDAV with a server address, a username and a password. The owner: "this does not make sense? it says upload via the API as if photosync knows the calternal API?" ## Cause `apps/web/src/routes/settings/account/AppPasswordsGroup.svelte` `requestForPreset`: the `photos` preset maps to `{ protocol: 'api', access: 'upload_only' }`. The WebDAV server already has the right access level: `DavFilesAccess::UploadOnly` in `crates/calternal-dav/src/files.rs` (PROPFIND lists names so the app can skip files it already sent; PUT and MKCOL create; no GET, no replace, no delete; lock class not advertised). ## Fix 1. The photo-backup preset grants `webdav · upload_only` below the chosen Home folder (default `Photos/`). 2. The ready panel shows the same copy-ready rows as the Files preset: **Server** (the WebDAV URL that opens at the chosen folder), **Username**, **Password**. No "Bearer token", no "Authorization header". Click-to-copy on the monospace value (#723) if merged; otherwise the existing Copy pill. 3. One plain sentence of help: "In your photo backup app, add a WebDAV server with these details. It can add new photos to <folder> but cannot see, change or delete anything else." 4. Preset label without a product name: "Photo backup from your phone". Product names stay out of UI, code and comments. 5. Do not repeat the section intro paragraph inside the ready panel. 6. Existing photo passwords created with `api · upload_only` keep working; list them as they are. ## Tests - Unit: the preset request has scopes `[{protocol:'webdav', access:'upload_only'}]` and the home prefix. - e2e like a User: create the preset, read Server/Username/Password from the panel, then with those values over real WebDAV: PROPFIND the folder (names only), MKCOL `2026/10`, PUT a HEIC and a MOV, PUT the same name again (refused, no overwrite), GET (refused), DELETE (refused), PUT outside the folder (refused). The uploaded photo then appears in Photos. - Screenshots of the ready panel, macOS emulation, both themes.

app-password-photo-chooser-1440-dark.png

253 KiB

app-password-photo-chooser-1440-light.png

228 KiB

app-password-photo-chooser-390-dark.png

104 KiB

app-password-photo-chooser-390-light.png

81 KiB

app-password-photo-chooser-820-dark.png

214 KiB

app-password-photo-chooser-820-light.png

149 KiB

app-password-photo-ready-1440-dark.png

253 KiB

app-password-photo-ready-1440-light.png

225 KiB

app-password-photo-ready-390-dark.png

70 KiB

app-password-photo-ready-390-light.png

45 KiB

app-password-photo-ready-820-dark.png

187 KiB

app-password-photo-ready-820-light.png

135 KiB

kayg commented

2026-10-02 13:36:52 +00:00

Author

Owner

Starting #849 on job/photopw-849, based on c4a61e8cf090170f35b1bed3350d9de20c83ecd5 (origin/dev). I’m tracing the photos preset and matching it to the existing WebDAV Files preset. The initial issue report identifies the preset protocol mapping as the cause; I’ll verify the request and panel data flow before editing.

Starting #849 on `job/photopw-849`, based on `c4a61e8cf090170f35b1bed3350d9de20c83ecd5` (`origin/dev`). I’m tracing the photos preset and matching it to the existing WebDAV Files preset. The initial issue report identifies the preset protocol mapping as the cause; I’ll verify the request and panel data flow before editing.

kayg commented

2026-10-02 13:37:18 +00:00

Author

Owner

Owner follow-up (2026-10-02): the Custom scopes panel for a WebDAV password shows only Username and Password, with no server address. Extend the fix: every password with a WebDAV scope (any preset, including Custom) shows a Server row. When a Home folder is set, the Server URL opens at that folder (/dav/files/<account>/<folder>/), because the credential cannot use the Home root. CalDAV passwords keep their own server row and setup profile. Add an e2e case for Custom WebDAV + Upload only + Home folder.

Owner follow-up (2026-10-02): the Custom scopes panel for a WebDAV password shows only Username and Password, with no server address. Extend the fix: **every** password with a WebDAV scope (any preset, including Custom) shows a **Server** row. When a Home folder is set, the Server URL opens at that folder (`/dav/files/<account>/<folder>/`), because the credential cannot use the Home root. CalDAV passwords keep their own server row and setup profile. Add an e2e case for Custom WebDAV + Upload only + Home folder.

kayg commented

2026-10-02 13:38:15 +00:00

Author

Owner

Finding: requestForPreset('photos') currently sends [{ protocol: 'api', access: 'upload_only' }] with the chosen Home prefix, and the generic ready panel therefore labels the one-time secret as a Bearer token. The same panel already builds a /dav/files/<account-id>/ Server value for the Files preset. crates/calternal-dav/src/files.rs already defines DavFilesAccess::UploadOnly: PROPFIND, PUT and MKCOL are allowed; reads and destructive methods are denied. I’m switching the preset to that existing DAV access and will exercise it over the real local server.

Finding: `requestForPreset('photos')` currently sends `[{ protocol: 'api', access: 'upload_only' }]` with the chosen Home prefix, and the generic ready panel therefore labels the one-time secret as a Bearer token. The same panel already builds a `/dav/files/<account-id>/` Server value for the Files preset. `crates/calternal-dav/src/files.rs` already defines `DavFilesAccess::UploadOnly`: PROPFIND, PUT and MKCOL are allowed; reads and destructive methods are denied. I’m switching the preset to that existing DAV access and will exercise it over the real local server.

kayg commented

2026-10-02 14:51:25 +00:00

Author

Owner

Finding: scopeSummary treated every WebDAV row as full read/write, so changing the photo preset to WebDAV would have mislabeled its saved permission as “Files · read and change.” The preset now displays “Photo uploads · add only” for WebDAV upload-only rows. The chooser and one-time setup text also state that the app can see names within its selected folder while it cannot open, replace, delete, or access other folders. E2E coverage checks these labels and probes the real DAV permission.

Finding: `scopeSummary` treated every WebDAV row as full read/write, so changing the photo preset to WebDAV would have mislabeled its saved permission as “Files · read and change.” The preset now displays “Photo uploads · add only” for WebDAV upload-only rows. The chooser and one-time setup text also state that the app can see names within its selected folder while it cannot open, replace, delete, or access other folders. E2E coverage checks these labels and probes the real DAV permission.

kayg referenced this issue

2026-10-02 16:47:31 +00:00

Audit: plain-language UI copy and names across every screen #860

kayg commented

2026-10-02 17:24:57 +00:00

Author

Owner

Copy audit evidence for the same App Passwords screen. The existing photo preset issue covers the “Photo upload · PhotoSync” label and the Bearer-token path. These adjacent strings need the same plain-language and no-product-name review.

apps/web/src/routes/settings/account/AppPasswordsGroup.svelte:45-60: the visible protocol names are “CalDAV”, “WebDAV”, “API”, “MCP” and “IMAP”. Presets include “Calendar apps · CalDAV”, “Files / WebDAV”, “Automation · API”, “AI assistant · MCP (read only)” and “Custom scopes”; custom options repeat the protocol names. Use names by task, such as “Calendar apps”, “Files”, “Notes sync”, “Automation” and “Assistant tools”. Rename “Custom scopes” to “Custom access”.
Line 335: “Choose its protocol and access” → “Choose what this password can do”.
Lines 403, 441 and 460: setup steps say “Add CalDAV Account” / “Other CalDAV Account” / “Choose CalDAV”. Use general steps such as “Add a calendar account from a server”, followed by the existing Server, Username and Password fields.
Lines 452, 457 and 462: “Other apps (Thunderbird, DAVx⁵, …)”, “Thunderbird” and “DAVx⁵ on Android” name third-party products. Use “Other calendar apps” and “Calendar app on Android”.
Lines 495-499: “Bearer token”, “Authorization header”, “Bearer token” and “scope” → “App password” and “Use this password in the app’s sign-in settings. It can [plain access summary].”
Lines 509, 532-535: the password list exposes scopeSummary, “Scope preset”, and “The selected protocol and access are enforced for every request.” Use plain access summaries and “Choose what this password can do”.
Lines 538, 545-546 and 554: “Home folder prefix” / “Protocol” → “Limit to this folder” / “App type”. Keep host values in the custom form when the User needs them.
Lines 559-569: “Plugin ID”, “Plugin access” and “Resource ID” → “Feature name”, “Feature access” and “Limit to one item”. Explain when an optional value is needed. Line 164: “Plugin access needs the API protocol.” → “Choose web access for this feature.” Line 167: “Plugin access cannot be combined with a Home folder prefix.” → “Feature access cannot be limited to a folder.”
Lines 198-212: scopeSummary and lastUsed show protocol names and “Plugin: …”. Use the same plain access names as the create form.

Owner rule: no jargon in UI labels and no third-party product names in UI, code or comments. The photo preset remains the specific behavior fix in #849; this comment records the other copy defects on its screen.

Expected behaviour: each password describes which apps can use it and what they can do in plain words. The User can create, use and revoke every preset without reading protocol names or product-specific directions.

Test idea: add copy assertions for all presets and custom access. Include the ready view, existing-password rows and screen-reader names. Keep the WebDAV photo-backup acceptance checks from this issue.

Copy audit evidence for the same App Passwords screen. The existing photo preset issue covers the “Photo upload · PhotoSync” label and the Bearer-token path. These adjacent strings need the same plain-language and no-product-name review. - `apps/web/src/routes/settings/account/AppPasswordsGroup.svelte:45-60`: the visible protocol names are “CalDAV”, “WebDAV”, “API”, “MCP” and “IMAP”. Presets include “Calendar apps · CalDAV”, “Files / WebDAV”, “Automation · API”, “AI assistant · MCP (read only)” and “Custom scopes”; custom options repeat the protocol names. Use names by task, such as “Calendar apps”, “Files”, “Notes sync”, “Automation” and “Assistant tools”. Rename “Custom scopes” to “Custom access”. - Line 335: “Choose its protocol and access” → “Choose what this password can do”. - Lines 403, 441 and 460: setup steps say “Add CalDAV Account” / “Other CalDAV Account” / “Choose CalDAV”. Use general steps such as “Add a calendar account from a server”, followed by the existing Server, Username and Password fields. - Lines 452, 457 and 462: “Other apps (Thunderbird, DAVx⁵, …)”, “Thunderbird” and “DAVx⁵ on Android” name third-party products. Use “Other calendar apps” and “Calendar app on Android”. - Lines 495-499: “Bearer token”, “Authorization header”, “Bearer token” and “scope” → “App password” and “Use this password in the app’s sign-in settings. It can [plain access summary].” - Lines 509, 532-535: the password list exposes `scopeSummary`, “Scope preset”, and “The selected protocol and access are enforced for every request.” Use plain access summaries and “Choose what this password can do”. - Lines 538, 545-546 and 554: “Home folder prefix” / “Protocol” → “Limit to this folder” / “App type”. Keep host values in the custom form when the User needs them. - Lines 559-569: “Plugin ID”, “Plugin access” and “Resource ID” → “Feature name”, “Feature access” and “Limit to one item”. Explain when an optional value is needed. Line 164: “Plugin access needs the API protocol.” → “Choose web access for this feature.” Line 167: “Plugin access cannot be combined with a Home folder prefix.” → “Feature access cannot be limited to a folder.” - Lines 198-212: `scopeSummary` and `lastUsed` show protocol names and “Plugin: …”. Use the same plain access names as the create form. Owner rule: no jargon in UI labels and no third-party product names in UI, code or comments. The photo preset remains the specific behavior fix in #849; this comment records the other copy defects on its screen. Expected behaviour: each password describes which apps can use it and what they can do in plain words. The User can create, use and revoke every preset without reading protocol names or product-specific directions. Test idea: add copy assertions for all presets and custom access. Include the ready view, existing-password rows and screen-reader names. Keep the WebDAV photo-backup acceptance checks from this issue.

kayg referenced this issue

2026-10-02 17:25:52 +00:00

Audit: module docs and stale comments (comments are docs) #863

kayg referenced this issue

2026-10-02 17:51:59 +00:00

Audit: plain-language UI copy and names across every screen #860

kayg commented

2026-10-02 18:18:46 +00:00

Author

Owner

Runtime finding: bun run test:e2e:app-passwords reached app-password creation (HTTP 200), then timed out at its existing API-row summary check. The merged #629 scopeSummary() now renders full API access as API access · can view and change, while the retained E2E expected API access · read and change. I am aligning that one UI-copy assertion with the merged chooser text; protocol, scope, status-code, and authorization assertions remain unchanged.

Runtime finding: `bun run test:e2e:app-passwords` reached app-password creation (HTTP 200), then timed out at its existing API-row summary check. The merged #629 `scopeSummary()` now renders full API access as `API access · can view and change`, while the retained E2E expected `API access · read and change`. I am aligning that one UI-copy assertion with the merged chooser text; protocol, scope, status-code, and authorization assertions remain unchanged.

kayg commented

2026-10-02 18:39:09 +00:00

Author

Owner

Implementation report

Head: 64cd653108443af30c309fdab7c6cdad3b7c3ceb

Built: the Photo backup preset now creates a folder-scoped WebDAV upload_only password and shows copyable Server, Username, and Password fields. The selected Home folder is encoded in the Server URL. Existing API upload_only passwords remain supported. Added unit and guard tests, real DAV probes, and a performance profile path for the app-password route.

Files: apps/web/src/routes/settings/account/AppPasswordsGroup.svelte, apps/web/src/routes/settings/account/photoPreset.ts, apps/web/src/routes/settings/account/photoPreset.test.ts, apps/web/src/routes/settings/shared-components.guard.test.ts, apps/web/src/lib/components/Select.svelte.test.ts, apps/web/e2e/app-passwords.mjs, apps/web/e2e/fixtures/app-passwords-849.heic, apps/web/e2e/route-perf.mjs, bench/run.sh.

Gates

cargo fmt --check: exit 0 (no output)
cargo clippy -p calternal-auth --all-targets -- -D warnings: passed; Finished in 8m 05s
cargo test -p calternal-auth: test result: ok. 65 passed; 0 failed; 0 ignored
cargo clippy -p calternal-server --all-targets -- -D warnings: passed; Finished in 20m 28s
cargo test -p calternal-server: test result: ok. 107 passed; 0 failed; 3 ignored; 0 measured; 0 filtered out; finished in 20.67s
bun run check: svelte-check found 0 errors and 0 warnings
focused Vitest: Test Files 3 passed (3); Tests 6 passed (6)
bun run build: Wrote site to "build"; ✔ done; 71.9s
node --check apps/web/e2e/app-passwords.mjs: passed

The full web Vitest suite exited 1 after timeouts in existing unrelated component, Calendar, Files, and Settings tests: Test Files 23 failed | 131 passed (154) and Tests 28 failed | 1028 passed (1056). The real-server combined E2E reached four successful password creations, then failed in the merged #629 MCP write call: 400 !== 200 at apps/web/e2e/app-passwords.mjs:470. I left that MCP behavior unchanged.

A focused temporary real-server run exercised the #849 photo flow. It confirmed the stored grant is webdav · upload_only under Photos, HEIC and MOV uploads work, PROPFIND exposes names, GET/DELETE/out-of-folder writes are denied, and original file bytes survive a duplicate-name PUT. Two behavior gaps remain: duplicate PUT returns HTTP 204 and creates a renamed copy (APP_PASSWORD_E2E_849 2.HEIC) instead of refusing the duplicate as the issue test says; the uploaded HEIC did not appear in the Photos timeline because the timeline request returned an {error: ...} response. I did not change Files/Photos server behavior in this UI job. Please resolve these before treating the photo backup flow as complete.

Screenshot set

All screenshots use macOS platform emulation, at 390, 820, and 1440 px in light and dark themes. The ready-panel password is masked.

UX gaps closed

Setup now shows the three fields a WebDAV photo app needs, with copy actions and accurate folder-boundary permissions.
Home folder description is exposed to screen readers; keyboard selection and Enter-to-create work; phone/tablet targets were checked by touch.

UX gaps left

Photos timeline indexing returned an error in the real-server probe.
Duplicate same-name PUT is safely renamed rather than refused; it does not replace the original, but differs from the issue test wording.
The combined E2E is still blocked by the merged #629 MCP write returning HTTP 400.
The required performance profile was not run before the job time limit; no p50/p95, CPU, or RSS measurements are available.

Decisions not covered in DESIGN

I used the shorter neutral label “Photo backup” to keep its icon and heading on one line at phone width.
The ready copy says the password can see file names in the selected folder because PROPFIND exposes names; it cannot read or change existing file contents.

## Implementation report **Head:** `64cd653108443af30c309fdab7c6cdad3b7c3ceb` **Built:** the Photo backup preset now creates a folder-scoped WebDAV `upload_only` password and shows copyable Server, Username, and Password fields. The selected Home folder is encoded in the Server URL. Existing API `upload_only` passwords remain supported. Added unit and guard tests, real DAV probes, and a performance profile path for the app-password route. **Files:** `apps/web/src/routes/settings/account/AppPasswordsGroup.svelte`, `apps/web/src/routes/settings/account/photoPreset.ts`, `apps/web/src/routes/settings/account/photoPreset.test.ts`, `apps/web/src/routes/settings/shared-components.guard.test.ts`, `apps/web/src/lib/components/Select.svelte.test.ts`, `apps/web/e2e/app-passwords.mjs`, `apps/web/e2e/fixtures/app-passwords-849.heic`, `apps/web/e2e/route-perf.mjs`, `bench/run.sh`. ### Gates ```text cargo fmt --check: exit 0 (no output) cargo clippy -p calternal-auth --all-targets -- -D warnings: passed; Finished in 8m 05s cargo test -p calternal-auth: test result: ok. 65 passed; 0 failed; 0 ignored cargo clippy -p calternal-server --all-targets -- -D warnings: passed; Finished in 20m 28s cargo test -p calternal-server: test result: ok. 107 passed; 0 failed; 3 ignored; 0 measured; 0 filtered out; finished in 20.67s bun run check: svelte-check found 0 errors and 0 warnings focused Vitest: Test Files 3 passed (3); Tests 6 passed (6) bun run build: Wrote site to "build"; ✔ done; 71.9s node --check apps/web/e2e/app-passwords.mjs: passed ``` The full web Vitest suite exited 1 after timeouts in existing unrelated component, Calendar, Files, and Settings tests: `Test Files 23 failed | 131 passed (154)` and `Tests 28 failed | 1028 passed (1056)`. The real-server combined E2E reached four successful password creations, then failed in the merged #629 MCP write call: `400 !== 200` at `apps/web/e2e/app-passwords.mjs:470`. I left that MCP behavior unchanged. A focused temporary real-server run exercised the #849 photo flow. It confirmed the stored grant is `webdav · upload_only` under `Photos`, HEIC and MOV uploads work, PROPFIND exposes names, GET/DELETE/out-of-folder writes are denied, and original file bytes survive a duplicate-name PUT. Two behavior gaps remain: duplicate PUT returns HTTP 204 and creates a renamed copy (`APP_PASSWORD_E2E_849 2.HEIC`) instead of refusing the duplicate as the issue test says; the uploaded HEIC did not appear in the Photos timeline because the timeline request returned an `{error: ...}` response. I did not change Files/Photos server behavior in this UI job. Please resolve these before treating the photo backup flow as complete. ### Screenshot set All screenshots use macOS platform emulation, at 390, 820, and 1440 px in light and dark themes. The ready-panel password is masked. - [Photo chooser 390 light](https://git.kayg.org/attachments/fca890a6-a73a-4b12-9c88-e44b4de82518), [390 dark](https://git.kayg.org/attachments/57626f0d-e476-468d-a171-a7a2f3b0cdb6) - [Photo chooser 820 light](https://git.kayg.org/attachments/5cf19d18-b7ed-4f8e-a1d7-d5f152e78da2), [820 dark](https://git.kayg.org/attachments/bf4a698d-4b03-4ddf-a450-7bdd729d994c) - [Photo chooser 1440 light](https://git.kayg.org/attachments/f368035b-41fa-4aa1-a089-e3621587f8b5), [1440 dark](https://git.kayg.org/attachments/37d2084a-a18f-42be-a01f-3f05b8f429b3) - [Photo ready 390 light](https://git.kayg.org/attachments/aa040c91-e40e-48e9-9d86-206cdbf1c68c), [390 dark](https://git.kayg.org/attachments/872cd259-68c3-4657-a1ca-3fd4600afbf8) - [Photo ready 820 light](https://git.kayg.org/attachments/2e182d4b-a94f-4fe8-a1d7-d5f152e78da1), [820 dark](https://git.kayg.org/attachments/87173104-1f92-407d-90e1-171354a3dcc6) - [Photo ready 1440 light](https://git.kayg.org/attachments/fbd0ac1c-dd9e-4dde-bf31-c45104c9a17f), [1440 dark](https://git.kayg.org/attachments/aa09d781-d845-456c-b166-7a8bb1b4ce7a) ### UX gaps closed - Setup now shows the three fields a WebDAV photo app needs, with copy actions and accurate folder-boundary permissions. - Home folder description is exposed to screen readers; keyboard selection and Enter-to-create work; phone/tablet targets were checked by touch. ### UX gaps left - Photos timeline indexing returned an error in the real-server probe. - Duplicate same-name PUT is safely renamed rather than refused; it does not replace the original, but differs from the issue test wording. - The combined E2E is still blocked by the merged #629 MCP write returning HTTP 400. - The required performance profile was not run before the job time limit; no p50/p95, CPU, or RSS measurements are available. ### Decisions not covered in DESIGN - I used the shorter neutral label “Photo backup” to keep its icon and heading on one line at phone width. - The ready copy says the password can see file names in the selected folder because PROPFIND exposes names; it cannot read or change existing file contents.

kayg referenced this issue

2026-10-03 00:07:19 +00:00

Audit: plain-language UI copy and names across every screen #860

Rows
Columns

App Passwords: photo backup preset hands out an API Bearer token instead of WebDAV details #849

Owner report (2026-10-02)

Cause

Fix

Tests

Implementation report

Gates

Screenshot set

UX gaps closed

UX gaps left

Decisions not covered in DESIGN