Feature request: Per-user page access restrictions for internal pages

[Plattenspatz]

Use Case

We're running a single Kener instance that serves status pages for multiple customers (multi-tenant). Each customer should only see their own status pages — for example, a user from "Customer A" should be able to access /customer-a-monitoring but not /customer-b-monitoring.

Right now, all pages in Kener are public and visible to everyone. PR #714 introduces the concept of internal pages (public vs. internal toggle), which is a great foundation. Our use case would build on top of that by adding per-user filtering for internal pages.

Proposed Behavior

• Pages can be marked as internal (as proposed in Implement internal pages #714)
• Each user gets an optional page access pattern (e.g. customer-a*)
• When an internal page is accessed, Kener checks:
  1. Is the user logged in? If not → redirect to sign-in (same as Implement internal pages #714)
  2. Does the user's access pattern match the page path? If not → return 404 (not 403, to avoid revealing that the page exists)
• The page switcher only shows pages the user is allowed to see
• Users without an access pattern (empty/wildcard) can see all internal pages (backward compatible, works for admins)

Rough Technical Idea

• Add a page_access_pattern text field to the users table
• Extend the access check in dashboardController.ts (where Implement internal pages #714 adds the internal check)
• Filter the page switcher API response (pages/get.ts) by the user's pattern
• Add a field in the user management UI for admins to set the pattern

Why This Matters

This is a common scenario for MSPs (Managed Service Providers) and hosting companies that want to give customers visibility into the health of their services without exposing other customers' infrastructure. A reverse proxy solution works but is fragile and hard to maintain compared to native support in Kener.

Willingness to Contribute

We'd be happy to implement this and submit a PR. Before we start, we'd like to know:

1. Is this something you'd consider merging into Kener?
2. Do you have a preferred approach for the access model (pattern-based as described, explicit page-to-user assignments, or something else)?
3. Should we wait for Implement internal pages #714 to be merged first, or base our work on that branch?
   Any feedback on the direction would be appreciated — we'd rather align early than submit something that doesn't fit the project's vision.

Related: #714, #697

[Plattenspatz]

After digging deeper into the codebase — especially the new RBAC system from v4.0.23 (#695) and the internal pages PR #714 — I think there's an opportunity to solve both problems with a single, unified mechanism. I'd like to put this on the table as an alternative.

Unified approach: Access Groups on pages + Role-based scoping

The core idea: instead of a separate "internal" toggle (#714) plus a separate access control layer, use one concept — Access Groups — that handles both public visibility and per-user filtering.

How it works

Pages get one or more Access Groups — a simple tag like public, customer-a, customer-b.

A default group public always exists. A page with the public group is visible to everyone without authentication — exactly like pages work today. A page without public requires login and is scoped to specific roles.

Roles get a "Page Access Scope" — in the role permission editor, admins select which access groups the role can view.

One access check replaces everything:

Page has "public" group?
  → Yes: allow (no login required)
  → No: user logged in?
    → No: redirect to sign-in
    → Yes: user's role has any of the page's groups in scope?
      → Yes: allow
      → No: 404 (not 403 — don't reveal the page exists)

Example

Page: "customer-a-monitoring"     Access Groups: [customer-a]
Page: "customer-b-monitoring"     Access Groups: [customer-b]
Page: "shared-infra"              Access Groups: [customer-a, customer-b]
Page: "public-status"             Access Groups: [public]

Role: "Customer A"                Page Scope: [customer-a]
Role: "Customer B"                Page Scope: [customer-b]
Role: "Admin"                     Page Scope: [] (empty = all pages)

• Alice (Role: Customer A) → sees customer-a-monitoring + shared-infra, gets 404 for customer-b-monitoring
• Bob (Role: Customer B) → sees customer-b-monitoring + shared-infra, gets 404 for customer-a-monitoring
• Admin → sees everything
• Anonymous visitor → sees only public-status

Why this unifies #714 and per-user access

The public group replaces the page_is_internal boolean from #714. A page is "internal" simply because it doesn't have the public group — no separate flag needed. And the same mechanism that controls public/internal also controls which logged-in user sees which page.

This also handles cases that neither approach covers on its own — like a page shared between two customers ([customer-a, customer-b]), which would be hard to express with a boolean toggle or a single access pattern.

What this would touch in the codebase

• DB: access group field on pages (or a join table for multiple groups), scope field on roles
• dashboardController.ts: one access check (replacing the internal check from Implement internal pages #714)
• pages/get.ts: filter page switcher by the user's role scope
• Role permissions UI: new "Page Access Scope" section
• Page edit UI: access group selector (replaces the internal toggle from Implement internal pages #714)

Would love to hear your thoughts on this, @rajnandan1.