Skip to content

Check permissions for routes accessed via deep-links. - #27427

Draft
dennisoelkers wants to merge 1 commit into
masterfrom
feat/enforce-route-permissions
Draft

dennisoelkers wants to merge 1 commit into
masterfrom
feat/enforce-route-permissions

Conversation

@dennisoelkers

Copy link
Copy Markdown
Member

Description

Motivation and Context

Prior to this PR, we were hiding links (e.g. buttons, items in navigations, ...) to routes that the user has insufficient permissions for, but when the user used a deep-link, we tried to render the change and (usually) failed on the first API call that the user was missing permissions for.

This PR is now making use of already defined permissions for routes to block overall access to them.

/nocl Internal refactoring.

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Refactoring (non-breaking change)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have requested a documentation update.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.

Plugin routes could already declare `permissions`, but `AppRouter` never
read the field, so any logged-in user who reached the URL directly got
the page. Navigation only hid the entries, and the unauthorized page was
reactive: it appeared only once an API call happened to return a 403.

Wrap plugin routes in a `RoutePermissionGuard` that renders
`UnauthorizedErrorPage` when the user lacks the declared permissions,
using the same `isPermitted` semantics the navigation uses so a route and
its nav entry cannot disagree.

`UnauthorizedErrorPage` now takes an optional `error`, since a route
level denial has no `FetchError`, plus a `displayPageLayout` pass-through
so routes already nested under `PageContentLayout` do not render a second
one.

Core routes declare no permissions and are unaffected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant