Add approved viewer registration

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

erik/slugkit#171

erik commented

2026-06-20 09:04:39 -05:00

Owner

Goal

Add open registration for viewer access, with email verification and explicit admin approval before a user becomes active.

Requirements

Public registration must create a pending site user, not an active viewer.
Registration must require email verification before the request can be approved.
Pending users must not receive settings, admin, or API access while awaiting approval.
Pending users may only see a clear pending-approval status after signing in or following verification.
Admins must be able to approve or reject pending registration requests from the Site users/settings area.
Approval must activate the user with the viewer role.
Rejection must keep the user unable to sign in or access viewer-only resources.
Viewers must be treated as untrusted internet users.
Viewer access must be limited to explicitly safe read-only resources.
Viewers must not access Site users, ActivityPub admin, site config, audit/security information, drafts, private metadata, or write operations.
API keys must not be created automatically during registration or approval.
Viewer-created API keys must be scoped only to viewer-safe GET endpoints.
Registration and magic-link/verification flows must be rate-limited to reduce abuse.
Registration and login flows must avoid revealing whether an email address already exists.
Deactivated, rejected, or unverified users must be unable to authenticate into protected areas.
Add tests for pending, approved, rejected, inactive, and viewer authorization paths.
Document the registration and approval model.

Acceptance criteria

A new public registration flow accepts an email address and creates a pending site user.
Registration sends or records an email verification step before admin approval is possible.
Pending users cannot access settings/admin pages, protected APIs, or viewer-only resources.
Pending users see a pending-approval status instead of protected content.
Admins can view pending registrations in the Site users/settings area.
Admins can approve a pending user, activating them with the viewer role.
Admins can reject a pending user, keeping them unable to authenticate into protected areas.
Approved viewers can access only explicitly allowed viewer-safe read-only resources.
Viewers are denied access to Site users, ActivityPub admin, site config, audit/security data, drafts, private metadata, and write operations.
Registration and verification requests are rate-limited.
Registration/login responses do not disclose whether an email already exists.
No API key is automatically created for a registered or approved viewer.
Viewer API keys, if created later by the viewer, are restricted to safe GET endpoints.
Tests cover pending approval, approval, rejection, inactive users, viewer access, and viewer denial cases.
Documentation explains the pending-registration, email-verification, approval, and viewer-access model.

task-cdb4c12b

## Goal Add open registration for viewer access, with email verification and explicit admin approval before a user becomes active. ## Requirements - Public registration must create a pending site user, not an active viewer. - Registration must require email verification before the request can be approved. - Pending users must not receive settings, admin, or API access while awaiting approval. - Pending users may only see a clear pending-approval status after signing in or following verification. - Admins must be able to approve or reject pending registration requests from the Site users/settings area. - Approval must activate the user with the `viewer` role. - Rejection must keep the user unable to sign in or access viewer-only resources. - Viewers must be treated as untrusted internet users. - Viewer access must be limited to explicitly safe read-only resources. - Viewers must not access Site users, ActivityPub admin, site config, audit/security information, drafts, private metadata, or write operations. - API keys must not be created automatically during registration or approval. - Viewer-created API keys must be scoped only to viewer-safe `GET` endpoints. - Registration and magic-link/verification flows must be rate-limited to reduce abuse. - Registration and login flows must avoid revealing whether an email address already exists. - Deactivated, rejected, or unverified users must be unable to authenticate into protected areas. - Add tests for pending, approved, rejected, inactive, and viewer authorization paths. - Document the registration and approval model. ## Acceptance criteria - [ ] A new public registration flow accepts an email address and creates a pending site user. - [ ] Registration sends or records an email verification step before admin approval is possible. - [ ] Pending users cannot access settings/admin pages, protected APIs, or viewer-only resources. - [ ] Pending users see a pending-approval status instead of protected content. - [ ] Admins can view pending registrations in the Site users/settings area. - [ ] Admins can approve a pending user, activating them with the `viewer` role. - [ ] Admins can reject a pending user, keeping them unable to authenticate into protected areas. - [ ] Approved viewers can access only explicitly allowed viewer-safe read-only resources. - [ ] Viewers are denied access to Site users, ActivityPub admin, site config, audit/security data, drafts, private metadata, and write operations. - [ ] Registration and verification requests are rate-limited. - [ ] Registration/login responses do not disclose whether an email already exists. - [ ] No API key is automatically created for a registered or approved viewer. - [ ] Viewer API keys, if created later by the viewer, are restricted to safe `GET` endpoints. - [ ] Tests cover pending approval, approval, rejection, inactive users, viewer access, and viewer denial cases. - [ ] Documentation explains the pending-registration, email-verification, approval, and viewer-access model. ## Dependencies - task-cdb4c12b

erik added the

labels

Rows
Columns

Add approved viewer registration #171

Goal

Requirements

Acceptance criteria

Dependencies