1. Information stored
Student E-page stores information needed to operate the features currently available. This can include:
- account name, email address, email-verification state, role and a password hash;
- service requests, school or institution details entered for a request, request status and activity history;
- messages attached to requests;
- uploaded supporting documents and completed documents delivered by an admin;
- service-fee snapshots, itemised quotes, quote responses, Paystack payment-attempt references/status metadata when enabled, and clearly labelled TEST payment records;
- notification and read/unread state;
- session, one-time email-verification/password-reset token hashes, and rate-limit records used for access control and abuse protection; and
- admin-managed schools, admission updates and deadlines.
The site should not be used to send card numbers, passwords, OTPs, verification codes or examination PINs in ordinary messages.
2. How information is used
Information is used to create and manage accounts, verify account email addresses, recover account access, process service requests, keep request communication together, enforce access rules, deliver files to the correct account, show request history, manage quotes, verify configured Paystack transactions, keep TEST records separate, and operate the admissions information system.
The current build does not contain advertising, behavioural advertising or third-party analytics code.
3. Who can access information
Students can access their own account-level information and requests. Authorised admin functions can access student requests, documents, payment records and request conversations so the service can be managed.
Public school, update and deadline pages expose only content intentionally published by an admin. Draft admission content stays private to the admin workspace.
5. Documents and file data
Uploaded files are stored in the private project database and are not served as public static files. The server checks the signed-in account and request permissions before allowing a download.
Current checks include file type, file size and request limits. A configured ClamAV scanner can inspect uploads before storage; production mode fails closed when scanning is unavailable and does not serve active documents that are not marked clean.
6. Retention and deletion
No automatic retention or deletion schedule is configured in this development build. Removed supporting documents are made unavailable through the application, but backups or earlier downloaded copies can still exist.
Self-service account deletion is not implemented. A defined retention schedule and deletion process are required before public launch.
7. Security measures and current limits
The project uses password hashing, server-side permission checks, CSRF checks for state-changing browser requests, input validation, upload restrictions, session expiry and rate limits. The private database folder is excluded from public static serving.
Production mode requires HTTPS reverse-proxy configuration and secure cookies. Verified database backup tooling and production HTTPS/session controls are included. Malware-scanning enforcement and authenticator-based admin MFA are now available. External deployment monitoring and final live-provider/device acceptance testing remain deployment requirements.
8. Your choices and questions
Only submit information that is necessary for the service you are requesting. You can remove supporting files where the current request rules allow it and can sign out to end the current browser session.
For questions about information attached to an active request, use the request conversation or the Contact page. Published support contact details appear on the Contact page when an admin configures them.
Read document help