Chapter 2: Literature and Technology Review

2.1 Related Systems

Existing educational platforms handle access control in various ways, but few offer administrator-configurable permission bundles:

2.2 Technology Stack

2.2.1 Flask

Flask was selected for its minimal, unopinionated design, allowing the project to be structured into clear layers (routes, services, and repositories). This architecture keeps components loosely coupled, enabling the authorization module (Section 3.7) to be tested independently of web routing or database details.

2.2.2 PostgreSQL

PostgreSQL serves as the primary database due to its support for relational constraints, composite keys in association tables, and custom CHECK constraints. These features let us enforce key data rules—such as valid exam statuses and positive question point values—directly at the database level rather than depending entirely on application code.

2.2.3 Bcrypt

Bcrypt handles password hashing using a salted, key-stretching design that resists brute-force attacks. While slower than basic hashing algorithms, it provides appropriate security for authentication without affecting overall system responsiveness.

2.3 Object-Oriented Programming Concepts Applied

• Encapsulation: domain logic resides within model objects—for instance, Exam.publish() verifies that an exam is in draft state and contains at least one question before publishing, rather than relying on caller checks.

• Composition over inheritance: permissions are linked via object composition rather than deep role hierarchies—a Role combines individual Permission objects directly or aggregates them through PermissionBundle instances (Section 3.5).

• Polymorphism (Strategy Pattern): grading logic uses a QuestionGrader interface with distinct implementations for single-choice, true/false, and multiple-choice questions. A GraderFactory selects the appropriate grader at runtime, allowing new question types without modifying existing grading code.

• Layered architecture: web routes manage HTTP requests, services handle business rules, and repositories encapsulate database queries, as shown in Figure 3.4.

Chapter 3: System Analysis and Design

3.1 Requirements

3.2 User Stories

3.3 Use Cases

3.4 Entity-Relationship Diagram

The database schema is fully normalized. The access-control layer uses four association tables (user_roles, role_permissions, bundle_permissions, and role_bundles) to allow roles to gather permissions through direct assignment or bundle inheritance. The testing domain (subjects, exams, questions, choices, attempts, and answers) is similarly structured, using CHECK constraints to enforce valid status values, positive timer values, and non-negative scores directly in the database.

Figure 3.1: Entity-Relationship Diagram

3.5 Class Diagram — Composed RBAC

Figure 3.2 details the core access-control design. AuthorizationService.get_user_permissions() calculates a user's active permissions by combining two paths: direct grants (Role → Permission via role_permissions) and bundle grants (Role → PermissionBundle → Permission via role_bundles and bundle_permissions). Roles can use either path or combine both as needed.

Figure 3.2: Composed RBAC Class Diagram

3.6 Class Diagram — Examination Domain

The grading subsystem uses the Strategy and Factory design patterns. Each supported question format (single choice, true/false, multiple choice) implements a shared QuestionGrader interface, retrieved dynamically via GraderFactory. This structure simplifies extending the platform with new question types without altering existing grading routines.

Figure 3.3: Examination Domain and Grading Strategy Class Diagram

3.7 System Architecture

The application uses a standard layered layout where components only interact with the layer directly below them. Routes delegate logic to services, and services use repositories for data access. This structure keeps AuthorizationService independent of HTTP contexts, making unit testing straightforward.

Figure 3.4: Layered System Architecture

Chapter 4: Implementation

4.1 Package Structure

The codebase follows the layered architecture described in Section 3.7. Templates are further split by role (admin, teacher, student) to keep each portal's presentation logic isolated.

4.2 Key Classes, Services, and Repositories

Table 4.1 summarizes the primary service and repository classes referenced in the class diagrams of Section 3.5 and 3.6. Full method-level detail is provided in Appendix A.

4.3 Interface Screenshots

4.3.1 Administrator Portal

The administrator portal provides full lifecycle management for permissions, roles, and permission bundles, directly exercising the Composed RBAC design from Chapter 3.

