The Login Wall — Multi-User Accounts

Why multi-user, and what it changes

You chose accounts over a single shared password, and that's a great call if more than one person will ever touch this — each gets their own streak, their own task list, their own practice grid. It's the same model as MedTrack in Part 2, where each user had their own meds. The structure: a users table, a login flow that sets $_SESSION['user_id'], and a user_id foreign key on every per-user table so queries can filter "just mine."

Here's the mental model for the whole thing: authentication is proving who you are (the login), and authorization is what you're allowed to see (filtering by user_id). This chapter does both. Get them right and the dashboard goes from "a webpage" to "an app with users."

The security non-negotiables

This is the one chapter where "good enough" isn't — auth bugs are how people get genuinely hurt. The rules from the Part 2 sessions chapter all apply, and they're worth repeating because each one prevents a specific, real attack:

🐍 Python brain: password_hash/password_verify are PHP's built-in equivalent of passlib's pwd_context.hash()/verify(). Both pick a strong algorithm for you (bcrypt) and support transparent upgrades. Same idea, no extra package needed.

The users table + a one-time registration

Reuse the MedTrack users table verbatim:

CREATE TABLE users (
    id            INT PRIMARY KEY AUTO_INCREMENT,
    email         VARCHAR(150) UNIQUE NOT NULL,
    name          VARCHAR(100) NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    role          VARCHAR(20)  NOT NULL DEFAULT 'user',
    created_at    DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP
);

I snuck in a role column — we'll use it next chapter to decide who's allowed to edit content. To make your own account, use a throwaway registration script exactly like the MedTrack one:

<?php
declare(strict_types=1);
require __DIR__ . '/lib/db.php';

$hash = password_hash('pick-a-strong-password', PASSWORD_DEFAULT);
$stmt = db()->prepare(
    "INSERT INTO users (email, name, password_hash, role) VALUES (?, ?, ?, 'admin')"
);
$stmt->execute(['you@example.com', 'Eric', $hash]);
echo "Created. NOW DELETE THIS FILE.";

The auth helpers

Put these in lib/auth.php — they're the MedTrack pattern, lightly adapted:

<?php
declare(strict_types=1);
require_once __DIR__ . '/db.php';

function require_login(): array {
    if (session_status() !== PHP_SESSION_ACTIVE) session_start();
    if (empty($_SESSION['user_id'])) {
        header('Location: login.php');
        exit;
    }
    return [
        'id'   => (int) $_SESSION['user_id'],
        'name' => $_SESSION['user_name'] ?? '',
        'role' => $_SESSION['user_role'] ?? 'user',
    ];
}

function attempt_login(string $email, string $pass): bool {
    $stmt = db()->prepare("SELECT * FROM users WHERE email = ?");
    $stmt->execute([$email]);
    $u = $stmt->fetch();
    if ($u && password_verify($pass, $u['password_hash'])) {
        session_regenerate_id(true);                 // prevent fixation
        $_SESSION['user_id']   = (int) $u['id'];
        $_SESSION['user_name'] = $u['name'];
        $_SESSION['user_role'] = $u['role'];
        return true;
    }
    return false;                                    // caller shows generic error
}

The login.php page is a form that calls attempt_login() and, on success, redirects into the dashboard; on failure it shows the single generic message. logout.php clears the session array, expires the cookie, and calls session_destroy() — all three, exactly like the Part 2 chapter drilled into you.

Gating the dashboard + scoping data per user

Two moves finish the job. First, lock the front door — at the very top of index.php, right after the requires:

require __DIR__ . '/lib/auth.php';
$me = require_login();          // bounces to login.php if not authed

Now every visit either has a logged-in $me or never gets past that line. Show $me['name'] and a logout link in the topbar so it feels personal (the greeting already says "Eric" — now it'll mean it).

Second, make the data theirs. Add a user_id column to progress, tasks, and practice_log (you pre-added it to progress in chapter 4's stretch goal — nice foresight):

ALTER TABLE tasks        ADD COLUMN user_id INT NOT NULL DEFAULT 1;
ALTER TABLE practice_log ADD COLUMN user_id INT NOT NULL DEFAULT 1;

Then thread $me['id'] through every query: include it in INSERTs, and add AND user_id = ? to SELECTs/UPDATEs/DELETEs. Miss one and you've got a bug where users see each other's data — so audit every query touching those tables. This is tedious but mechanical, and it's the difference between "multi-user" and "everyone shares one pile."