Native Role‑Permission System vs. Custom Hook‑Based Checks for Least‑Privilege Access After Credential Expiry in ProcessWire

Goal: guarantee that once a user’s credentials have expired (session timeout or remember‑me token invalidation), any subsequent request for a page that requires specific permissions is denied, regardless of whether the request comes from the front‑end API, template rendering, or cached content.

Constraint: ProcessWire’s native role‑permission system centralizes access control and automatically respects $user->hasPermission() checks, but it cannot express dynamic, context‑based rules without creating additional roles. Custom hook‑based checks (e.g., adding a hook before Page::render) allow fine‑grained decisions based on page fields, time, or headers, yet they require developers to duplicate permission logic and to register the hook early enough to intercept all request paths; otherwise, expired‑credential checks can be bypassed. Additionally, any Page objects or custom caches that were loaded before expiration may remain accessible unless the permission check is repeated.

• Does the native role‑permission system reliably deny access for all request types after credentials have expired, or are there scenarios where cached Page objects bypass the check?
• How can developers ensure that a custom hook‑based permission check is invoked early enough to cover every possible entry point (API, template, admin) without missing any request?
• Is there a recommended way to combine the auditability of native roles with the flexibility of hooks so that permission logic is not duplicated while still enforcing least‑privilege access after credential expiry?