By default, a “code embed” of an asset can be included in any website but it’s possible since As of version
| Status | ||
|---|---|---|
|
This feature can be used to restrict embedding to your own domain and subdomains ( ex : e.g. *.mycomanymycompany.com) . A finest case would be to only limit the embedding of sensitive assets or to a precise specific domain ( ex : e.g. https://futureproducts.mycompany.com). Note : It's worth noting that this feature can be used with or without tokenisation of medias but those two features are not related.
In this article, we will see how to implement this feature.
General principles
Embedding protection is implemented by a mix of CSP Headersindependently of media tokenization, although combining the two can provide additional protection.
How is this protection working?
To implement this feature, Wedia uses a combination of Content Security Policy (CSP) headers, X-Frame-options Options headers, and server detection of the referer to try to limit the embedding of a player on most modern browsers on market.
CSP headers
...
are used by recent browsers
...
like Firefox, Chrome, Safari,
...
and Edge, while the X-Frame-
...
Options header is used in conjunction with referer protection to deal with older browsers like
...
Therefore, protection is mainly achieved by browser and so it’s always possible to fetch media by code or some other means. To achivieve better protection, add some tokenisation to your medias.
Simple use case : apply a global limitation
For this use case, all we have to do is filling the parameter “CSPAllowedAncestors” on a MediaCloud customer config. Some examples Internet Explorer.
There are two main use cases for this feature:
Option 1 : General domain limitation for all assets
applying a global limitation to all assets, or limiting the embedding of specific assets. In the simple use case, you can use the "CSPAllowedAncestors" parameter in the MediaCloud customer config to specify the domains or websites where embedding is allowed. This can be a single hostname, a specific subdomain, or multiple rules separated by spaces. Please contact your account manager to set it up:
Limit embedding to one hostname : http://www.acme.com
Limit embedding on the same host and only whith https : https://www.acme.com
Limit to any subdomain : *.acme.com
Limit to any https subdomain : https://*.acme.com
We can have multiple rules separated by spaces : https://site1.acme.com https://site2.acme.com
...
Option 2 : Limit embedding per asset
For a finer grained authorization, you have the flexibility to implement specific rules for each asset. For example, you may only want to allow private assets to be embedded on a single website, or you may want to set different CSP rules for different assets. You can also allow certain "known embedding rules" to be applied by asset contributors. This use case requires more steps to set up, but it gives project managers greater control over the embedding of their assets.
This use - case needs some steps because it gives more room to projects managers to implement any kind of rule :
...
Whatever the use case, the steps are the same :
Define a new DAMDY Behaviour on a project or modify an existing one by setting the “evp.behaviours” on WXM_DAMDY plugin.
...
2. Implement the following method in your groovy file
...