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 9c9e059 with MkDocs version: 1.6.1

Browse Source
This commit is contained in:
2026-09-20 03:44:18 +00:00
parent 887d1dfcb7
commit b7b490080c
5 changed files with 66 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dev/rest-api/remote-sessions/index.html
+24 -9
View File
@@ -2494,11 +2494,13 @@ server does not have to prompt:</p>
the client region itself</li>
<li>Track-selection hints (<code>range_</code>, <code>vcodec</code>, <code>quality</code>, <code>best_available</code>) so
the server fetches the right manifests</li>
<li>Your local per-service <strong>cache files</strong> (e.g. refreshed tokens), but only the
files for the active profile. The client withholds a file whose name embeds
a hash of another credential, or the name of another profile. One profile's
tokens therefore never reach the server while you use a different profile.
At worst, a withheld file makes the server authenticate again</li>
<li>Your local per-service <strong>cache files</strong> (e.g. refreshed tokens), including
files in subdirectories of the service cache directory, but only the files
for the active profile. The client withholds a file whose path, in any
directory or file name, embeds a hash of another credential or the name of
another profile. One profile's tokens
therefore never reach the server while you use a different profile. At
worst, a withheld file makes the server authenticate again</li>
</ul>
<p>The server uses its own accounts only when the operator lists the service in
<code>serve.server_accounts</code> and gives your API key <code>server_accounts</code> in <code>serve.users</code>.
@@ -2884,11 +2886,24 @@ returns <code>{ "status": "accepted" }</code>. A post with no pending prompt is
</span></code></pre></div>
<p>The handler writes forwarded <code>cache</code> files into that directory before authentication.
On <code>DELETE</code>, when the login belongs to the client (<code>client_auth</code>), the handler
harvests updated cache files (compressing each with zlib and base64-encoding,
<strong>excluding</strong> <code>titles_*</code> files) and returns them under a <code>cache</code> field, so the
client can keep refreshed tokens:</p>
<div class="language-json highlight"><pre><span></span><code><span id="__span-9-1"><a id="__codelineno-9-1" name="__codelineno-9-1" href="#__codelineno-9-1"></a><span class="p">{</span><span class="w"> </span><span class="nt">"status"</span><span class="p">:</span><span class="w"> </span><span class="s2">"ok"</span><span class="p">,</span><span class="w"> </span><span class="nt">"cache"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="nt">"tokens"</span><span class="p">:</span><span class="w"> </span><span class="s2">"...base64(zlib(bytes))..."</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="p">}</span>
harvests updated cache files from the whole directory tree (compressing each
with zlib and base64-encoding, <strong>excluding</strong> <code>titles_*</code> files) and returns them
under a <code>cache</code> field, so the client can keep refreshed tokens. Each cache key
is the file path relative to that directory, with <code>/</code> separators and no <code>.json</code>
suffix, which is the <code>Cacher</code> cache key the service reads it with:</p>
<div class="language-json highlight"><pre><span></span><code><span id="__span-9-1"><a id="__codelineno-9-1" name="__codelineno-9-1" href="#__codelineno-9-1"></a><span class="p">{</span>
</span><span id="__span-9-2"><a id="__codelineno-9-2" name="__codelineno-9-2" href="#__codelineno-9-2"></a><span class="w"> </span><span class="nt">"status"</span><span class="p">:</span><span class="w"> </span><span class="s2">"ok"</span><span class="p">,</span>
</span><span id="__span-9-3"><a id="__codelineno-9-3" name="__codelineno-9-3" href="#__codelineno-9-3"></a><span class="w"> </span><span class="nt">"cache"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span>
</span><span id="__span-9-4"><a id="__codelineno-9-4" name="__codelineno-9-4" href="#__codelineno-9-4"></a><span class="w"> </span><span class="nt">"tokens"</span><span class="p">:</span><span class="w"> </span><span class="s2">"...base64(zlib(bytes))..."</span><span class="p">,</span>
</span><span id="__span-9-5"><a id="__codelineno-9-5" name="__codelineno-9-5" href="#__codelineno-9-5"></a><span class="w"> </span><span class="nt">"session_web/&lt;sha1&gt;"</span><span class="p">:</span><span class="w"> </span><span class="s2">"...base64(zlib(bytes))..."</span>
</span><span id="__span-9-6"><a id="__codelineno-9-6" name="__codelineno-9-6" href="#__codelineno-9-6"></a><span class="w"> </span><span class="p">}</span>
</span><span id="__span-9-7"><a id="__codelineno-9-7" name="__codelineno-9-7" href="#__codelineno-9-7"></a><span class="p">}</span>
</span></code></pre></div>
<p>Both sides reject a cache key with a drive letter, a root, a <code>..</code> segment, an empty
segment, or more than 8 segments before it becomes a path, so a peer cannot write
outside the cache directory. Both sides also refuse a <code>cache</code> map with more than
64 entries. The server skips a cache key it cannot write, such as one that names an
existing file as a directory, and logs a warning.</p>
<h3 id="remote-session-info-response">Remote session info response<a class="headerlink" href="#remote-session-info-response" title="Permanent link">&para;</a></h3>
<p><code>GET /api/session/{id}</code>:</p>
<div class="language-json highlight"><pre><span></span><code><span id="__span-10-1"><a id="__codelineno-10-1" name="__codelineno-10-1" href="#__codelineno-10-1"></a><span class="p">{</span>