Tests: Cloudflare Access sign-in, the sign-in rate limit and account settings #399

New Issue

rays · 2026-11-06T19:51:42-08:00

rays commented

2026-11-06 19:51:42 -08:00

access.rs is at 68% of its lines, and the browser suite never reaches it (0%): fetch and prefetch, which get the team's signing keys, and the parts of verify that check a real token, are untested. In web.rs, vouched_name and parts of auth, too_many (the sign-in flood answer) and patch_me (blocked words, the TypeSafe key) are untested; in cli.rs, user_cmd (45 lines: add, passwd, rm, list). This is who gets in.

Tests to add:

with a local JWKS endpoint standing in for the team's: a token signed by its key, for the right audience and not expired, signs in as its email; a wrong audience, an expired token, an unknown key id, an HS256 token, and a header without a token are each refused (and logged)
Cf-Access-* headers are trusted only from the configured proxy address (#209), from a container on another network as cloudflared's are
the keys are fetched once and refreshed when a token names a key not seen yet
a flood of wrong passwords from one address is answered 429 (too_many) and a right one after the wait still works (the load test's signin covers volume, not this)
PATCH /api/me: blocked words over the limits are refused; a TypeSafe key is checked before it is saved
ipx user add|passwd|rm|list against a scratch database

Seen with the coverage of both suites merged line by line (cargo: sh scripts/coverage.sh, browser: sh scripts/coverage.sh api; reports in target/coverage/cargo, api and page; #390, #394), as of 2026-11-07. A test added here shows in Grafana's Coverage row at the next run.

access.rs is at 68% of its lines, and the browser suite never reaches it (0%): `fetch` and `prefetch`, which get the team's signing keys, and the parts of `verify` that check a real token, are untested. In web.rs, `vouched_name` and parts of `auth`, `too_many` (the sign-in flood answer) and `patch_me` (blocked words, the TypeSafe key) are untested; in cli.rs, `user_cmd` (45 lines: add, passwd, rm, list). This is who gets in. Tests to add: - with a local JWKS endpoint standing in for the team's: a token signed by its key, for the right audience and not expired, signs in as its email; a wrong audience, an expired token, an unknown key id, an HS256 token, and a header without a token are each refused (and logged) - Cf-Access-* headers are trusted only from the configured proxy address (#209), from a container on another network as cloudflared's are - the keys are fetched once and refreshed when a token names a key not seen yet - a flood of wrong passwords from one address is answered 429 (`too_many`) and a right one after the wait still works (the load test's signin covers volume, not this) - PATCH /api/me: blocked words over the limits are refused; a TypeSafe key is checked before it is saved - `ipx user add|passwd|rm|list` against a scratch database Seen with the coverage of both suites merged line by line (cargo: `sh scripts/coverage.sh`, browser: `sh scripts/coverage.sh api`; reports in target/coverage/cargo, api and page; #390, #394), as of 2026-11-07. A test added here shows in Grafana's Coverage row at the next run.

rays added the enhancement label 2026-11-06 19:51:42 -08:00

rays referenced this issue

2026-11-06 20:10:29 -08:00

No limit on wrong passwords for one name or address #409

rays referenced this issue from a commit

2026-11-06 20:10:35 -08:00

Tests for proxy sign-in, passwords, account settings and ipx user (#399)

rays commented

2026-11-06 20:10:41 -08:00

Tests added in 3bb59c2. web.rs runs the router with a peer address: the proxy's header is believed only from the trusted proxy; with Access set the name is the signed token's, and another app's token, an expired one, garbage, no token, no header, or a good token not via Caddy are each refused; wrong passwords and unknown names are 401 and the right one afterwards signs in with a session cookie; PATCH /api/me refuses an over-long block list and a malformed TypeSafe key before asking TypeSafe. access.rs reads the keys from a local stand-in for the team's certs (a 503 and a 404 are errors); the refetch of an unseen key id was already tested. cli.rs: ipx user add, list, passwd (which signs every browser out), rename and rm against a scratch database. Not done: the 429 for a flood of wrong passwords, which does not exist (#409), and a TypeSafe key TypeSafe refuses, which needs IPX_TYPESAFE_URL set process-wide and is left to #398's stand-in.

Tests added in 3bb59c2. web.rs runs the router with a peer address: the proxy's header is believed only from the trusted proxy; with Access set the name is the signed token's, and another app's token, an expired one, garbage, no token, no header, or a good token not via Caddy are each refused; wrong passwords and unknown names are 401 and the right one afterwards signs in with a session cookie; PATCH /api/me refuses an over-long block list and a malformed TypeSafe key before asking TypeSafe. access.rs reads the keys from a local stand-in for the team's certs (a 503 and a 404 are errors); the refetch of an unseen key id was already tested. cli.rs: ipx user add, list, passwd (which signs every browser out), rename and rm against a scratch database. Not done: the 429 for a flood of wrong passwords, which does not exist (#409), and a TypeSafe key TypeSafe refuses, which needs IPX_TYPESAFE_URL set process-wide and is left to #398's stand-in.

rays closed this issue

2026-11-06 20:10:42 -08:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rays/ipx#399