Nested Logins

What you'll learn:

• How login access is evaluated on nested pages
• When a broader child login is an intentional, valid setup
• How to spot and fix an unintended open-access gap
• How to audit your app's login pages for consistent access control

How login access works on nested pages

When you place a login page inside another login-protected page, it's natural to assume that only users who can reach the parent will ever reach the child. That's not how Knack evaluates access.

Each login page checks its own allowed roles independently; access doesn't cascade down from parent to child. If a nested login page allows a broader (or different) set of roles than its parent, any user whose role matches the child's settings can reach it directly, even if that same role is excluded from the parent, as long as they have the page URL.

When a mismatch is intentional

There are legitimate reasons to give a nested login broader or different access than its parent:

• A custom integration or external script needs a specific user to update a single field, while the surrounding pages stay locked to a specific role
• A support or admin workflow lives inside a broader app hierarchy but needs to be reachable by a different role for one narrow task
• A public-facing form or entry point is embedded within an otherwise role-restricted section

In these cases, Knack won't stop you from configuring it this way.

When a mismatch becomes a problem

A problem could be an unintentional mismatch: the parent login is restricted to specific roles, but the nested login was left at "All logged-in users" (or another broad role set) without the builder realizing users can reach the child directly via URL, bypassing the parent entirely.

A logged-in user whose role doesn't match the parent login can still reach a nested page if:

1. They have, or can guess, the direct URL
2. The nested login page's access isn't restricted to match (or be a subset of) the parent's roles

Recommended setup patterns

The safest pattern is to make each nested login's allowed roles an equal or stricter subset of its parent's allowed roles.

Standard setup: child is more restrictive than parent

Parent login   → Staff, Admin
  └── Child login → Admin only
       └── Admin-only pages

Both roles can reach the parent. Only Admins can reach the child, whether they arrive via the parent or go straight to its URL.

Intentional broader access: narrow task for a specific role

Parent login   → Admin only
  └── Child login → Staff only
       └── Field update form (Staff workflow)

This is valid when Staff need that specific nested page for a defined purpose, and the access is expected and documented.

Pattern to avoid: unintentional open access

Parent login   → Admin only
  └── Child login → All logged-in users
       └── Pages that should be Admin-only

Any logged-in user could reach this child page directly, regardless of the parent's restrictions. If this isn't intentional, restrict the child login to match or be a subset of the parent's roles.

Auditing your login pages

• If your nested login access is intentional, no action is needed — just make sure it's documented and expected.
• If you want a nested page's access to stay consistent with its parent, set role restrictions explicitly on each login page.

To audit an app:

1. Open the page in Builder
2. Select the lock icon, or go to Page Settings → Access
3. Confirm "Who can access this Page?" is set as intended at every login level in the hierarchy