feat(portal): add SSR operations and exclusive groups
This commit is contained in:
@@ -0,0 +1,34 @@
|
||||
# Accessibility review
|
||||
|
||||
Review date: 2026-08-01
|
||||
|
||||
## Scope
|
||||
|
||||
Player account management, administrator navigation, dashboard metrics and chart, user records, group management, event filtering, event details, forms, tables, and status notifications.
|
||||
|
||||
## Implemented checks and improvements
|
||||
|
||||
- Added a keyboard-visible “Skip to main content” link and consistent high-visibility `:focus-visible` outlines.
|
||||
- Darkened the accent color so accent text reaches at least 4.5:1 contrast on both canvas and panel backgrounds.
|
||||
- Preserved reduced-motion behavior and disabled decorative cursor animation when requested.
|
||||
- Added labels or accessible names to search, Minecraft username, settings, group, and event-filter controls.
|
||||
- Added `fieldset` and `legend` semantics to multi-select event-type filters.
|
||||
- Added table captions, column scopes, and row scopes to administrator data tables.
|
||||
- Added `role=status` with polite announcements for successful nickname changes and `role=alert` with assertive announcements for errors.
|
||||
- Added semantic `time` elements for audit and security activity timestamps.
|
||||
- Made event JSON keyboard-focusable so horizontally overflowing content can be reviewed without a pointer.
|
||||
- Added an accessible title, description, per-point labels, and textual values to the registration chart.
|
||||
- Added explicit new-tab context to the external Discord invite link.
|
||||
- Kept destructive account and group actions behind native keyboard-operable `details` confirmation disclosures.
|
||||
- Allowed administrator navigation to wrap at narrow viewport widths instead of overflowing.
|
||||
|
||||
## Validation
|
||||
|
||||
- ESLint with the Next.js ruleset passes.
|
||||
- Component rendering tests verify nickname status and error announcement roles and dismissal text.
|
||||
- The production build passes and reports database-backed player and administrator pages as dynamic server-rendered routes.
|
||||
- Color contrast was calculated for the canvas, panel, muted text, accent text, and signal combinations used by the interface.
|
||||
|
||||
## Follow-up
|
||||
|
||||
Authenticated browser automation is still recommended in CI with axe-core and a test Keycloak realm. It should cover keyboard order, zoom to 200%, reflow at 320 CSS pixels, and screen-reader announcements against a running production build.
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
### Web application
|
||||
|
||||
The Next.js application owns user onboarding, account management, admin configuration, server-side Minecraft profile validation, sessions, and the HTTP API used by Discord and Velocity integrations.
|
||||
The Next.js application owns user onboarding, account management, admin configuration and metrics, server-side Minecraft profile validation, sessions, and the HTTP API used by Discord and Velocity integrations. Database-backed portal and console pages are dynamic React Server Components: authentication, queries, filtering, and dashboard aggregation execute on the server and return rendered HTML.
|
||||
|
||||
User authentication begins with an opaque, short-lived, single-use token created for a Discord user. Only a cryptographic hash of the token is persisted. Admin authentication is a separate Keycloak OIDC flow and requires the `minecraft-account-manager-admin` role.
|
||||
|
||||
|
||||
@@ -24,8 +24,9 @@ Next.js portal and APIs, Discord bot, PostgreSQL persistence, Keycloak admin aut
|
||||
- Velocity credentials are high-entropy bearer tokens stored only as hashes.
|
||||
- Velocity requests have a 45-second clock window and database-unique request IDs for cross-instance replay prevention.
|
||||
- Velocity and its API fail closed.
|
||||
- Registered players require at least one enabled access group; the implicit `everyone` group starts disabled.
|
||||
- Group and membership mutations re-check the Keycloak administrator role server-side and are audited.
|
||||
- Registered players require an enabled effective group; explicit assignments replace rather than combine with the protected, disabled-by-default `everyone` fallback.
|
||||
- Group and membership mutations re-check the Keycloak administrator role server-side; destructive group deletion and its audit event commit atomically.
|
||||
- Event filters accept only event types already present in the ledger, and event detail routes remain role-protected.
|
||||
- ORM-parameterized queries are used throughout.
|
||||
- CSP, clickjacking, MIME-sniffing, referrer, and browser-permission headers are configured.
|
||||
- Forwarded IP headers are ignored unless `TRUST_PROXY=true` is explicitly configured.
|
||||
|
||||
Reference in New Issue
Block a user