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

Deployed 5b0369e with MkDocs version: 1.6.1

Browse Source
This commit is contained in:
2026-10-07 15:04:22 +00:00
parent ab7534754f
commit 53e2d835d3
7 changed files with 1081 additions and 976 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dev/rest-api/endpoints/index.html
+1 -1
View File
@@ -4813,7 +4813,7 @@ the newlines must go out at once.</p>
</div>
</div>
</div>
<p><code>server_account</code> is <code>true</code> when the server authenticated with one of its own accounts (<code>serve.server_accounts</code>). Otherwise the server uses only what the client sent, and never falls back to its own credentials. Only a client that sent its own cookies, credentials, or cache files gets cookies, auth headers, and the remote session cache back. A client that answered a login prompt (a device code or an OTP) gets them too. This applies only when the login then succeeds and the remote session does not use a server account. For any other remote session (a server account, or an anonymous login through the server's proxy) the tracks and segments responses carry no cookies and no auth headers. The server also drops secret-looking keys from track data, and the cache stays on the server. A server-account service also refuses a client proxy URI, because the server's login would pass through it.</p>
<p><code>server_account</code> is <code>true</code> when the server authenticated with one of its own accounts (<code>serve.server_accounts</code>). Otherwise the server uses only what the client sent, and never falls back to its own credentials. When the login succeeds and the remote session does not use a server account, the login belongs to the client, and the client gets cookies, auth headers, and the remote session cache back. A remote session on the server's device is the exception: the client gets its cookies back, but no auth headers and no cache. For a server-account remote session the tracks and segments responses carry no cookies and no auth headers. The server also drops secret-looking keys from track data, and the cache stays on the server. A server-account service also refuses a client proxy URI, because the server's login would pass through it.</p>
<table>
<thead>
<tr>
dev/rest-api/remote-sessions/index.html
+3 -3
View File
@@ -2608,9 +2608,9 @@ completion, and also when <code>dl</code> exits early (<code>--list</code>, Ctrl
deletes the remote session. If the login belongs to the client, the <code>DELETE</code>
request returns the updated cache files (for example a refreshed token) and the
client saves them locally, so the <strong>next</strong> 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,
authentication. The login belongs to the client when it succeeds and the
remote session does not use a server account. This includes a pair code that
the user approves on another device. A server-account login never does,
and neither does a remote session on the server's device (see below).
The client saves only the returned files that pass the same profile check it
applies before it sends them, so a file for another profile cannot overwrite