Identity And Access · GoingNinja Manual Knowledge Wiki

It is not product login. It is the shared reader boundary in front of invited knowledge and preview surfaces.

1. What The Current Model Is

GoingNinja now uses one common reader-access shape:

public root on rascher.online
protected reading behind Cloudflare Access
one public request entry path on rascher.online
one small access registry in Cloudflare D1
manual review before access is granted
explicit Cloudflare group membership when access is approved

The current live protected manual surface remains:

https://wiki.rascher.online/

The public request entry now lives on:

https://rascher.online/access/request

The internal account-settings surface now lives at the protected root account path:

https://rascher.online/account/
Account Settings

2. What A Reader Does

The current reader flow is:

open the public root or request path
request wiki access directly
submit real first name, last name, and email
receive request confirmation and wait for manual review
if approved, sign in with the approved email through Cloudflare Access
use internal account settings for deletion later

Right now the request flow is intentionally single-purpose:

there is no area chooser
wiki is the only requestable area today

Registration requests are intentionally narrow. Only these fields are accepted:

first name
last name
email

The worker rejects obviously invalid identity strings and the request is still reviewed manually before any protected access is granted.

3. What The Public Root May Show

The public entry surface is intentionally small.

It may show:

Log in to wiki
Request wiki access

It should not carry internal account actions like deletion. Deletion belongs to the internal account-settings path, not to the public entry surface.

Inside protected surfaces, account settings belong to the page chrome:

the wiki exposes the authenticated reader profile in the shell
that profile links to the protected account page
the assistant does not own account-management actions

4. What Cloudflare Controls

Cloudflare Access remains the protection layer for:

the protected manual
preview domains such as www.preview.<product-domain>
later operator or internal reader surfaces

The default policy shape is now group-based instead of direct email lists:

rascher-online::admins
rascher-online::manual-readers
preview::<product>::readers
preview::<product>::operators

The practical rule is:

root stays public
request entry stays public
protected reading stays behind Cloudflare Access
approval must update both D1 review state and the matching Cloudflare group

5. What The Registry Stores

The shared registry is intentionally small.

It stores:

reader identity tuple: first name, last name, email
request type: registration or deletion
request status
registration timestamp
last login timestamp
review timestamps
event log entries for later traceability

It does not store product-local session state, product secrets, or application data.

6. How Approval Works

The first admin path is deliberately small and protected.

The public worker stores requests in D1. When the mail provider is present, the worker also sends:

a confirmation mail to the requester
a review notification mail to the operator review inbox

That mail flow is now defined explicitly in:

Access Email Behavior

System mail should use a dedicated sending subdomain instead of the root domain mailbox identity.

The current target contract is:

primary sender: access@notify.rascher.online
root-domain sender only as transitional fallback
reply handling through the operator inbox

That keeps transactional access mail reputation separate from the root domain and scales better when more protected surfaces and MVP notifications are added later.

Admin review can now run through:

protected admin review on https://rascher.online/admin/access

The CLI remains available for the same shared contract:

node scripts/manage-root-access.mjs list-requests
node scripts/manage-root-access.mjs show-directory
node scripts/manage-root-access.mjs sync-manual-policies
node scripts/manage-root-access.mjs sync-root-apps
node scripts/manage-root-access.mjs approve <email>
node scripts/manage-root-access.mjs reject <email>
node scripts/manage-root-access.mjs keep-active <email>
node scripts/manage-root-access.mjs mark-deleted <email>

Approval is not complete when D1 says approved. Approval is complete only when:

the registry state is approved
the approved email is added to rascher-online::manual-readers
the manual Access applications allow that group

Deletion is not complete when a request row exists. Deletion is complete only when:

the email is removed from the reader group
the registry state is marked deleted

7. What This Does Not Replace

This model does not replace:

product member auth
project-local session storage
product-local consent flows
product-local privacy obligations

It is the shared invited-reader boundary for the platform and protected previews.

8. Session Continuity Rule

The Mistral assistant must keep its own conversation continuity across page changes. Reader login is not a substitute for chat persistence.

That means:

Cloudflare Access controls who may read protected surfaces
the assistant keeps its conversation state on its own origin

These are different concerns and both must work.

9. Protected Session Profile For Embedded Tools

Protected surfaces may expose a narrow authenticated session endpoint for shared UI elements.

The current example is the wiki assistant shell:

the protected root validates the Cloudflare Access assertion
the session endpoint returns only the small profile needed for the shell
the wiki shell shows the reader profile in the page chrome outside the bot itself
the embedded assistant keeps only chat history and answer state

This keeps identity in the protected root contract instead of duplicating profile state inside the assistant service.