Loading challenges
Nobody has started this yet — be first.
Business impact
TOTP_VALID_WINDOW exists specifically to tolerate small clock drift between a user's phone and the server, and the couple of seconds it takes a human to read a 6-digit code and type it in before it rotates. The direction that matters most in practice is "the code the user is looking at is about to roll over to the next one" -- the +1 step. Users whose phone clock runs even slightly fast, or who are a beat slow entering a code near a 30-second boundary, get a confusing, intermittent "invalid code" on a security-critical login path.
Problem
verify_totp_code() loops for offset in range(-window, window):. For TOTP_VALID_WINDOW=1, range(-1, 1) produces [-1, 0] -- the +1 offset, the furthest-future step the window is supposed to cover, is never checked at all.
Current behavior
A code generated one step (30s) in the future, which TOTP_VALID_WINDOW=1 says should be accepted, is rejected with 401 "invalid code."
Expected behavior
With TOTP_VALID_WINDOW=N, codes for steps -N through +N inclusive (relative to the current step) are all accepted, subject to replay prevention (a separate, already-correct mechanism).
Steps to reproduce
Why this matters
range(-window, window) vs range(-window, window + 1) is a classic "off-by-one on a symmetric range" mistake -- it is easy to write the lower bound correctly while getting the upper bound's inclusivity wrong, especially since Python's range() stop argument being exclusive is exactly the kind of detail that is easy to forget when reasoning about a -N..+N window in the abstract.
Suggested approach
Work out, for window=1, exactly which offsets range(-window, window) produces, and compare that against what "a window of +/-1 step" should mean. Check the other direction too (is -window itself included correctly?) to make sure the fix does not just move the bug to the other edge.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_07.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
Sign in to create it automatically, or do it yourself:
$git checkout -b fix/totp-window-edgeFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/totp-window-edgeSubmit it below
Paste your fork URL and the branch name, with a short write-up of the root cause.
Questions
Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.
Sign in to ask a question or reply.
Sign inhttp://localhost:5000make seedpyotpmake docker-prod-upYou do not need Docker running at all to work the tickets -- the test suite uses an in-memory SQLite database (via StaticPool, an isolated DB per test function) and fakeredis (TestingConfig.USE_FAKE_REDIS), so everything runs against a plain virtualenv:
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
pytest practice_tickets/tests/test_ticket_01.py -v # a single ticket
./practice_tickets/run_tickets.sh # all 15, clean pass/fail summary
All 15 tests fail at the start; as you fix each ticket in app/, its test (and only its test) should flip to passing. make test (pytest -q) runs the project's own main suite -- as of writing it shows 9 pre-existing failures caused by ticket bugs 02, 03, 07, 11, and 15; fixing those tickets fixes those failures too, not a separate task. Do not look at git diff / version control history to find the bugs if this repo is ever put under source control -- the point is to find them the way you would find a real bug: from a failing test and a description of broken behavior, not a diff.
Level 1
Fix a bug
Read existing behaviour, correct it.