v0.1.2

• Sign-in redirect: a crafted sign-in link can no longer send you to another website after you sign in.
• Music server load: restoring a long queue or playing a whole artist now sends at most 8 requests to the music server at a time.
• Sign-in errors: a failed sign-in no longer shows the music server's internal error details. The details are still written to the server log.
• Docs: they now state that the Docker image always marks the session cookie Secure. If you reach Heddohon over plain http, without https, set HEDDOHON_COOKIE_SECURE=false or sign-in will not stick.

v0.1.1

v0.1.1

A security release. Nine fixes from a second review of authentication, session
handling and the cover cache. Behaviour outside those areas is unchanged.

Everyone signs in again

Upgrading ends every existing session. The session cookie is now named
__Host-heddohon_session wherever it is Secure, and exactly one name is read
per request. Reading the old name as a fallback would leave the shadowing
problem below open, so cookies issued by 0.1.0 are not honoured. Settings,
playlists, saved queues and playback positions are unaffected.

Fixed

The sign-in throttle could be bypassed by sending attempts at once.

One address could refuse sign-in to everybody. Behind a reverse proxy with
no ADDRESS_HEADER, every visitor arrives as the proxy, so 60 deliberate
failures in 15 minutes blocked sign-in for the whole deployment, and a correct
password did not clear it. The address counter now applies only where the
address identifies a visitor, and a line is logged where it does not.

A sibling subdomain could pin a session.

The session cookie could go out without Secure. The flag was derived from
ORIGIN. adapter-node does not require ORIGIN: it derives the origin from the
Host header and defaults the scheme to https, so an https deployment with
ORIGIN unset passed its own cross-origin check while the cookie went out
unprotected. The flag now follows the request scheme.

/healthz named the music server. A configuration error returned its own
message, which carries the offending variable and its value, so
HEDDOHON_SUBSONIC_URL=10.0.0.10:4533 was readable without signing in. The
response now reports that there is a fault and the detail stays in the log.

Cached artwork crossed Jellyfin library limits.

Authenticated pages could be stored by a shared proxy. Pages and private
JSON carried neither Cache-Control nor Vary. Responses now default to
private, no-store and carry Vary: Cookie. The cover and stream routes keep
their own max-age.

?next= could send you off-site after signing in.

Alice and alice were two accounts. Both music servers accept a username
in any case, and the account row was matched case-sensitively, which split
settings, saved queues and playback position across two rows. The lookup is now
COLLATE NOCASE.

Upgrading

docker compose pull && docker compose up -d.

v0.1.0

In this release

• Original files by default. Subsonic requests use format=raw, Jellyfin
  static=true. The player shows what is being decoded: FLAC 24/96, MP3 320.
• Transcoding when the connection will not play the original
• Cover art cached on the server
• Per-account settings and queue

Install

git clone https://github.com/zorcerer/heddohon.git && cd heddohon
cp .env.example .env

Edit .env: set HEDDOHON_SECRET (openssl rand -base64 48), point
HEDDOHON_SUBSONIC_URL or HEDDOHON_JELLYFIN_URL at your music server, and
delete the line for the one you do not have. Those URLs are resolved by the
container rather than by the browser, so a private address is the right answer.
Set ORIGIN to the public URL if you reach Heddohon through a reverse proxy, or
form submissions are refused by the CSRF origin check.

docker compose up -d

Then open http://localhost:13000 and sign in with your music server account.
Everything in .env reaches the container; the full list is in
docs/configuration.md.

On Unraid, install from Community Applications instead; the template is at
templates/heddohon.xml.

On Unraid, the Community Applications template is at templates/heddohon.xml.

Set ORIGIN to the public URL if you reach it through a reverse proxy, or form
submissions are refused by the CSRF origin check. Every variable is listed in
docs/configuration.md.

Before you expose it publicly

This is a 0.1.0 and has not been audited by a third party. The controls and the
known gaps are written up in SECURITY.md; the largest outstanding
one is that the application's own pages carry no Content-Security-Policy.