mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-23 11:46:28 +00:00
rcourtman
28fd2d1c15
A settings capability is a promise the routes have to keep. Without an RBAC licence the authorizer allows every action, so capabilities derived from it alone reported true while the matching route stayed gated by ensureSettingsScope and in turn ensureAdminSession. canAccessPermissionSurface already refused to trust the authorizer for a non-admin proxy caller. The session half of that rule was never written, so a non-admin session on an unlicensed instance was told apiAccessRead, apiAccessWrite, singleSignOnRead and singleSignOnWrite were all available. The nav gates on exactly those flags, so the API Access and Single Sign-On tabs rendered, their first request came back 403, and the user got an error toast on a tab they were never able to use. Everything routed through canAccessAdminSurface was already correct, which is why authenticationRead and the audit surfaces behaved and these two did not. The fallback uses snapshot.sessionIsAdmin, which derives from the same sessionUserCarriesAdminPrivileges the routes enforce, so the capability now matches the answer the route will give. That keeps the OIDC-only pattern working, where SSO principals are the instance's only administrators. Nothing was reachable that should not have been. This is a capability reporting fix, not an access control one. Refs #1672 Contract-Neutral: settingsCapabilities JSON shape is unchanged (same 14 fields, same types); this corrects a wrong value returned to non-admin sessions when no RBAC authorizer is registered, no public-contract delta