mirror of
https://github.com/TecharoHQ/anubis.git
synced 2026-05-16 03:30:11 +00:00
Xe Iaso
2c1237b5c0
Previously Anubis only checked for the X-Original-Url when using subrequest mode. This header is used by the example nginx config to pass the request path through from the original client request to Anubis in order to do path-based filtering. According to facts and circumstances, Traefik hardcodes its own headers[1]: ```text httpdebug-1 | GET /.within.website/x/cmd/anubis/api/check httpdebug-1 | X-Forwarded-Method: GET httpdebug-1 | X-Forwarded-Proto: http httpdebug-1 | X-Forwarded-Server: b9a5d299c929 httpdebug-1 | X-Forwarded-Port: 8080 httpdebug-1 | X-Forwarded-Uri: / httpdebug-1 | X-Real-Ip: 172.18.0.1 httpdebug-1 | Accept-Encoding: gzip httpdebug-1 | User-Agent: curl/8.20.0 httpdebug-1 | Accept: */* httpdebug-1 | X-Forwarded-For: 172.18.0.1 httpdebug-1 | X-Forwarded-Host: localhost:8080 ``` As a result, this means that path-based filtering did not work. This commit fixes this issue by amending how path based checking logic works: * For CEL based checks, this pipes through the `subrequestMode` flag from main and alters the behaviour if either `X-Original-Url` or `X-Forwarded-Url` are found. These values are currently hardcoded for convenience but probably need to be made configurable in the policy file at a future date. * For path-based checks, this uses the existing `subrequestMode` flag from main and adds `X-Forwarded-Url` to the list of headers it checks. A smoke test was added to make sure that traefik in this mode continues to work. Thank you https://github.com/flifloo for filing a detailed issue with the relevant configuration fragments. Those configuration fragments formed the core of this smoke test. [1]: https://doc.traefik.io/traefik/v3.4/middlewares/http/forwardauth/ Closes: https://github.com/TecharoHQ/anubis/issues/1628 Signed-off-by: Xe Iaso <me@xeiaso.net> Co-Authored-By: flifloo <flifloo@gmail.com>
Website
This website is built using Docusaurus, a modern static website generator.
Installation
$ yarn
Local Development
$ yarn start
This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
Build
$ yarn build
This command generates static content into the build directory and can be served using any static contents hosting service.
Deployment
Using SSH:
$ USE_SSH=true yarn deploy
Not using SSH:
$ GIT_USER=<Your GitHub username> yarn deploy
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the gh-pages branch.