Loading challenges
Nobody has started this yet — be first.
Business impact
Any real client -- a mobile app, a SPA, even a curl script a support engineer runs to check "which account does this token belong to" -- has no way to re-derive "who is logged in" from a token alone. Today the only way to know is to have kept the full register/login response cached since the moment of login, which doesn't survive a page refresh, an app restart, or a token obtained any other way (e.g. a stored refresh token exchanged for a new access token via /refresh, which doesn't return a user object at all). This blocks the most basic "my account" screen a client would want to build, and there's no server-side way for a client -- or a support engineer -- to sanity-check which account a given token maps to.
Problem
auth_bp only exposes POST /register, POST /login, and POST /refresh. All three return a user object, but only as a side-effect of registering or logging in. There is no endpoint that answers "who am I, right now, given this access token" -- the one thing every authenticated client eventually needs.
Current behavior
There is no GET /api/auth/me route at all -- calling it returns a plain 404, not an authentication failure and not a profile.
Expected behavior
GET /api/auth/me, guarded by @jwt_required(), should return the current user's profile (id, email, created_at -- the same shape already produced by UserSchema, the one used under the "user" key in register/login responses) for whoever the access token identifies.
Steps to reproduce
cd flask/movie_watchlist .venv/bin/python -m pytest practicetickets/test_ticket03_me_endpoint.py -v
Why this matters
auth_bp's other three routes each build their response by calling user_schema.dump(user) after either creating or authenticating a user -- there's no route that does the equivalent for a request that already carries a valid access token. movies/service.py's get_owned_movie_or_404() already shows the pattern for resolving "who is making this request" via get_jwt_identity() inside a JWT-guarded view; /me needs the exact same identity resolution, just without an owned resource attached to it.
Suggested approach
Look at how register() and login() build their user_schema.dump(user) response, and how app/blueprints/movies/service.py:get_owned_movie_or_404() resolves "who is making this request" via get_jwt_identity(). This ticket is those two ideas combined into one new, small view function -- resolve the current user from the JWT identity the same way the movies blueprint already resolves the current user for ownership checks, then reuse the existing user_schema to serialize it. Decide what should happen if the identity in a valid token no longer corresponds to any user (compare against how app/init.py's user_lookup_error_loader already handles that same scenario for @jwt_required() routes in general).
Acceptance criteria
Verification
cd flask/movie_watchlist && .venv/bin/python -m pytest practicetickets/test_ticket03_me_endpoint.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/me-endpointFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/me-endpointSubmit 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 inRun the existing test suite (uses an in-memory SQLite DB, no setup needed):
.venv/bin/python -m pytest -v # 33 passed, 0 failed on a clean checkout
cp .env.example .env
# edit .env: set SECRET_KEY, JWT_SECRET_KEY, POSTGRES_PASSWORD to real values
docker compose up --build
This builds the web image, starts Postgres (db), waits for its healthcheck, then runs flask db upgrade and starts gunicorn -- all with one command, no manual migration step. The API is then available at http://localhost:5000.
Work the tickets in practicetickets/ (TICKET_01 through TICKET_07); each names one pytest test file in the same directory. This directory is outside pytest.ini's testpaths = tests, so a bare pytest run from the project root never picks these up -- they only run when pointed at directly:
cd flask/movie_watchlist
.venv/bin/python -m pytest practicetickets/test_ticket01_movie_list_ordering.py -v # a single ticket
./practicetickets/run_tickets.sh # all 7, clean pass/fail summary
run_tickets.sh also unsets TEST_DATABASE_URL/DATABASE_URL for its own run, so a leftover Postgres URL from a different project in your shell doesn't get picked up instead of the in-memory SQLite DB these tests are written against.
Level 2
Implement a feature
Extend the system within its own patterns.