Add POST /auth/2fa/backup-codes/regenerate

Nobody has started this yet — be first.

Business impact

Right now, a user's only way to get a fresh set of backup codes is to fully disable and re-enable 2FA -- a clunky, alarming flow. Support gets tickets from users who have used most of their codes, or suspect one leaked, and want to rotate them without touching whether 2FA is on at all. This is a standard capability in any product with recovery codes (GitHub, Google, etc. all offer "regenerate codes" as a first-class action).

Problem

The route POST /auth/2fa/backup-codes/regenerate is registered and reachable, but is a placeholder that always returns {"error": "not implemented"}, 501 regardless of the caller.

Current behavior

regenerate_backup_codes()'s handler body is just return jsonify(error="not implemented"), 501 -- it never touches the database or totp_lib at all.

Expected behavior

An authenticated user with 2FA already enabled can call this endpoint to invalidate every existing backup code and receive a brand new set, shown once in the response body -- without touching totp_enabled or totp_secret at all.

Steps to reproduce

Enable 2FA for a user.
POST /auth/2fa/backup-codes/regenerate with a valid access token.
Observe: 501 {"error": "not implemented"}, regardless of the request.

Why this matters

This is a good exercise in reusing an existing building block (generate_backup_codes) correctly, and in getting the ordering right: the old codes must be gone from the database before (or atomically with) the new ones being issued, not just "new ones added alongside the old."

Suggested approach

Look at how confirm_2fa() calls totp_lib.generate_backup_codes() after 2FA is proven. This route needs the same call, but preceded by deleting the user's existing BackupCode rows (the same query shape disable_2fa() used to use -- see the disable-2fa ticket, a related but distinct gap in the same area of the code).

Acceptance criteria

POST /auth/2fa/backup-codes/regenerate requires a valid access token and that the user has totp_enabled=True
It returns a fresh set of BACKUP_CODES_COUNT codes in the response body
Every previously-issued backup code for that user stops working
Every newly-issued code works exactly once

Verification

pytest practice_tickets/tests/test_ticket_05.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b feat/regenerate-backup-codes

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin feat/regenerate-backup-codes

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Production-Style Flask Auth Service

A from-scratch Flask authentication service: JWT access + refresh tokens with rotation and reuse detection, real session/device revocation, password reset, email verification, and TOTP 2FA with backup codes.

Fork on GitHub

Download

Setup

Production-Style Flask Auth Service

git clone <your-fork>
cd FlaskDevTraining/flask_auth_service
cp .env.example .env
make docker-up   # docker compose up --build: Postgres + Redis + Flask dev server

Migrations run automatically on container start. The app is reachable at . Seed two demo users (one plain, one with 2FA already enabled) with -- it prints the 2FA user's TOTP secret, provisioning URI, and a one-liner to compute a current code with , so the 2FA flow is fully testable without an authenticator app. A production-style path with gunicorn (no dev server, no bind mount) is available via .