Figure 4.1: Permission Registry (create, edit, guarded delete)

Figure 4.2: Role Management (direct permissions and attached bundles)

Figure 4.3: Permission Bundles (composed capability groups)

4.3.2 Teacher Portal

The teacher dashboard presents authored-exam KPIs and candidate performance analytics, backed by TeacherDashboardService.

Figure 4.4: Instructor Dashboard

4.3.3 Student Portal

The student portal lists available examinations (filtered by AuthorizationService independent business rules: publication status, attempt window, and remaining attempts) and presents results and progress analytics.

Figure 4.5: Available Examinations

Figure 4.6: My Results Dashboard

Chapter 5: Testing and Results

5.1 Testing Strategy

System testing combined three approaches: (1) automated unit and integration tests using Python's unittest module to check business logic and endpoint permissions; (2) manual browser checks on a local development server to test template rendering and CSRF protection (which are disabled during automated test runs); and (3) exploratory testing across user roles to uncover edge cases missed by automated scripts (Section 5.4).

The test suite grew iteratively alongside defect discovery rather than being written upfront and left static, as shown in Table 5.1.

5.2 Notable Defects Identified and Resolved

The following examples illustrate the testing and debugging process. Each issue was investigated to determine the root cause, resolved in code, and followed by a regression test to prevent recurrence.

Defect 1: Alpine.js Component Crash from Unescaped JSON in an HTML Attribute

Defect 2: Boolean Identity Check Failing on Integer-Valued Fields

Defect 3: Implicit Role Inference via Unrelated Permission Checks

Defect 4: Missing CSRF Token on Dynamically Added Delete Forms

Defect 5: False-Positive Failure from Confirmation Dialog Behavior

5.3 Security and Access-Control Verification

In addition to functional testing, the authorization layer underwent unauthorized access testing to verify endpoint protections directly. Since hiding UI elements is insufficient for security, these tests sent direct HTTP requests to verify that backend endpoints properly block unauthorized actions regardless of client interface controls.

5.4 Discussion: Limitations of Automated Testing Observed in This Project

Development highlighted two important testing observations. First, automated suites can pass completely while user-facing bugs remain present (as seen in Defects 1 and 4). These gaps stemmed from test environment settings, such as checking response status codes instead of page content or disabling CSRF validation in test runs. To address this, later test updates focused on rendered output assertions and CSRF-enabled integration runs. Second, Defect 5 showed that perceived bugs can sometimes stem from unexpected user interaction behavior rather than application logic, proving the value of reproducing exact browser steps before modifying code.

5.5 Performance and Security Notes

• Password storage uses bcrypt with per-password salting; raw passwords are never logged or persisted.

• Login is rate-limited by email and client IP to mitigate brute-force credential attacks.

• All state-changing requests (POST) are protected by Flask-WTF CSRF tokens, verified across all three admin RBAC management views following Defect 4.

• Permission and role changes take effect on the very next request with no caching layer, eliminating a class of "stale privilege" bugs common in systems that cache authorization state in the session.

• Database-level CHECK constraints (e.g. on exam status, attempt count, and score ranges) provide a defense-in-depth layer independent of application-level validation.

5.6 Demonstration Summary

End-to-end functionality was verified across all three user roles on a live development instance. As Administrator, custom permissions, roles, and bundles were created, edited, and removed, while system-default entities remained protected against deletion. As Teacher, an examination was created, populated with questions, published, and evaluated via score reports. As Student, published tests were taken within time limits, with results accurately recorded on the student dashboard.

Chapter 6: Conclusion and Future Work

6.1 Summary

This project implemented a Composed RBAC authorization framework within an online examination system. The platform resolves user privileges by combining direct permission grants with reusable Permission Bundles, enforced through a normalized database schema and a centralized AuthorizationService. Endpoint testing confirmed server-side enforcement across all 14 system permissions, with boundary tests showing no unauthorized access leaks. The development process documented in Chapter 5 helped refine both application features and system security controls.