kenzuya/unshackle
1
0
Fork 2
mirror of https://github.com/unshackle-dl/unshackle.git synced 2026-11-14 13:05:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(remote): license with the client's device when the user picked one

Browse Source 
A remote client that passes --cdm, has a cdm entry for the service that named the loaded device, or sets server_cdm: false now declines the server CDM at session create, and warns when the server keeps it. A service option listed in SERVER_DEVICE_OPTIONS keeps the server CDM.
This commit is contained in:
imSp4rky
2026-10-01 13:21:53 -06:00
parent af17bad010
commit 9a1abd23b6
14 changed files with 292 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/configuration/drm.md
+8
View File
@@ -13,6 +13,14 @@ Resolution is case-insensitive: an override (`dl --cdm <name>`, or the `cdm` fie
job) wins, then the per-service entry, then `default`. An override pins one device for the whole
run and skips any quality or Widevine/PlayReady sub-entries.
Over `--remote`, an override also makes your device license the remote session, not the server
CDM. A per-service entry does the same when it names a device without a quality: a device name,
a `widevine` or `playready` sub-entry, or a profile or `default` sub-entry. A per-service entry
that selects only by quality, or only for a different profile, loads no device when the run
starts. unshackle then shows a warning, and the server decides who licenses the remote session.
With only the top-level `default` entry, the server CDM licenses when the API key has it. See
[`remote_services`](services.md#remote_services).
```yaml
cdm:
default: chromecdm_l3
docs/reference/configuration/services.md
+15
View File
@@ -89,6 +89,15 @@ overrides such as `title_map`.
Leave `server_cdm` unset and the client follows the server: it uses the server CDM for each
service the API key has it on, and the local CDM for the others. `true` asks for the server CDM
and falls back to the local CDM when the server refuses; `false` always uses the local CDM.
`dl --cdm <name>` on a remote run has the same effect as `false` for that run: the device you
name licenses the remote session. A [`cdm`](drm.md#cdm) entry for the service has the same
effect for that service when it names the device that unshackle loaded. Both take priority over
`server_cdm: true`. Remove the entry to use the server CDM for that service. The `default`
entry does not count.
The server has the last word. When it keeps the server CDM for a remote session that your
device was to license, unshackle shows a warning. This occurs with a server that does not read
your choice, and with a service option that runs the remote session on the server's device.
`auth_headers` lists extra header names to send the API key in, tried before the defaults
`X-Secret-Key` and `X-Api-Key`, which unshackle always appends as fallbacks. It sends the
@@ -154,6 +163,12 @@ client that asks anyway gets a `FORBIDDEN` error. Because a download job always
an API key without `server_cdm` for that service also cannot submit or retry `/api/download`
jobs. Keys that have no `users` entry, such as `api_secret`, keep server CDM access.
A remote client that picks its own device licenses the remote session with that device. It picks
with `dl --cdm`, with a `cdm` entry for the service, or with `server_cdm: false` in its
`remote_services` entry. The server CDM makes no licence for that remote session, with or without
a limit. A service option that runs the remote session on the server's device, such as a
server-identity flag, keeps the server CDM.
`server_cdm_max_height` limits the live licences the server's device makes for that API key.
Set it to a height in pixels for every service, or to a map of service tag to height with an
optional `default` entry. A service the map does not name or sets to `null` gets the `default`, and