fix(remote): return session cache for device-code and cache-only logins

Answered login prompts and uploaded cache now count as client auth; the client closes on exit and keeps the remote session alive during long downloads.
This commit is contained in:
imSp4rky
2026-09-16 19:36:31 -06:00
parent aec45e30cc
commit ffda836442
10 changed files with 222 additions and 18 deletions
+14 -7
View File
@@ -195,10 +195,16 @@ hood the client walks a remote session through its lifecycle.
=== "5. Download + close"
The client downloads, decrypts, and muxes locally. On completion it deletes
the remote session. If the server has updated cache files (for example a refreshed
token), the delete returns them and the client saves them locally, so the **next**
remote session can skip interactive auth.
The client downloads, decrypts, and muxes locally. While it works, it sends a
keep-alive request to the remote session at an interval of one third of
`session_ttl`, so a long download does not let the remote session expire. On
completion, and also when `dl` exits early (`--list`, Ctrl+C, an error), it
deletes the remote session. If the login belongs to the client, the `DELETE`
request returns the updated cache files (for example a refreshed token) and the
client saves them locally, so the **next** remote session can skip interactive
authentication. The login belongs to the client when the client sent
cookies, credentials, or cache files, or answered a login prompt (a device code
or an OTP) that led to a successful login. A server-account login never does.
!!! tip "Renaming remote titles locally"
You can rename titles for a remote service you do not have installed locally by
@@ -423,9 +429,10 @@ _sessions/<pbkdf2_hmac(sha256, X-Secret-Key, "unshackle-session-ns", 100000)[:12
```
The handler writes forwarded `cache` files into that directory before authentication.
On `DELETE`, the handler harvests updated cache files (compressing each with zlib
and base64-encoding, **excluding** `titles_*` files) and returns them under a
`cache` field, so the client can keep refreshed tokens:
On `DELETE`, when the login belongs to the client (`client_auth`), the handler
harvests updated cache files (compressing each with zlib and base64-encoding,
**excluding** `titles_*` files) and returns them under a `cache` field, so the
client can keep refreshed tokens:
```json
{ "status": "ok", "cache": { "tokens": "...base64(zlib(bytes))..." } }