From 03e0d84380372fd17d7122c8d9de780789694b73 Mon Sep 17 00:00:00 2001 From: Frank Date: Mon, 2 Nov 2026 19:09:23 -0800 Subject: [PATCH] docs(audiobookshelf): the phone app's connection facts and where its token lives MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The page told an agent how to sign in from a browser and nothing about the phone. Measured 2026-11-03 on the deployed service: - Server Address `http://192.168.0.235:8000`, user `frank`, plain HTTP, no base-path prefix; `/healthcheck` and `/ping` answer 200 from a second host on the LAN and `iptables -S INPUT` has no rule for 8000, so no phone-side setup is needed. `download: true` on the root account is what enables offline listening. - `POST /login` puts the bearer at `user.token`, not top level. Reading `response.token` yields "", the client sends `Authorization: Bearer ` with nothing after it, and every `/api/*` answers 401 as though the password were wrong — which it was not. That is the failure I hit inside five minutes of scripting this. - The LAN-only law gains its consequence for clients: the Anubis + Authentik chain serves browsers, so guarding a vhost does not make the phone app work remotely. Remote listening wants a VPN into the LAN; the LAN address is then still correct. bats: 822 seams green. --- .../Dankserver/Audiobookshelf.md | 21 ++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/serverAppConfigs-docs/Dankserver/Audiobookshelf.md b/serverAppConfigs-docs/Dankserver/Audiobookshelf.md index 55fb1c3..f81a2e5 100644 --- a/serverAppConfigs-docs/Dankserver/Audiobookshelf.md +++ b/serverAppConfigs-docs/Dankserver/Audiobookshelf.md @@ -65,6 +65,22 @@ never `/healthcheck`. It also reads files that are genuinely broken and logs `[AudioFileScanner] Invalid data found when processing input` per file — that is the file, not the bind: the same line count grows while the total climbs. +## Phone app + +The official **Audiobookshelf** app connects with Server Address +`http://192.168.0.235:8000`, username `frank`, and the same password as the web UI — +no base-path prefix, plain HTTP. Verified from a second host 2026-11-03: `/healthcheck` +and `/ping` answer 200 across the LAN and `iptables -S INPUT` carries no rule for 8000, +so a phone on `192.168.0.0/24` connects with no further setup; `download: true` on the +root account is what makes offline listening work. Away from the LAN it cannot connect — +see the LAN-only law, and note that the guard chain is not the remedy there. + +**The login token is at `user.token`, not top level.** `POST /login` answers +`{ user, serverSettings, ereaderDevices, Source, userDefaultLibraryId }` and the bearer sits +inside the user object. A client that reads `response.token` gets the empty string, sends +`Authorization: Bearer ` with nothing after it, and every `/api/*` call then answers `401` +as though the password were wrong. + ## Laws - **Speak the image's env names, not the README's.** The server reads `PORT`, @@ -108,7 +124,10 @@ the file, not the bind: the same line count grows while the total climbs. - **LAN-only until Frank says otherwise.** `0.0.0.0:8000` with no reverse proxy in front. Any public vhost requires the Anubis + Authentik chain first, and the outpost proxy provider has to exist before the vhost flips (external exposure - policy in `AGENTS.md`). + policy in `AGENTS.md`). That chain serves browsers: the phone app is a non-browser + client and cannot solve a challenge, so guarding a vhost does not make remote + listening work — remote listening wants a VPN into the LAN, after which the LAN + address in *Phone app* is correct unchanged. - **There is no `/setup` route; the creation door is `POST /init`.** `/status` (no `/api` prefix) reports `isInit` = "a root user exists", `POST /init` with `{"newRoot":{"username","password"}}` creates it, `POST /login` returns the -- 2.54.0