Technical requirements

1. Platform and components

Component	Baseline	Current use
Server runtime	PHP 8.1 or later	Server-rendered PHP pages, session handling, and JSON endpoints.
Database access	PDO with the MySQL driver	Prepared statements and exception-mode errors.
Database server	MySQL or XAMPP MariaDB; use a currently supported release compatible with the schema.	Relational persistence for users, sessions, login attempts, audit entries, records, transactions, and notifications.
Browser	Modern browser with HTML, CSS, and JavaScript support	Responsive interface and dashboard data visualization without a client framework.
Local development	XAMPP Apache and MySQL/MariaDB, or PHP's built-in development server	The built-in PHP server is for local preview and is not a production web server.

2. Application architecture

Pages: PHP renders the public site, authentication, profile, dashboard, and administrator views. Shared initialization, authentication, escaping, URL, and page-shell helpers reside in app/bootstrap.php.
API: Dashboard JSON endpoints are grouped under api/dashboard/. They authenticate from the server session, return JSON with private/no-store caching headers, and expose generic errors to clients.
Browser code: assets/dashboard.js loads dashboard regions, handles loading and error states, refreshes data, and renders charts as SVG.
Authorization: The implemented roles are administrator and standard_user. Each protected page and endpoint must enforce access on the server; interface visibility alone is not authorization.
URL generation: Use the shared app_url() helper for PHP-rendered links so deployments below a web-root subdirectory can be supported.

Document request processing, staff-specific roles, payment verification, and notification producers are not complete in the current application. New endpoints for these workflows require explicit server-side permission and data-scope checks.

3. Data and database requirements

Import database/schema.sql to create the easyreg database and its tables.
Use InnoDB, utf8mb4, foreign keys, and database uniqueness constraints as defined by the schema.
Persist timestamps in UTC. The application sets UTC as its PHP timezone; dashboard date ranges are also calculated in UTC.
Store password hashes only. Store session identifiers as SHA-256 hashes in the session table; never store raw session IDs there.
Store monetary amounts in integer minor units with an ISO currency code. The current schema defaults the currency code to PHP; fee policy and transaction workflow still need definition.
Keep the database connection private to the application. Use PDO prepared statements and a least-privilege database account in production.
Retain audit records and personal data only under an institution-approved retention and deletion policy.

4. Security requirements

Control	Technical requirement	Baseline status
Password handling	Hash with PHP password APIs; never log or display plaintext passwords.	Implemented using password hashing and verification.
Sessions	Cookie-only IDs, strict session mode, HttpOnly and SameSite=Lax cookies, session revocation, 30-minute idle timeout, and 8-hour absolute lifetime. Require HTTPS and Secure cookies in production.	Session controls and timeouts implemented; Secure cookie depends on HTTPS.
CSRF and output encoding	Verify CSRF tokens on state-changing browser requests and HTML-escape untrusted output.	Shared CSRF helpers and HTML escaping are implemented.
Authorization	Check role and object ownership on every server request. Scope standard-user data queries to the authenticated user.	Administrator and standard-user checks exist; future request workflows need their own authorization rules.
Abuse prevention	Verify CAPTCHA server-side and apply request/login throttling. Do not treat CAPTCHA as a replacement for rate limits.	Local arithmetic CAPTCHA and account/IP attempt tracking exist; production must configure Turnstile as described in deployment notes.
Secrets and errors	Keep application keys, database credentials, and provider secrets out of source control and public web paths. Hide detailed errors from production users; log sanitized diagnostics server-side.	Production requires `EASYREG_APP_KEY`; production error display is disabled by environment setting.

5. Configuration and deployment

Configuration inputs

Setting	Purpose	Production requirement
`EASYREG_ENV`	Runtime environment; defaults to development.	Set to `production` to suppress displayed PHP errors and require an explicit application key.
`EASYREG_APP_KEY`	Application-held key used for privacy-preserving fingerprints and related secret operations.	Configure a strong private value of at least 32 characters outside source control.
`EASYREG_DB_HOST`, `EASYREG_DB_NAME`, `EASYREG_DB_USER`, `EASYREG_DB_PASS`	Database connection settings. Defaults are intended for local development.	Set explicit production values and a least-privilege database account; do not use XAMPP's default root account.
`EASYREG_BASE_URL`	Optional application base URL for deployments requiring an explicit path.	Set only to the correct deployment path and scheme when automatic path resolution is insufficient.
Turnstile settings	Provider site and secret keys and expected hostname for production CAPTCHA verification.	Configure privately for the production hostname; never commit provider secrets.

Deployment steps

Deploy behind a maintained web server with HTTPS enabled; keep configuration and secrets outside the public document root.
Provision a supported PHP runtime with PDO MySQL and required PHP extensions enabled.
Create the database, import database/schema.sql, and configure a least-privilege database user.
Configure the production environment key, database connection, Turnstile credentials, expected hostname, and correct base URL if needed.
Create the first administrator using the one-time CLI setup script. Do not ship a default administrator password.
Verify HTTPS, session cookie flags, access controls, CAPTCHA verification, logs, backups, and recovery before opening service to users.

XAMPP and the PHP built-in web server are local development options, not a production security boundary. Production operations and monitoring remain deployment responsibilities, not completed app features.

6. Operations and recovery

Backups: Back up the database and required private configuration using an approved protected process. Restrict backup access because it contains personal information and password hashes.
Restore: Test restoration periodically in a non-production environment. Agree on recovery-point and recovery-time objectives with the institution before production launch.
Monitoring: Monitor PHP/web-server and database availability, disk capacity, authentication failures, and backup completion without recording passwords, CAPTCHA tokens, session IDs, or secrets.
Updates: Keep PHP, database software, the web server, and any CAPTCHA integration on supported, patched releases.
Failure behavior: Return generic errors to users, preserve working dashboard regions when a separate region fails, and distinguish zero, unavailable, stale, and error states.

Automated backup restoration, monitoring integrations, defined retention, and service-level objectives are not currently documented as implemented application capabilities.

7. Verification and readiness

Before a production release, verify at minimum:

PHP syntax checks pass for changed PHP files, and the schema imports cleanly into the supported database version.
Registration, login, logout, session expiry, profile updates, and administrator account actions work as authorized.
Unauthenticated requests are redirected or rejected; standard users cannot read administrator-only data or another user's records through altered URLs or API parameters.
CSRF failures are rejected, user-controlled content is safely encoded, SQL values are parameterized, and API responses do not leak internal exception details.
Dashboard endpoints return appropriate JSON content types and no-store cache headers, including on error responses.
Responsive pages remain usable by keyboard and screen readers; loading, empty, unavailable, and error states remain distinguishable.
Production HTTPS and cookie settings, application secrets, CAPTCHA configuration, database privileges, and backup restoration are tested in the deployment environment.

This document records technical requirements and the observed source baseline. It is not a claim that every production-readiness item has been independently tested or deployed.

8. Implementation gaps and constraints

The implemented account roles are Administrator and Standard User; distinct Student, Registrar, and Cashier role policies are not available.
Document request submission, fee calculation, cashier payment verification, registrar processing, record fulfillment, and notification delivery remain incomplete workflows.
The current development default database credentials must be replaced with private deployment configuration before production use.
Production server topology, supported browser matrix, monitoring provider, backup schedule, retention policy, and recovery objectives require operator and institutional decisions.
Compatibility should be confirmed against the actual selected PHP and MySQL/MariaDB release; this codebase does not declare a dependency lockfile or automated deployment pipeline.