Review fixes. The bolded lead read as an absolute while the body reported 363
DD-MM-YYYY headings and told you to match the file — it now says "most", and
says outright that a DD-MM-YYYY file stays DD-MM-YYYY. The counts are stamped
as of 2026-08-25 so a future reader knows they are a snapshot.
CodeRabbit is right that `grep -q "^## ${version} ("` is not an exact-version
check. Reproduced: with version 5.1.1.2 the pattern matches a heading reading
`## 5X1Y1Z2 (`, because BRE dots match any character; `grep -qF` does not.
Described as an unescaped BRE instead. The conclusion is unchanged, since the
date is not in the pattern either way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SKILL.md's step 7 said to match `## X.Y (DD-MM-YYYY)`. The repo does not use
that: 7705 dated CHANGELOG headings are ISO `YYYY-MM-DD` against 363 in
`DD-MM-YYYY`, and the newest entry is ISO in 125 of 135 add-ons. Following the
instruction cost a Copilot review round on #3019.
`DD-MM-YYYY` is not invented, which is presumably how it got written down. It
is what `onpush_builder.yaml` inserts with `date '+%d-%m-%Y'` when a push
arrives with no heading for the config.yaml version, and it is the addons_updater
bot's default in `99-run.sh` — but that bot runs here with `date_iso8601: true`
(confirmed against the running add-on's options), which is why almost everything
on master is ISO. Neither is a reason to write `DD-MM-YYYY` by hand.
The traps.md entry also records that the builder's duplicate check is
`grep -q "^## ${version} ("` — keyed on the exact config.yaml version and blind
to the date — so an ISO heading you wrote yourself still suppresses the bot's
insertion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(sabnzbd): enable Home Assistant ingress
The add-on already carried a complete but disabled nginx ingress scaffold:
`etc/nginx/` with its includes and a `servers/ingress.conf`, a
`cont-init.d/32-nginx_ingress.sh` short-circuited by `exit 0`, and
`ENV PACKAGES="nginx"` in a Dockerfile byte-identical to nzbget's. Only
`ingress: true` and the s6 service that starts nginx were missing.
What SABnzbd 5.1.1 actually needs from the proxy, measured against the
running add-on rather than assumed:
- Its interface emits only relative links (`href="../../config/general/"`,
`href="../../staticcfg/css/Auto.css"`, `action="./one"`), and grepping the
5.1.1 source for `(href|src|action)="/` across `interfaces/{Glitter,Config,
wizard}` and for absolute `url:` literals in the Glitter JavaScript returns
nothing. A plain pass-through proxy preserves path depth, so no `sub_filter`
is warranted. The previous config's `sub_filter /sabnzbd ...` would also have
mangled the `https://sabnzbd.org/wiki/...` help links present on every
config page.
- Redirects are the one exception: `Raiser()` prefixes `cfg.url_base()`, so
`GET /` answers `303 Location: /sabnzbd/wizard/`. One `proxy_redirect`
handles every observed case; all of them were path-absolute, never a full
URL. Login redirects and logout go through the same `Raiser()`, and the
session cookie's path is hardcoded to `/` (`interface.py:316`), so it is
still sent under the ingress path.
- SABnzbd rejects a Host header that is not an IP literal:
`Host: homeassistant` answers 403 "Hostname verification failed", while
`Host: 192.168.1.5:8123` answers 200. nginx therefore sends `$proxy_host`
instead of including the shared `proxy_params.conf`, which forwards
`$http_host`.
`ingress_entry: sabnzbd` is dropped rather than kept: Supervisor appends it to
the ingress URL, which only resolves while the user's `url_base` is literally
`/sabnzbd`, and that is a setting they can change. SABnzbd serves the same
interface at `/` as under its `url_base` (verified for `/config/general/`,
`/static/`, `/staticcfg/` and `/wizard/`), so entering at the ingress root
works for any value, including the empty code default.
Ingress traffic reaches SABnzbd as `127.0.0.1:8080` and so is not filtered by
a user's host whitelist; direct ip:port access is unchanged and still is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(sabnzbd): keep the ingress Location relative and scope the login cookie
Exercising the shipped config against the running add-on caught a bug that
reading it did not. With nginx's default `absolute_redirect on`, rewriting
`Location: /sabnzbd/wizard/` produced
`http://homeassistant.local:18099/api/hassio_ingress/<token>/sabnzbd/wizard/`
— nginx expands a scheme-less replacement using the browser's Host and its own
listen port, which is the add-on's internal ingress port and is not reachable
from the browser. `absolute_redirect off` keeps it a path, which the browser
resolves against the Home Assistant origin.
`proxy_cookie_path` comes from Codex's review of the diff. SABnzbd hardcodes
the login cookie to `Path=/` (`interface.py:316`), so on the shared ingress
origin the browser would send it to every other add-on's ingress path as well.
Verified end to end by running the shipped nginx.conf and ingress.conf against
the live add-on, with the browser Host set to a non-IP hostname throughout:
all five redirect cases return a path under the ingress entry, the config
pages, wizard, API and both static roots return 200, and a stub upstream
emitting `Path=/` comes back rewritten to the ingress path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(sabnzbd): drop webui, which the add-on linter forbids alongside ingress
frenck/action-addon-linter fails the PR with "'webui' should be removed,
Ingress is enabled." No other ingress add-on in this repo keeps the key. The
"Open Web UI" button now opens ingress; the ports mapping is untouched, so
direct ip:port still works, it just has to be typed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(sabnzbd): make the nginx finish script actually work on s6-overlay v3
CodeRabbit is right that the execline finish script copied from nzbget is
inert on this image. s6-portable-utils dropped `s6-test` in favour of
execline's `eltest` — s6-overlay 3.2.1.0 ships no `s6-test` at all — so
execlineb cannot run the first `if` block and never reaches s6-svscanctl.
`/var/run/s6/services` is also the v2 scandir path; v3's legacy services.d
compatibility layer uses /run/service.
Rather than port it to eltest, use the shell form the scrutiny add-on already
ships: `kill -15 1` signals s6-overlay's init directly, so it depends on
neither the s6 tool set nor the scandir path, and it is three lines shorter.
The 0 and 256 exclusions are kept, so a normal shutdown does not trigger it.
Also fix the CHANGELOG date to YYYY-MM-DD per Copilot: that is what this file
and 7705 of the repo's 8068 dated headings use.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 15:46:36 +02:00
8 changed files with 68 additions and 26 deletions
- Ingress is now enabled: the WebUI opens directly in the Home Assistant sidebar, and the "Open Web UI" button now goes there. Access by ip:port is unchanged, but has to be typed rather than clicked, as Home Assistant does not allow an add-on to offer both.
- Note for users who set a "Host verification" whitelist in SABnzbd: ingress sends `Host: 127.0.0.1:8080` upstream, because SABnzbd rejects any Host that is not an IP literal. That whitelist therefore no longer filters the ingress route, which is gated by Home Assistant authentication instead. Direct ip:port access is unchanged and still filtered.
## 5.1.1 (2026-08-22)
- Update to latest version from linuxserver/docker-sabnzbd (changelog : https://github.com/linuxserver/docker-sabnzbd/releases)
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.