Module 13: JWT Auth Front-End, Playwright E2E Tests

Summary

Builds on Module 12's JWT authentication API by adding real front-end pages for login and registration, connecting them to the existing /auth/register and /auth/login endpoints, and adding genuine Playwright browser-automation E2E tests covering both successful and failing auth flows. CI/CD continues to run tests, scan for vulnerabilities, and deploy to Docker Hub on success.

What Was Added

1. Front-End Pages (templates/)

• login.html — username/password form. Client-side checks are minimal (non-empty fields only), consistent with the idea that login doesn't need to validate password strength, just that credentials were entered. On success, stores the access/refresh tokens in localStorage and redirects.
• register.html — username, email, first/last name, password, and confirm-password fields. Client-side validation includes:
  • Email format (regex)
  • Password length (≥8 characters) and complexity (uppercase, lowercase, digit) — mirrors the server-side PasswordMixin rules from Module 12
  • Live password-match checking as the user types
  • On success, redirects to /login rather than showing an in-page success message

2. Playwright E2E Tests (tests/e2e/test_auth_e2e.py)

Real browser-automation tests (not just HTTP requests) driving the actual login.html/register.html forms:

• Positive:
  • test_register_valid_data_shows_success — registers with valid data, confirms redirect to /login
  • test_login_valid_credentials_shows_success — registers, then logs in, confirms the success message and a real access token in localStorage
• Negative:
  • test_register_short_password_shows_error — confirms the front-end validation catches a short password before the request ever reaches the server
  • test_login_wrong_password_shows_error — confirms a 401 from the server surfaces as a visible "invalid credentials" message in the UI

A helper (wait_for_alert_or_fail_with_reason) reports which alert (success/error) actually appeared, or the current page state, if a test fails — making future failures self-diagnosing rather than a bare timeout.

Key Design Patterns Demonstrated

1. Client-side + server-side validation layering — client-side checks (instant feedback) mirror but don't replace server-side Pydantic validation (the actual security boundary)
2. Factory Pattern — Calculation.create(), carried over from Module 11
3. Dependency Injection — get_db(), get_current_user(), get_current_active_user()
4. In-process vs. subprocess testing — schema unit tests, requests-based API tests, and Playwright browser tests each verify a different layer of the same auth flow

Module Alignment

• ✅ JWT login/registration routes
• ✅ Front-end pages with client-side validation
• ✅ Playwright E2E tests, positive and negative scenarios
• ✅ CI/CD: test → security scan → deploy to Docker Hub

Requirements

• Python 3.12
• Docker and Docker Compose

Setting Up the Development Environment

git clone git@github.com:enp23/assignment13.git
cd assignment13
python3.12 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
docker compose up -d --build

Running Tests

pytest                          # full suite
pytest tests/e2e/ -v            # Playwright + subprocess-based E2E tests only
pytest --cov=app --cov-report=term-missing   # with coverage detail

E2E tests run against a dedicated test database (fastapi_test_db), kept separate from fastapi_db via TEST_DATABASE_URL, passed explicitly to the subprocess test server.

API Docs

http://localhost:8000/docs

Front-End Pages

http://localhost:8000/login http://localhost:8000/register

Docker Hub

https://hub.docker.com/repository/docker/en23/assignment13/