Stage 6 · L28

Reload the current actor and reject inactive identity

Core · original Session 6

current_actor resolves a verified access token into current stored identity. It opens its own session, reads the UUID subject, rejects missing/inactive/version-changed users and returns a frozen Actor containing only id, email and current role. The session closes before that value reaches another service or an async provider call.

Current state matters after issuance. The baseline deactivates an account in a separate transaction while keeping the same token, then verifies that /auth/me returns401. Stage07 changes a stored role and confirms the same token loses write permission. A role copied into a long-lived JWT would otherwise continue granting stale authority.

Rental creation now receives equipment_id and quantity only. The router inserts actor.id into the internal RentalIn. A caller-supplied owner_id is an extra field and rejected. This removes a client-controlled owner boundary; the authenticated actor is still not sufficient for reading or changing every existing rental, which stage07 scopes.

/auth/me exposes id/email/role, never password hash, credential version, action tokens or private mailbox data. User is an ORM row with persistence responsibilities; Actor is a plain trusted identity value. Passing a session-bound User object across a background or await boundary can trigger accidental lazy I/O and muddle ownership.

Tests must patch the session factory where current_actor uses it: equipment.api.SessionLocal, imported inside the function. Patching a similarly named symbol in an unused module gives false confidence. The provider-stage fixture observes this actual factory and proves both authentication and preparation sessions close before outbound HTTP begins.

The stage-end reset capstone combines already-taught trust and transaction boundaries: validate the reset-purpose token, lock its current user row, require the expected stored credential version, replace the password hash and advance that version in one transaction. A used reset token and earlier access token then have stale versions. Complete reset_password before running its reset walkthrough; an untouched starter deliberately returns501 exercise_pending. The focused actor walkthrough above works before this implementation.

python run_checks.py --stage 06 --role starter --walkthrough actor
# Fresh synthetic registration/verification/login.
# GET /auth/me → 200; disable that local user → 401; restore → 200.

python run_checks.py --stage 06 --role starter --walkthrough actor

A correctly signed access token returns the current account only while its stored active/version checks pass. The owned walkthrough temporarily disables only its newly created synthetic user, observes401, restores active state and observes200 again. No reset implementation is required for this focused actor exercise. Implement and test credential reset separately in the stage capstone.

python run_checks.py --stage 06 --role starter --prepare
python run_checks.py --stage 06 --role starter
python run_checks.py --stage 06 --role starter --transfer

python run_checks.py --stage 06 --role starter --walkthrough reset

python run_checks.py --stage 06 --role solution --transfer
python run_checks.py --stage 06 --role solution --walkthrough reset

def reset_password(session, payload):
    claims = action_claims(payload.token.get_secret_value(), "reset")
    with session.begin():
        user = session.scalar(select(User).where(User.id == UUID(claims["sub"])).with_for_update())
        if user is None or not user.active or user.credential_version != claims["cv"]:
            raise DomainError(400, "invalid_action_token", "Action token is invalid or expired")
        user.password_hash = PASSWORDS.hash(payload.new_password.get_secret_value())
        user.credential_version += 1
    return {"reset": True}