Bearer-auth routes reject every legitimate request

Nobody has started this yet — be first.

Business impact

Any route configured with auth.type: bearer is completely unusable -- every single request gets 401'd, including ones with a perfectly valid token. If a customer-facing API is fronted by a bearer-auth route, this is a full outage for that route, not a degradation: 100% of traffic fails, and the error message ("missing x-api-key header") actively misleads whoever is debugging it, since the client is correctly sending Authorization: Bearer ..., not x-api-key.

Problem

AuthConfig.header_name() is supposed to return x-api-key for api_key routes and authorization for bearer routes (unless a route overrides it via auth.header). Right now it returns "x-api-key" unconditionally, regardless of .

Current behavior

header_name()'s per-type branch has been collapsed to a single unconditional return, so AuthConfig(type="bearer").header_name() returns "x-api-key" instead of "authorization", even though self.type is right there to branch on.

Expected behavior

A route with auth.type: bearer (and no explicit auth.header override) reads the credential from the Authorization header, exactly as app/auth/checks.py::check_bearer expects.

Steps to reproduce

Configure a route with auth: {type: bearer, credentials: {"tok-1": "client-a"}}.
Send a request with Authorization: Bearer tok-1.
Observe: 401, "missing x-api-key header". Expected: 200.

Why this matters

header_name() is the single source of truth both check_api_key and check_bearer (app/auth/checks.py) call to find their credential -- it is shared logic with a per-type branch that is supposed to pick the right default. Collapsing the branch to always return one value is the kind of copy-paste-and-forgot-to-finish mistake that is easy to miss because api_key routes (the more common case, probably written and tested first) keep working fine.

Suggested approach

Look at header_name()'s only two possible return values and the docstring comment two lines above it that already states the intended mapping. The method has all the information it needs (self.type) to pick correctly -- it just is not using it.

Acceptance criteria

AuthConfig(type="bearer").header_name() returns "authorization"
AuthConfig(type="api_key").header_name() returns "x-api-key"
AuthConfig(type="bearer", header="x-custom").header_name() still returns the explicit override regardless of type

Verification

pytest practice_tickets/tests/test_ticket_02_bearer_auth_wrong_header.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 fix/bearer-auth-wrong-header

Fix it and commit

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

Push the branch

$git push -u origin fix/bearer-auth-wrong-header

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

Dynamic API Gateway & Reverse Proxy

A FastAPI reverse proxy that streams every request and response without ever buffering a body in full, with hot-reloadable routing, per-route auth, Redis token-bucket rate limiting, and a per-upstream circuit breaker.

Fork on GitHub

Download

Setup

Dynamic API Gateway & Reverse Proxy

git clone <your-fork>
cd FastAPIDevTraining/gateway_proxy
cp .env.example .env   # adjust GATEWAY_ADMIN_TOKEN etc. if you like
docker compose up --build   # Redis + the gateway (uvicorn --reload) + 2 demo upstreams

The gateway is reachable at . Two demo upstreams come up alongside it — (low-latency JSON echo at , plus for the streaming-passthrough demo) and (, , for timeout and circuit-breaker demos) — and wires five example routes against them, one per feature. Verify the stack with (liveness only) and (pings Redis, which every rate-limited route depends on). Every endpoint (route CRUD, reload, persist, breaker snapshot) requires .