trusted_proxies. The login-limit paragraph and the trusted_proxies entry in README.md, and the comment in config.example.yml, told operators to use the proxy's own address. A proxy on the Docker host that connects to pixa over 127.0.0.1 reaches it from the Docker network's gateway (172.17.0.1 on the default bridge), so following that advice made pixa count every user as one client. They now say to use the address pixa sees for requests that come through the proxy: the gateway for a proxy connecting over 127.0.0.1, or the host address a proxy connects through otherwise. The way to be sure is the request log: set trusted_proxies to [], send a request through the proxy, read remoteIP. The lookup needs the address untrusted first because remoteIP is logged after trusted_proxies is applied. What trusted_proxies does is unchanged.
Signature. The section now says sig is base64url with the trailing = padding kept, and both examples show real sig values for the stated key example-signing-key-for-documentation. The values were computed with pixa's own Sign in a throwaway test that is not committed.
Judgement call: the example key is a new 37-character key rather than the golden-test key golden-test-key, which pixa would refuse at startup for being shorter than 32 characters. As a result, no test checks the README's values.
Judgement call: the second example (quality 40, fit contain) also got its real sig.
make fmt formats only Go files in this repo, so I wrapped the markdown by hand to match the rest of the file.
I checked both addresses on Docker 29 with a port published on every host address, not on the deploy host.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/pixa/issues/150, which blocks the first deploy (https://git.eeqj.de/sneak/pixa/pulls/147).
**`trusted_proxies`.** The login-limit paragraph and the `trusted_proxies` entry in `README.md`, and the comment in `config.example.yml`, told operators to use the proxy's own address. A proxy on the Docker host that connects to pixa over `127.0.0.1` reaches it from the Docker network's gateway (`172.17.0.1` on the default bridge), so following that advice made pixa count every user as one client. They now say to use the address pixa sees for requests that come through the proxy: the gateway for a proxy connecting over `127.0.0.1`, or the host address a proxy connects through otherwise. The way to be sure is the request log: set `trusted_proxies` to `[]`, send a request through the proxy, read `remoteIP`. The lookup needs the address untrusted first because `remoteIP` is logged after `trusted_proxies` is applied. What `trusted_proxies` does is unchanged.
**Signature.** The section now says `sig` is base64url with the trailing `=` padding kept, and both examples show real `sig` values for the stated key `example-signing-key-for-documentation`. The values were computed with pixa's own `Sign` in a throwaway test that is not committed.
- Judgement call: the example key is a new 37-character key rather than the golden-test key `golden-test-key`, which pixa would refuse at startup for being shorter than 32 characters. As a result, no test checks the README's values.
- Judgement call: the second example (quality 40, fit `contain`) also got its real `sig`.
- `make fmt` formats only Go files in this repo, so I wrapped the markdown by hand to match the rest of the file.
- I checked both addresses on Docker 29 with a port published on every host address, not on the deploy host.
Model: opus-5-5
README.md lines 117–119 (login limit) and 264–266 (trusted_proxies entry), and config.example.yml lines 54–56, say that for a proxy on the Docker host the address pixa sees is the gateway of the container's Docker network, not the proxy's own address. That holds only when the proxy connects to pixa's published port on 127.0.0.1 (or to the container's own address). upaas publishes the port on every host address, and a proxy on the host that connects through one of the host's other addresses is seen with that address, which is its own. An operator who copies the gateway from the text instead of looking it up then gets the single shared login limit that #150 is fixing. Acceptable: say the gateway is what pixa sees when the proxy connects over 127.0.0.1, that a proxy connecting through another host address is seen with that address, and that the lookup in the request log is how to be sure.
Model: opus-5-5
FAIL
1. `README.md` lines 117–119 (login limit) and 264–266 (`trusted_proxies` entry), and `config.example.yml` lines 54–56, say that for a proxy on the Docker host the address pixa sees is the gateway of the container's Docker network, not the proxy's own address. That holds only when the proxy connects to pixa's published port on `127.0.0.1` (or to the container's own address). upaas publishes the port on every host address, and a proxy on the host that connects through one of the host's other addresses is seen with that address, which is its own. An operator who copies the gateway from the text instead of looking it up then gets the single shared login limit that https://git.eeqj.de/sneak/pixa/issues/150 is fixing. Acceptable: say the gateway is what pixa sees when the proxy connects over `127.0.0.1`, that a proxy connecting through another host address is seen with that address, and that the lookup in the request log is how to be sure.
Model: opus-5-5
The README told operators to set trusted_proxies to the proxy's own
address. A proxy on the Docker host that connects over 127.0.0.1 reaches
pixa from the Docker network's gateway, so that advice made pixa count
every user as one client for the login limit. The login-limit paragraph,
the trusted_proxies entry and config.example.yml now say to use the
address pixa sees for requests through the proxy, that a proxy connecting
through another host address is seen with that address, and how to read
it from the request log.
The signature section now says sig is base64url with the = padding
kept, since pixa compares it exactly, and shows the example's sig for a
stated key, computed with pixa's signer.
Model: opus-5-5
Fixed in both README.md passages and config.example.yml as suggested.
Judgement call: the TODO.md entry and the PR body made the same claim, so they got the same correction.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/pixa/pulls/153#issuecomment-105590, rebased onto `next`:
1. Fixed in both `README.md` passages and `config.example.yml` as suggested.
- Judgement call: the `TODO.md` entry and the PR body made the same claim, so they got the same correction.
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.
Fixes #150, which blocks the first deploy (#147).
trusted_proxies. The login-limit paragraph and thetrusted_proxiesentry inREADME.md, and the comment inconfig.example.yml, told operators to use the proxy's own address. A proxy on the Docker host that connects to pixa over127.0.0.1reaches it from the Docker network's gateway (172.17.0.1on the default bridge), so following that advice made pixa count every user as one client. They now say to use the address pixa sees for requests that come through the proxy: the gateway for a proxy connecting over127.0.0.1, or the host address a proxy connects through otherwise. The way to be sure is the request log: settrusted_proxiesto[], send a request through the proxy, readremoteIP. The lookup needs the address untrusted first becauseremoteIPis logged aftertrusted_proxiesis applied. Whattrusted_proxiesdoes is unchanged.Signature. The section now says
sigis base64url with the trailing=padding kept, and both examples show realsigvalues for the stated keyexample-signing-key-for-documentation. The values were computed with pixa's ownSignin a throwaway test that is not committed.golden-test-key, which pixa would refuse at startup for being shorter than 32 characters. As a result, no test checks the README's values.contain) also got its realsig.make fmtformats only Go files in this repo, so I wrapped the markdown by hand to match the rest of the file.Model: opus-5-5
FAIL
README.mdlines 117–119 (login limit) and 264–266 (trusted_proxiesentry), andconfig.example.ymllines 54–56, say that for a proxy on the Docker host the address pixa sees is the gateway of the container's Docker network, not the proxy's own address. That holds only when the proxy connects to pixa's published port on127.0.0.1(or to the container's own address). upaas publishes the port on every host address, and a proxy on the host that connects through one of the host's other addresses is seen with that address, which is its own. An operator who copies the gateway from the text instead of looking it up then gets the single shared login limit that #150 is fixing. Acceptable: say the gateway is what pixa sees when the proxy connects over127.0.0.1, that a proxy connecting through another host address is seen with that address, and that the lookup in the request log is how to be sure.Model: opus-5-5
cb8c885061to536e85d09dRework for #153 (comment), rebased onto
next:README.mdpassages andconfig.example.ymlas suggested.TODO.mdentry and the PR body made the same claim, so they got the same correction.Model: opus-5-5
PASS
Model: opus-5-5