[pringelmann]

• closes Scoped app passwords: route gate #65526
• Ref Allow to restrict app password data access #2866
• Stacked on feat(auth): store scopes on app passwords #65268

Summary

Second step for limited app passwords: a token with scopes can only call the index.php and OCS routes its scopes open. Everything else gets a 403. Tokens without scopes aren't affected. DAV is in #65552.

How it works

• New middleware after the security middleware. Tokens without scopes skip it
• Controllers declare the scope they need with #[TokenScope] on a method or the class (unstable API in NCU\, so apps can use it). A method's attribute replaces the class one. No attribute means refused, so new endpoints start closed
• Apps not shipped with Nextcloud can only require their own <appid>: scopes
• Files routes need files:files:read / files:files:write, shares, sharee search and direct links files_sharing:shares:write. Calendar and contacts OCS routes in dav need the matching dav: scope
• Only deleting and rotating your own app password is open to every scoped token
• Admin-only routes and pages are refused before the controller runs

Known limit: an admin's calendar or contacts token can import into other users' calendars and address books via the user parameter, and a files token can transfer ownership of files to another account.

Tests

Unit tests for the middleware and its place in the stack. They pin the scopes of the share, direct link, preview and download endpoints, and check that templates, direct editing, conversion and page methods stay unannotated. Integration tests cover allowed and refused calls with a scoped token.

Next step

DAV enforcement, then the access picker in Settings.

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 (tests, reviewed)

[pringelmann]

Own middleware instead of one more check in SecurityMiddleware, which is hand-built and already does a lot. Also registered last on purpose, the test in DIContainerTest checks the order.

[pringelmann]

We only know it's a page once the controller returns a TemplateResponse, so it has to check after controller runs. Page GETs don't change data, so letting the controller run is fine though. What we block is the render, which pulls in every app's listeners and initial state.

[pringelmann]

@artonge I think adding multiple scopes later will be quite easy.

For example we can do something like:

• Any of several scopes -> Simply repeat the attribute. Existing single attributes still work
• All of several scopes -> Widen the param to string|array, which is backwards compatible too.

Either way I've moved the attribute to NCU so it can stay flexible until 37 cc @CarlSchwan

[nickvergessen]

shouldnt this be allowing to write shares?

[pringelmann]

Accepting mounts the share into your own files, so I decided to go with files write. The sharing write scope is for creating shares only, and a client without it should still be able to accept incoming shares. Happy to change it if you disagree?