RD-API-Server v1.4.4

The browser remote desktop works. This release fixes the last of three faults that shared one symptom, and is the first verified end to end against a live peer.

The viewer could not load its own scripts

Its HTML is served from an application route, not from the directory the file lives in, and relative URLs resolve against the document's address. src="./viewer.js" on /admin/remote/frame asked for /admin/remote/viewer.js, which does not exist. One 404 stops the entire module graph — nothing runs, and the page renders as bare HTML: a manual connection form asking for an ID server and a base64 key that had been injected correctly a line above.

The served document now carries a <base> pointing at the published assets.

The trailing slash on that base is load-bearing, and Laravel's asset() strips it. Without one, the last path segment is treated as a filename and every relative URL still resolves a directory too high — the same 404, from a <base> that looks correct. That variant was caught only because the fix was checked in a browser rather than assumed.

Verified end to end

For the first time, against a live peer through the published image:

Rendezvous and relay	Connected over WebSocket to hbbs and hbbr
Handshake	Encrypted; the plaintext-downgrade warning stayed hidden
Login	user@host · Windows reported by the peer
Video	H.265, 1920×1080, frames received = frames painted, no drops
Monitors	All four of the peer's displays enumerated
Input	None sent — the session was run view-only throughout

The session started when Connect was pressed, and not before.

A check for the wrong half of the key pair

An Ed25519 signing key is 64 bytes — a seed followed by the 32-byte public key — and RustDesk writes both halves to disk with confusingly similar names. RUSTDESK_KEY wants the public one.

Configuring the private half is not a cosmetic typo. That value is handed to every client and to the viewer, so the key whose entire purpose is to prove the server's identity gets published to anyone who requests a client configuration — and anyone holding it can impersonate the ID server to every client on the deployment. It also does not work: hbbs compares the presented key against its own and refuses with a licence mismatch.

The diagnostics page now recognises a 64-byte value, says what it is, prints the correct public key extracted from it, and says to rotate the pair. A value that is neither 32 nor 64 bytes of base64 is reported too.

Found by configuring a test deployment from a real one and watching hbbs refuse it.

Upgrading

docker compose pull && docker compose up -d

No migration and no configuration change. Then open System → Remote diagnostics and press Test from this browser — the browser, not the container, is what has to get through your reverse proxy, so it is the one check this server cannot make on your behalf.

Image

ghcr.io/gigaionllc/rustdesk-api-server:1.4.4

Multi-architecture (AMD64/ARM64), digest sha256:8b3561625c8d09bec29c2912fb2fd7cfb371a22ed43209322fdefa7f3e2d6254. The latest, 1 and 1.4 tags point at the same manifest.

Verification

662 PHP tests, 253 web-client unit tests, 15 browser tests, Pint and PHPStan. The new regression test loads the real viewer route and resolves every URL the served document references the way a browser would; it was confirmed to fail without this fix before being kept.

---

Full notes: docs/releases/v1.4.4.md

RD-API-Server is an independent, third-party, open-source project. It is not affiliated with, endorsed by, or sponsored by RustDesk or Purslane Ltd.