How to Secure Your Videos on DynTube

DynTube gives you several independent protection layers. Each one answers a different question — where a video may be embedded, whether the stream is readable without a key, which player may play it, and who has to be signed in — and you combine the ones that match your risk.

• Domain Whitelisting
• Subscriptions & Access Control
• Video Encryption
• Extra Security
• Token Authentication

Domain Whitelisting

Domain whitelisting restricts which sites may play your videos. It is an account-level list: while it has entries, playback is only authorised for pages on those domains, and a request from anywhere else is refused with a 403 and a message saying playback is not available on that host.

Where to set it

1. In the dashboard, go to Settings, then Global.
2. The page opens on the Allowed Domains tab, which holds the Whitelist Domains list.
3. Choose Add Domain and enter one hostname per row, for example yourdomain.com.
4. Choose Save Domains.

How the allowed-domain list is enforced

• An empty list means no domain restriction at all. Whitelisting only starts protecting anything once there is at least one entry — until then, playback is not refused on origin grounds.
• Your plan caps how many domains you can add. The page shows how many of that allowance are in use, and Add Domain stops once you reach it. On plans without domain restrictions the tab is visible but read-only, and existing entries are kept rather than erased.
• The list is the account default. A project can override it with its own set of allowed domains, in which case that project’s list applies to its videos instead — including an empty override, which means that project is unrestricted.
• The hostname is the unit to rely on. Wildcard patterns are accepted and the dashboard suggests directory-style examples, but matching is attempted against the embedding page’s hostname first and only then against hostname plus path, so a path pattern is not a dependable access boundary on its own. If a section of a site must be protected, protect it with login or subscription access rather than with a path pattern.

Video Encryption

Video encryption on DynTube is HLS AES, set per project: each video is packaged with its own key, and the player must fetch that key from DynTube before it can decrypt and play the stream. Segments downloaded on their own are not playable without the key. It is not DRM — Certified DRM is a separate feature with its own plan grant, it requires CMAF output, and a project cannot have both.

Encryption and domain whitelisting are two settings that do different jobs, and one does not imply the other. Encryption decides whether the stream is readable without a key. The allowed-domains list decides which embedding hosts playback is authorised for. Turning encryption on does not limit where your videos can be embedded, and it does not populate your allowlist for you.

The key request is authorised before any key bytes are returned. What is actually checked:

• A valid, current playback token for that specific video is required. A key URL lifted out of a playlist is not usable on its own.
• Your allowed-domains list is applied to the key request only when that list is not empty. If the list is empty there is no origin restriction, so keys are served to any origin — encryption alone does not confine playback to your sites.
• The account option Allow encryption keys on all origins exempts key requests from the allowed-domains check. While it is on, keys are served regardless of the list, even a populated one.
• If the project that owns the video overrides domains, its own list is applied instead of the account list — including an empty override, which is unrestricted for that project.
• Country and IP restrictions, apps-only playback and any access gate on the content are evaluated on the key request as well.

Encryption governs conversions that run after you save it. Videos already converted keep the packaging they were produced with; saving the project does not re-encrypt existing output. To protect an already-converted video, put it through a fresh conversion once the setting is on. See How to Turn On Video Encryption for the full procedure and the combinations the server refuses to save.

Extra Security

Extra Security answers a different question from encryption: not “is the stream readable without a key”, but “which client may obtain the key”. With it off, any player that can follow the manifest and request the key — including third-party and command-line players — can decrypt an encrypted video. With it on, the ordinary key endpoint refuses to hand the key over, and the DynTube player gets it through a separate validated request that only exists for Extra Security videos.

Two clients are exempt from that refusal, and you should know both before you rely on the setting: an authenticated DynTube native-app session, and any request whose browser identification says iPhone — a legacy allowance for iOS’s built-in HLS playback. The second is a header match, and a header can be sent by anything. Extra Security reliably stops ordinary third-party players; it is not a barrier against someone deliberately imitating an iPhone.

• Set it per project, under the project’s Video Options, to apply to that project’s videos, or per video on the video’s Options tab. The dashboard states the effect plainly: “Video streams only play inside the DynTube player. Encrypted API playback on third-party players is blocked.”
• It only means something for encrypted videos. Extra Security governs the encryption-key handoff — an unencrypted video has no key to withhold, so turning it on there changes nothing.
• It is a plan feature. On current plan defaults it is included with Pro and Enterprise, and your account may be configured differently.

Token Authentication

Token authentication gives you a signed HLS URL for playing a video outside the DynTube player — a custom web player, a native mobile app, a set-top client. You mint it on your own server from your account’s security key (Settings → API keys), so the key itself never reaches the viewer, and the platform re-computes the signature on every request.

The signature covers the expiry and the optional restrictions as well as the video, so a tokenised URL cannot be edited: change the expiry, the country list or the IP list in the query string and the signature no longer matches, and playback is refused.

The legacy token format also accepts a views value, and it is signed into the hash like the others, but nothing counts plays against it: a tokenised URL is not consumed after a set number of views. Do not build a licence model, a per-purchase unlock or a rental on that parameter — the enforced controls are the expiry and, conditionally, the IP and country binding. Full parameter order, the hashing steps and code samples are on the Token Authentication page in the API reference.

Subscriptions & Access Control

Subscription protection is two mechanisms, and both have to be configured before anyone can watch:

• Authentication — must the viewer be signed in? This is the Authentication card on a video’s Options tab, or the same switch in a project’s Video Options as a project-wide default. It requires access; it does not grant it.
• Entitlement — which signed-in viewers may watch? This comes from the access scope of your plans. Playback works out which plan keys a video requires and checks them against the viewer’s active plans.

Plans are managed under Monetization → Plans & Payments (/subscriptions/plans), with renewal periods such as daily, weekly, monthly or yearly, or access for a set number of days. Your viewers exist as Subscribers (/subscriptions/subscribers) — this is the modern subscriber identity that current playback authorises against. Both need the Subscriptions feature on your plan.

Next Steps

• How to Turn On Video Encryption
• How to Add Login Protection to Videos
• Screen Recording & Download Prevention