dank/serverAppConfigs
1
0 Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(audiobookshelf): the wide listener default is a decision, not a defect

Browse Source 
The SSO paragraph left "whether an access policy should be bound to the
audiobookshelf application" open, which invites the next agent to relitigate
it. Frank's answer of 2026-11-03: accepted on purpose — every signer becomes a
listener with all libraries and downloads, no access policy on the application,
narrowing done per account in Settings -> Users. What that makes load-bearing is
authentik's own signup flow, now named in the same paragraph as the thing that
must stay operator-only.
This commit is contained in:
Frank committed 2026-11-03 03:08:36 -08:00
1 parent 1a47b831ee
commit 5794b07c32
1 file changed
+9 -6
Download Patch File Download Diff File Expand all files Collapse all files
serverAppConfigs-docs/Dankserver/Audiobookshelf.md
+9 -6
View File
@@ -146,12 +146,15 @@ the local form, and the phone app offers SSO on its server-address screen. The l
With `authOpenIDAutoRegister` on, a first sign-in creates the account and the claim alone With `authOpenIDAutoRegister` on, a first sign-in creates the account and the claim alone
decides its type — and the claim always carries `user`, so **the IdP is now the library gate**: decides its type — and the claim always carries `user`, so **the IdP is now the library gate**:
any authentik account that can reach this application becomes a listener. That is the intent any authentik account that can reach this application becomes a listener. That is the
(the household signs in with the accounts it already has), which makes two things worth intent (the household signs in with the accounts it already has), and its breadth is
checking when they change: whether authentik's own invitation/signup flow stays something only accepted on purpose: no access policy is bound to the `audiobookshelf` application, and
Frank drives, and whether an access policy should be bound to the `audiobookshelf` application the wide auto-registered default (every library, downloads on) is **not a defect to fix** —
to narrow who may even reach the login. Revoking one person is a disable/delete of their ABS Frank's call, 2026-11-03. Narrowing stays a per-account judgement in **Settings → Users**.
user; revoking everyone is that policy. The one thing still worth watching is authentik's own invitation/signup flow: it must
remain something only Frank drives, because an account created there is a listener the
moment it signs in. Revoking one person is a disable/delete of their ABS user; revoking
everyone is that signup flow.
Both halves — authentik's provider row and ABS's settings — are asserted end to end by the Playwright gate named in *Verification*. `23-` signs in as `qa-e2e-admin` and must land inside the app with site-admin rights; `24-` signs in as the standard identity, which is in no Audiobookshelf group, and must land as a listener. Together they pin the escalation and the default: a mapping that stops granting silently locks the household out, and a mapping that over-grants turns the household into site admins. Both halves — authentik's provider row and ABS's settings — are asserted end to end by the Playwright gate named in *Verification*. `23-` signs in as `qa-e2e-admin` and must land inside the app with site-admin rights; `24-` signs in as the standard identity, which is in no Audiobookshelf group, and must land as a listener. Together they pin the escalation and the default: a mapping that stops granting silently locks the household out, and a mapping that over-grants turns the household into site admins.