Found in the release review of #147 (#147 (comment), findings 1 and 3). Two README.md statements would mislead an operator on first deploy.
trusted_proxies advice. The login-limit paragraph says "setting trusted_proxies to the proxy's own address closes this". A proxy on the Docker host reaches pixa from the Docker network's gateway (for example 172.17.0.1 on the default bridge), not from its own address. An operator who sets 127.0.0.1/32 makes pixa record every client as the gateway, so all users share one login limit and anyone can lock the owner out.
Signature encoding. Step 3 of the signature example says "Base64URL-encode the result" without saying the trailing = padding is kept. pixa compares the signature exactly, so a signer whose encoder drops padding (Node's base64url, Go's RawURLEncoding) gets 401 on every URL.
Definition of done
The login-limit paragraph and the trusted_proxies entry say to set trusted_proxies to the address pixa sees for requests that come through the proxy, which pixa's request log shows; for a proxy on the Docker host that is the Docker network's gateway. No other change to what trusted_proxies does.
The signature section says the signature is base64url with padding kept, and shows the example's actual signature value for a stated key, computed from the code.
Documentation only; every changed sentence is true of the code.
Model: opus-5-5
Found in the release review of https://git.eeqj.de/sneak/pixa/pulls/147 (https://git.eeqj.de/sneak/pixa/pulls/147#issuecomment-105251, findings 1 and 3). Two `README.md` statements would mislead an operator on first deploy.
1. `trusted_proxies` advice. The login-limit paragraph says "setting `trusted_proxies` to the proxy's own address closes this". A proxy on the Docker host reaches pixa from the Docker network's gateway (for example `172.17.0.1` on the default bridge), not from its own address. An operator who sets `127.0.0.1/32` makes pixa record every client as the gateway, so all users share one login limit and anyone can lock the owner out.
2. Signature encoding. Step 3 of the signature example says "Base64URL-encode the result" without saying the trailing `=` padding is kept. pixa compares the signature exactly, so a signer whose encoder drops padding (Node's `base64url`, Go's `RawURLEncoding`) gets 401 on every URL.
## Definition of done
- The login-limit paragraph and the `trusted_proxies` entry say to set `trusted_proxies` to the address pixa sees for requests that come through the proxy, which pixa's request log shows; for a proxy on the Docker host that is the Docker network's gateway. No other change to what `trusted_proxies` does.
- The signature section says the signature is base64url with padding kept, and shows the example's actual signature value for a stated key, computed from the code.
- Documentation only; every changed sentence is true of the code.
Model: opus-5-5
clawbot
added this to the 1.0.0 milestone 2026-09-29 04:08:24 +02:00
clawbot
self-assigned this 2026-09-29 04:08:24 +02:00
#153 corrects the trusted_proxies advice in README.md and config.example.yml (use the address pixa sees for requests through the proxy, found as remoteIP in the request log while it is untrusted; for a proxy on the Docker host, the Docker network's gateway). It also states that sig is base64url with the = padding kept, and shows the example's real sig for the key example-signing-key-for-documentation.
Model: opus-5-5
https://git.eeqj.de/sneak/pixa/pulls/153 corrects the `trusted_proxies` advice in `README.md` and `config.example.yml` (use the address pixa sees for requests through the proxy, found as `remoteIP` in the request log while it is untrusted; for a proxy on the Docker host, the Docker network's gateway). It also states that `sig` is base64url with the `=` padding kept, and shows the example's real `sig` for the key `example-signing-key-for-documentation`.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found in the release review of #147 (#147 (comment), findings 1 and 3). Two
README.mdstatements would mislead an operator on first deploy.trusted_proxiesadvice. The login-limit paragraph says "settingtrusted_proxiesto the proxy's own address closes this". A proxy on the Docker host reaches pixa from the Docker network's gateway (for example172.17.0.1on the default bridge), not from its own address. An operator who sets127.0.0.1/32makes pixa record every client as the gateway, so all users share one login limit and anyone can lock the owner out.=padding is kept. pixa compares the signature exactly, so a signer whose encoder drops padding (Node'sbase64url, Go'sRawURLEncoding) gets 401 on every URL.Definition of done
trusted_proxiesentry say to settrusted_proxiesto the address pixa sees for requests that come through the proxy, which pixa's request log shows; for a proxy on the Docker host that is the Docker network's gateway. No other change to whattrusted_proxiesdoes.Model: opus-5-5
#153 corrects the
trusted_proxiesadvice inREADME.mdandconfig.example.yml(use the address pixa sees for requests through the proxy, found asremoteIPin the request log while it is untrusted; for a proxy on the Docker host, the Docker network's gateway). It also states thatsigis base64url with the=padding kept, and shows the example's realsigfor the keyexample-signing-key-for-documentation.Model: opus-5-5