admin/memby
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.2.65 - End Credits wiring / Gateway: 0.1.45 - Credits

Browse Source
This commit is contained in:
ponzischeme89
2026-08-15 21:11:43 +12:00
parent d5d47473a2
commit e528d04b43
19 changed files with 574 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files
server/README.md
+16 -4
View File
@@ -331,15 +331,27 @@ leaves the server. `MEMBY_RADARR_TTL` controls the shared calendar cache lifetim
`https://mserver.sublogue.com/admin/` — a self-contained console for library imports,
maintenance, engagement and journeys. Set `MEMBY_ADMIN_TOKEN` to enable it; unset, every
`/admin` route 404s so it cannot be left exposed by accident. The page first uses the same
discreet Emby login gate as the private installer. After successful verification it
discreet Emby login gate as the private installer, and additionally requires that the
account **administers Emby** — `Policy.IsAdministrator`, which Emby returns with the
authentication itself, so the check costs no extra request. Knowing a household password
is not the qualification for reaching the console: `/install` is public by design, and any
viewer may sign in there. A refusal is worded exactly as a wrong password, so nothing
discloses that the account was right but the person is not an administrator; the operator
sees the reason in the log. An Emby that returns no policy at all is asked directly rather
than read as a refusal, and one that will not answer refuses the sign-in — silence is
never taken as permission.
The two sign-ins issue the *same* cookie, so they are separated by being signed with their
own purpose: an installer session cannot satisfy the console's gate, while an
administrator's session satisfies the installer's. After successful verification the page
establishes the HttpOnly admin cookie, but browser API requests require both that cookie
and the current 12-hour Emby-verified session. The old admin cookie therefore cannot
and the current 90-day Emby-verified admin session. The old admin cookie therefore cannot
bypass the gate after the browser session expires. Scripts may continue to use
`Authorization: Bearer <MEMBY_ADMIN_TOKEN>` without a browser session.
Those 12 hours are idle time, not a hard limit: opening an admin page, making any change,
Those 90 days are idle time, not a hard limit: opening an admin page, making any change,
or reading one while interacting with it slides the expiry forward once it is inside the
last six hours. What deliberately does **not** extend it is the page's own status
last 45 days. What deliberately does **not** extend it is the page's own status
poll — a console left open on a second monitor still times out, which is the whole point
of the TTL. The page marks its own requests with `X-Memby-Admin-Active` when there has
been interaction in the last five minutes, and on a 401 it reloads, so an expiry lands as