[M0-S][ACCESS] Implement approval-gated demo registration, isolated sandboxes, quotas, and feedback

[andreazedda]

Problem

bmyCure4MM is exposed on the internet, but a visitor can mainly inspect public documentation and anonymous surfaces. Protected clinic, research and simulator-management routes require authentication, while the canonical application has no ordinary product login/registration lifecycle. LOGIN_URL currently points to Django admin, which rejects non-staff users by design.

The result is a product-access dead end:

visitor discovers the platform
→ cannot request access in-product
→ cannot activate a least-privilege account
→ cannot try the research workflow
→ must install locally or contact the owner outside the platform

This defeats the purpose of maintaining a public demonstration surface for clinicians, researchers, biomedical engineers and pharmacology users who are unlikely to install the repository locally.

Product decision

Adopt an approval-gated access-request model, not unrestricted self-service activation.

request access
→ verify email
→ owner/Access Approver reviews request
→ approve with role, scope, expiry and quota
→ user sets password through one-time link
→ user enters an isolated synthetic/demo workspace
→ activity, resource use and feedback are auditable
→ access expires or can be revoked

User-facing flow

Public surfaces

Provide clear entry points:

/accounts/login/
/access/request/
/access/request/submitted/
/access/request/status/
/password/reset/

The public home/docs surfaces should display:

Request demo access
Already approved? Sign in
What the demo contains
What the demo does not contain

Access-request form

Minimum fields:

email (required)
display name or nickname (required)
professional role (optional controlled vocabulary)
affiliation/organization (optional)
intended use / reason for request (required)
country/time zone (optional)
terms, privacy notice and research-only intended-use acknowledgement

Do not collect clinical data, patient names, MRNs, free-text medical records or secrets in this form.

State machine

Implement an explicit lifecycle, for example:

DRAFT
PENDING_EMAIL_VERIFICATION
PENDING_REVIEW
APPROVED
REJECTED
ACTIVATION_SENT
ACTIVE
SUSPENDED
EXPIRED
REVOKED

Every transition must be authorized, timestamped and audit-recorded.

Approval

The platform owner or a dedicated least-privilege Access Approver can:

• inspect verified requests;
• approve or reject with a reason code;
• assign a demo role;
• set activation expiry and account expiry;
• set per-user quotas;
• resend or revoke activation;
• suspend or revoke access;
• inspect privacy-safe usage summaries and submitted feedback.

Routine approval should occur in a product administration page such as:

/manage/access-requests/

It should not require unrestricted Django superuser access for every decision.

Account and identity contract

Use email as the verified contact and login identifier, with a separate mutable display name/nickname. Usernames must not be treated as proof of identity.

Approved accounts must start with:

is_staff = false
is_superuser = false

Recommended role:

Demo Researcher

or a similarly explicit least-privilege role mapped through the RBAC contract from #8.

Demo/sandbox isolation

Phase 1 access must be limited to synthetic/demo material and per-user sandbox objects.

Required invariants:

• demo users cannot see private patient-derived records;
• demo users cannot enumerate other users or sandboxes;
• each created patient/scenario/dataset belongs to the requesting user or their isolated sandbox;
• cross-user object access fails server-side even with guessed identifiers;
• demo records are visibly marked synthetic/user-provided;
• user-provided input is not interpreted as validated clinical data;
• uploads are disabled until an isolated, scanned and governed upload contract exists, or are limited to explicitly non-identifying synthetic files;
• export scope is sandbox-only;
• data retention and deletion are explicit.

Resource protection

Because the deployment uses owner-operated cluster resources, approval must carry enforceable limits.

At minimum:

maximum concurrent jobs per user
maximum queued jobs per user
simulation runs per hour/day
maximum simulation horizon/cohort size
maximum request/body/file size
job timeout
artifact retention period
account expiry

The user must receive a deterministic explanation when a quota is reached. Coordinate with #10.

Feedback workflow

Add an in-product feedback path:

/feedback/

Allow authenticated demo users to submit:

bug
feature request
scientific question
usability problem
data/model interpretation problem
other

Store page/feature context, application version and request ID where safe. Never attach private patient content automatically. Provide status and optional reply notification.

Notifications

Implement configurable notifications for:

• email verification;
• new verified access request to approvers;
• approval/rejection;
• activation link;
• upcoming expiry;
• suspension/revocation;
• feedback acknowledgement.

Do not leak whether an unverified or unrelated email already has an account.

Security and privacy

• CSRF protection, HTTPS and secure cookies are mandatory in production.
• Activation and reset links must be single-use, expiring and revocable.
• Add rate limits to request, login, verification, reset and feedback endpoints.
• Do not log raw tokens, passwords, full request bodies or clinical content.
• Add abuse controls without making IP address the sole identity signal.
• Preserve research-only intended-use language from [M0-R][GOVERNANCE] Establish canonical intended use and remove prescriptive legacy outputs #12.

Tests

Access lifecycle

• valid request → email verification → pending review;
• unverified request cannot be approved as active;
• approval creates/activates exactly one account;
• repeated callbacks and approvals are idempotent;
• rejected, expired and revoked users cannot authenticate;
• activation/reset token expiry and reuse fail closed;
• no account-enumeration differences in public responses.

Authorization

• anonymous user: public docs/request/login only;
• pending user: no protected product access;
• approved demo user: own synthetic sandbox only;
• unrelated demo user: no cross-user access;
• approver: request-management scope only;
• superuser: recovery/admin scope;
• direct URL/API/artifact IDOR tests pass.

Resource controls

• per-user quota enforcement;
• concurrency and timeout handling;
• alias routes cannot bypass limits;
• expiry/revocation terminates new access and invalidates sessions as defined.

Browser acceptance

Test the complete flow on desktop and mobile:

landing/docs
→ request access
→ verify
→ approve
→ activate
→ sign in
→ open demo dashboard
→ create/run a synthetic scenario
→ inspect output
→ submit feedback
→ sign out

Acceptance criteria

• Ordinary product login/logout exists independently of Django admin.
• A visitor can request access with verified email and display name/nickname.
• No account becomes active without explicit owner/approver approval.
• Approved users set their password through a one-time expiring activation flow.
• Demo users are non-staff, non-superuser and least-privilege.
• Demo use is isolated to synthetic/per-user sandbox data.
• Object-level authorization and negative IDOR tests pass.
• Quotas, concurrency limits, timeouts, expiry and revocation are enforced.
• An in-product feedback workflow is operational.
• Notifications are privacy-safe and tested.
• Public pages clearly explain the request/login path and research-only scope.
• Mobile and desktop end-to-end acceptance passes.
• GitHub documentation, Notion project state and Trello operational sequencing are reconciled.

Dependencies

#75 platform-owner bootstrap
#8 object authorization and RBAC
#9 production HTTPS/security profile
#10 resource quotas and cost controls
#16 centralized policy/service architecture
#21 privacy-safe audit and observability

The request/approval UI can be developed in parallel with parts of the security work, but multi-user production activation must remain blocked until the isolation, authorization and quota gates pass.

Non-goals

• unrestricted open signup;
• access to private real-patient datasets;
• clinical decision support;
• collection of identifiable medical records in the demo;
• using Django admin as the ordinary user portal;
• relying on local repository installation as the primary demo path.