Semester 5 Coursework — Web Programming
Project: HostelManager — Student Dorm Booking System
Overview. Build a production-like web application that allows students to browse, book, and manage
dorm rooms, and admins to manage inventory and allocations. This coursework mirrors the depth of
a typical QMUL S5 Web Programming module: you will design the database schema, implement a
secure PHP back end, and a standards-compliant front end with progressive enhancement. No
frameworks are required; focus on correctness, security, and clean code.
Learning Outcomes
1 Design a relational schema and implement it in MySQL with appropriate constraints and indexes.
2 Implement secure session-based authentication and role-based authorization in PHP.
3 Develop REST-like endpoints with input validation and prepared statements.
4 Implement a responsive UI with accessible, semantic HTML and unobtrusive JavaScript.
5 Apply secure coding practices (password hashing, CSRF protection, output escaping).
6 Demonstrate logging, error handling, and simple load/performance testing.
Stack Constraints
Server-side: PHP 8.x (no full-stack frameworks), PDO MySQL, Composer allowed for small libs (e.g.,
PHPMailer).
Database: MySQL 8.x.
Client-side: Vanilla JS (ES6+), HTML5, CSS. You may use a small CSS framework (e.g.,
Pico/[Link]) but not JS UI frameworks.
Runtime: App must run locally with php -S localhost:8000 -t public and a [Link] to create the DB.
Core Functional Requirements
• R1 Accounts & Roles: Student and Admin roles. Registration with email verification (stub
acceptable), login/logout, password reset.
• R2 Rooms & Halls: CRUD for halls, rooms, room types (capacity, price/night, amenities).
Admin-only.
• R3 Booking: Students can search availability, create a booking (dates, occupants), view/cancel
bookings; admins approve/reject and can reassign.
• R4 Payments (Mock): Record a mock payment intent and status (no gateway needed).
• R5 Notifications: Email-like notifications (store in DB) on booking status changes.
• R6 Audit Log: Append-only table for critical actions (login, create booking, update inventory).
Non-Functional Requirements
• Use prepared statements and parameterized queries only.
• Hash passwords with password_hash() (default Argon2id or bcrypt).
• Protect against CSRF for all POST/PUT/DELETE actions (token per session).
• Escape all user-generated content on output (e.g., htmlspecialchars).
• Implement server-side validation for all inputs (length, type, ranges).
• Provide an [Link] with setup steps and test users.
Data Model (Minimum)
Table Key Columns
users id PK, email UNIQUE, password_hash, role ENUM('student','admin'), created_at
halls id PK, name, address
rooms id PK, hall_id FK, name, type, capacity, price_per_night, amenities JSON
bookings id PK, user_id FK, room_id FK, start_date, end_date, status ENUM('pending','approved','
payments id PK, booking_id FK, amount, status ENUM('initiated','recorded','failed')
notifications id PK, user_id FK, title, body, is_read, created_at
audit_log id PK, user_id FK NULL, action, details JSON, created_at
password_resets id PK, user_id FK, token, expires_at
API Endpoints (Suggested)
POST /api/auth/register, POST /api/auth/login, POST /api/auth/logout
GET /api/rooms?hall=&type;=&start;=&end;= — search availability
POST /api/bookings, GET /api/bookings/mine, PATCH /api/bookings/:id
GET/POST /api/admin/rooms, GET/POST /api/admin/halls — admin only
POST /api/payments/mock — mark payment status
All state-changing endpoints require CSRF token validation and session check.
Assessment & Marking (100%)
Criterion Weight Details
Correctness & Features 40% Implements R1–R6; search & availability logic; robust bookin
Security 20% Passwords hashed, CSRF, validation, escaping, session ha
Code Quality 15% Structure, readability, comments, no duplicate logic, error ha
DB Design & Performance 10% Keys, indexes, constraints; explain ANALYZE for 1–2 querie
UX & Accessibility 10% Semantic HTML, keyboard navigable, basic responsive layo
Documentation & Tests 5% [Link], ER diagram (image), 6+ API tests (curl or PHP
Deliverables
Submit a single ZIP named hostelmanager_studentID.zip containing:
1) public/ (entrypoint [Link]), src/, vendor/ (if any), [Link], [Link]
2) [Link] with setup steps and two test accounts (student/admin).
3) [Link] and a short [Link] (500–800 words).
4) A tests/ folder with API test scripts (curl or PHPUnit).
5) A [Link] (max 6 pages) describing design choices, security controls, and known limitations.
Submission & Deadlines (Example)
Recommended timeline (you may adjust for your study plan):
• Week 1–2: Schema, auth, basic CRUD • Week 3–4: Availability & booking • Week 5: Security hardening & tests •
Week 6: Polish & report.
Academic Integrity
This brief is for practice only and not affiliated with QMUL. Do not submit this as university coursework. Clearly
attribute any external libraries or code snippets you use.