Proper Video Player Documentation

Token-Authenticated Streams

Protected media can use a token in the URL, browser cookies, or custom request headers. Configure cookies or headers before calling Open.

Tokens in the URL#

Signed URLs and query-string tokens require no player-specific configuration. The URL is passed to the active backend unchanged and works whenever that backend supports the source type.

player.Open("https://stream.example.com/video.m3u8?token=TOKEN&expires=1760000000");

Call SetUseCredentials(true) before Open to use credentialed CORS for media requests. This mode applies to progressive sources, native HLS, and the HLS/DASH JavaScript engines.

player.SetUseCredentials(true);
player.Open("https://protected.example.com/stream.m3u8");
Server requirements

Credentialed cross-origin responses must include Access-Control-Allow-Credentials: true and an explicit Access-Control-Allow-Origin value. The wildcard * is not valid with credentials. Cookies must also satisfy the browser's SameSite, Secure, and third-party-cookie policies.

Custom request headers#

SetRequestHeader applies a header to HLS and DASH manifest, playlist, segment, and key requests on WebGL. Set at least one header before Open so the streaming engine installs its request hooks.

player.SetRequestHeader("Authorization", "Bearer " + token);
player.Open("https://protected.example.com/stream.m3u8");

// Subsequent requests use the replacement value without reopening the stream.
player.SetRequestHeader("Authorization", "Bearer " + refreshedToken);

Header lifetime#

  • Headers persist across Open calls.
  • Setting an existing header again changes the value used by subsequent streaming requests.
  • Pass null as the value to remove one header, or call ClearRequestHeaders() to remove all headers.

Limitations#

  • Browsers do not provide a custom-header hook for progressive <video src> requests. Use a URL token or cookies for MP4, WebM, and other progressive sources.
  • A non-simple custom header generally triggers a CORS preflight. The server must accept the OPTIONS request and list the header in Access-Control-Allow-Headers.
  • Native HLS cannot receive custom headers. When headers are configured, the player routes HLS through hls.js instead; this requires hls.js and Media Source Extensions support in the browser.
  • Standard AES-128 HLS key requests use the same hls.js header and credential configuration. EME DRM systems such as Widevine, FairPlay, and PlayReady are not supported.

Platform support#

SupportsRequestHeaders reports whether the active backend provides the WebGL HLS/DASH header path. It is false on the Unity VideoPlayer fallback, where header and credential methods are no-ops. URL tokens remain available there, subject to the fallback's source-format support.