Player Security FAQ

Frequently asked questions about Player security

Widevine Modular

Note: Ooyala Player V3 has been deprecated and is scheduled to be disabled. For details and alternatives, see the OVP Release Notes.

Q: What version does Ooyala support?

A: Widevine Modular is a 3rd party content protection mechanism that Ooyala supports as part of its overall content protection offering. Widevine Modular supports playback on Mobile with our SDKs. Customers might also use a Widevine Modular-based app on connected TV devices.

Wideview version releases are updated on a regular basis and are tested by Ooyala to ensure compatibility. As you prepare your implementation, please check with us directly to validate that there are no compatibility issues with the Widevine version that you are interested in using.

For more information about using Widevine with the Ooyala video platform, see the following documentation:

Q: Why are my videos not playing in Safari or another browser?

A: One of the first items to check is the browser and browser version. You can check what browser versions we support in our Player Requirements documentation.

Basically, the video bytes are not getting to the client. Some items that might impact the video playback in Safari and other browsers are:
  • Authorization issues (most common):
    • You may not have the correct encoding to play on your device of choice. Encoding refers to each transcoded file (specified by video bit rate, content width, audio bit rate, and delivery method).
    • If you are using content protection you may have compatibility issues with your browsers and devices. For example Widevine Modular only works with our SDKs and connected TVs.
  • Browser issues:
    • Video errors and/or failures can occur when using a Flash player on a browser where third-party cookies are disabled. Given that Safari blocks Flash Access cookies, if you are using a Flash player, your viewers can have issues with video playback. You may need to stipulate the use of a non-Safari browser when using a Flash player and Adobe Access.
    • Safari’s blocking of cookies can also have an impact on VAST ad management integration with our player. This may impede playback. You should test playback on other browsers.
  • Profile Setting issues:
    • You may have issues with bitrate settings, transcoding, or other overhead. In these cases you many need to contact Ooyala Technical Support to adjust your profile.
In all cases, try testing the video by creating a web page with just the video embed and no apps or other code on Safari and other browsers. If you cannot resolve the issue, you need to open a help ticket and supply your system information and your logs. You can also use the Ooyala Chrome Extension for Debugging/Troubleshooting to help you work with support.

Q: Which policies are supported at this time?

A: Ooyala gives you the ability to choose from multiple pre-defined policies. These policies are determined at license issuance time so that a piece of content can be packaged once but authorized for different policies (e.g., renting a movie vs. purchasing a movie). Since these policies may vary over time, you should check with your Customer Success Manager (CSM) or Technical Support contact for the supported policies.

You can also review our documentation about various content protection policies:
  • DRM Policies list the types of policies available in general. You can use this information as a starting point and ask your Customer Success Manager for the specific policies that we support.
  • Configurable DRM describes existing policy types and shows an example of a single policy (with its id).
  • Assigning a DRM Policy describes how you use the Backlot REST API to assign a policy.
An Ooyala Customer Success Manager or Support Engineer must set up your policies before you can assign them to assets.

Q: I'm getting the error "License Server Unavailable." What now?

A: A “License Server Unavailable” error indicates that a response from the Ooyala authorization server is not occurring. As this server is responsible for responding to authentication and token requests, the error can indicate:
  • You may have reached a device limit for an account. See the Device Registration section later in this topic.
  • Your Widevine Modular implementation may not be set up correctly. You may need to send the production keys for Widevine to Ooyala. These keys include:
    • widevine_aes_iv
    • widevine_aes_key
    • widevine_portal_id
    For more information, see the Widevine documentation, our mobile iOS SDK Widevine documentation, our Android SDK Widevine documentation, and the Content protection Options By Device information.
  • Authentication problems. The viewer may not have created a login or password for their account with the provider and therefore authentication is blocked for the viewer.
  • You may not have set up a particular content protection mechanism correctly. For example:
    • If browser cookies are disabled, token authentication can fail (e.g. Ooyala Player Token).
    • Your customer may be using Chrome with Incognito mode enabled. Google’s choice is for Adobe Access to not operate when the user is in incognito mode. The customer may need to clear the Flash player licenses in the browser (not via the native Mac OS setting) by resetting the license files button in the “Protected Content Playback Settings Panel.”
  • Device Registration Failure.
  • Caching problems with the authorization server (SAS).
If you cannot resolve the issue, you need to open a help ticket and supply your system information and your logs . You can also use the Ooyala Chrome Extension for Debugging/Troubleshooting to help you work with support.

Adobe Pass

Q: What versions is Ooyala using and/or supporting?

A: Adobe Pass is a third party content protection mechanism that Ooyala supports as part of its overall content protection offering. Adobe Pass versions are updated on a regular basis and are tested by Ooyala to ensure compatibility. Contact your Ooyala Customer Success Manager to validate that there are no compatibility issues with the Adobe Pass version that you are interested in using.

For documentation about the process and requirements for implementing Adobe Pass, you can start with Content Protection Options by Device and then look at Integrating Adobe Pass with Ooyala Player and Steps for integrating Ooyala Player with Adobe Pass.

Player Token

Q: When is the Ooyala Player Token recommended?

A: The Ooyala Player Token (OPT) is in the category of user authorization tokens that ensures that encrypted content cannot be downloaded until the client has been verified and prevents content from being played in a non-Ooyala player.

Note: Available only if your Ooyala account includes this functionality. To enable Ooyala Player Token, contact your account manager.

This type of content protection is recommended in situations where there is the risk that authorized users can take the embedded player JavaScript (.js) script tag generated in Backlot and distribute it freely to others for replay, or engage in other similar replay attacks. The Ooyala Player Token authorization feature lets you (content publishers and providers) secure your content from these types of risks. You can use this authorization to protect your monetized content from unauthorized distribution.

The Ooyala Player Token requires client cookies, and they may have an impact on your decision to use it. If you cannot use cookies or have frequent situations where the cookies are blocked, you may need to select another content protection option. Ooyala also has a separate level of token security offered through CDN tokens. CDN tokens operate slightly differently than the Ooyala Player Token. The Ooyala Player Token secures playback within the actual Ooyala player while CDNs offer token protection over individual assets. Some CDNs offer token authentication to protect the stream itself, however we currently do not offer this feature.

We support the Akamai CDN. We only support the CDN token authentication, not combinations of CDN asset and stream-based content protection. For example, you can have Akamai TBA for an asset but not a combination of Akamai TBA and Akamai TBA for mp4 stream.

Q: Will the Ooyala Player Token prevent others from stealing my content?

A: The Ooyala Player Token can prevent the unauthorized access and distribution of your content but it does not cover all possible security breaches. Ooyala has a number of other content protection features that you can use to apply layers of security to your content. For an overview of the levels and layers of security that you can apply to your content, see the article, “Survey of Content Protection Technology" in our Support Center documentation.

Q: I'm getting the error "Invalid Token". Now what?

A: The error “Invalid Token” can have a number of root causes. Some of the cases include:
  • Incompatibility with other features or security mechanisms. For example, if you use Ooyala Player Token (OPT) with an audio player, Adobe Pass is not compatible with the audio player and this may result in an Invalid Token error.
  • If you use OPT with Widevine, or other security mechanisms, you need to make sure you send the token with the license request.
  • By default, some browsers, such as Apple Safari, disallow third-party cookies, which can interfere with your OPT or authorization requests.
You need to check all points of failure. You should also review the Ooyala Player Token documentation and the Content Protection Options By Device information. If you cannot resolve the issue, you need to open a help ticket and supply your system information and your logs. You can also use the Ooyala Chrome Extension for Debugging/Troubleshooting to help you work with support.

Q: What happens if a user's cookies are disabled. Will this affect the license request process?

A: Yes, because cookies are involved in the authorization check process. If the Ooyala Player Token(OPT) is enabled for an asset, the license request must contain the auth_token returned in the authorization server (SAS) response. This is because the license request also includes an authorization check and token. With OPT, the embedded player loading event triggers the communication of the token request URL to the player. The player then requests authorization and a token from the Ooyala authorization server (SAS), using the token request. Depending on whether the request made justifies playback, the authorization server returns either a valid cookie and authorized response or an invalid cookie and an unauthorized response is returned. We can see, in this case, if cookies are disabled on the end-user's browser, the auth check will fail and the license request will return a 'User is not authorized' error.

Adobe (Flash) Access (Deprecated)

Note: Ooyala integration with Adobe Access DRM has been deprecated and is scheduled to be disabled. For details and alternatives, see the OVP Release Notes.

Q: What version are we using?

A: Adobe Access is a 3rd party content protection mechanism that Ooyala supports as part of its overall content protection offering. Adobe Access versions are updated on a regular basis and are tested by Ooyala to ensure compatibility. Contact your Ooyala Technical Support to validate that there are no compatibility issues with the Adobe Access version that you are interested in using.

Q: My viewers are having trouble viewing my videos in Safari. What is going on?

A: Basically, the video bytes are not getting to the client. Some items that might impact the video playback in Safari are:
  • Video errors and/or failures can occur when using a Flash player and third-party cookies are disabled in the browser. Given that Safari blocks Flash Access cookies, if you are using a Flash player, your viewers can have issues with video playback.
  • If the videos are playing on more than one machine, you can ask the viewers to clear their token with the following instructions: http://helpx.adobe.com/x-productkb/multi/removing-flash-access-data-files.html. As Safari blocks third-party cookies, you might consider moving away from using cookies for token authorization. You can use the Play Ready auth_token as a query string parameter. For more information, see Play Ready Example.
  • The stream may require an embed/player token.
  • Issues with ad manager integration. In some cases issues with Safari have been noted with the VAST ad manager.
  • You can also check the version of Safari that your viewers using. Make sure it is a supported version. See our Player Requirements documentation for more information.
  • You should review the Adobe Access documentation and the Content Protection Options By Device information to make sure there are no compatibility issues.
  • You can try to isolate the issue by testing the video without Adobe Access enabled to determine if it an issue with the browser or with the Flash player or Adobe Access itself. You will need to work with Ooyala support by opening a help ticket to disable Adobe Access.
If you cannot resolve the issue, you need to open a help ticket and supply your system information and your logs. You can also use the Ooyala Chrome Extension for Debugging/Troubleshooting to help you work with support.

Q: Which DRM policies are supported at this time?

A: In general, Ooyala gives you the ability to choose from multiple pre-defined DRM policies. These policies are determined at license issuance time and can include policies issued on a package or more commonly issued as policies enforced on output controls (such as enforcing no playback if HDCP is not present).

For more details, see our documentation on DRM policies:
  • DRM Policies - lists the types of policies available in general. You can use this information as a starting point.
    Note: The Backlot API, flashaccess_policy, lists all the properties associated with an Adobe (Flash) Access policy.
  • Configurable DRM - shows an example of a single policy (with its id).
  • Assigning a DRM Policy - describes how you use the Backlot REST API to assign a policy.
We support other types of content protection policies. For example, you can find specific policies that Adobe Access supports at Adobe Access Usage Rules. If you are using content protection from a third party, check the documentation for information about supported policies. Since these types of content protection policies may vary over time, to find out the specific policies we support at this time, check with your Customer Success Manager (CSM).
Note: An Ooyala Support Engineer must set up your policies before you can assign them to assets.

Q: If a piece of content is packaged once and authorized for different policies, how does the player know when to enforce one policy or the other?

A: The license server applies a policy to the asset during runtime. The license server can override any policy attribute specified during packaging. Thus, policies are determined by the license server; the player gets a single policy applied to the asset.

Q: Is Flash Access supported on Android?

A: Flash Access (now called Adobe Access) is supported on Android Air and Android Native implementations. However, you need to be cognizant of all the various types of support for the different content protection mechanisms and how they interact. You can start by reviewing the article Content Protection by Device in our Customer Support documentation. You should also check with the manufacture as support may change. For example, more recent versions of the Android OS may not support Flash at all.

Q: I'm getting the error "License Server Unavailable". What now?

A: A “License Server Unavailable” error indicates that a response from the Ooyala authorization server is not occurring. As this server is responsible for responding to authentication and token requests, the error can indicate:
  • Authentication problems. The viewer may not have created a login or password for their account with the provider and therefore authentication is blocked for the viewer.
  • You may not have set up a particular content protection mechanism correctly. For example:
    • You customer may be using Chrome with Incognito mode enabled. Google’s choice is for Adobe Access to not operate when the user is in Incognito mode. The customer may need to clear the Flash player licenses in the browser (not via the native Mac OS setting) by resetting the license files button in the “Protected Content Playback Settings Panel.”
    • This error can occurred when an Adobe Access implementation is not been set up correctly. You should review the Adobe Access documentation and the Content Protection Options By Device information to make sure there are no compatibility issues.
  • Device Registration Failure.
  • Caching problems with the authorization server (SAS).
  • You need to check the points of failure that you can for your client page. For example, are you using Player token authentication and your customers have browser cookies disabled or are you using Adobe Access and your customers using Chrome in Incognito mode? To check this point of failure, read the specific documentation for the content protection mechanism you are using and the supported standards and requirements. You can find that documentation here and here.

Other areas to consider revolve around Ooyala’s authorization and license servers. If you cannot resolve the issue, you need to open a help ticket and supply your system information and your logs . You can also use the Ooyala Chrome Extension for Debugging/Troubleshooting to help you work with support.

Concurrent Streams

Q: How often will the player send a heartbeat to establish that a user is watching a video and concurrent streaming limits can be enforced?

A: The player sends a heartbeat every 5 minutes. For example: If a viewer stops watching a video 2 minutes after the last heartbeat, the viewer will not be able to watch another video for another 3 minutes.

Publishers who want to avoid imposing the waiting period between switching videos, can pass the auth_token along in the authorization request for the next video so that the same auth_id (this is used to determine a unique stream) can be used for the next video.

The auth_tokens do expire, but the auth_id can still be extracted from an expired auth_token (there is a separate expiry time for the auth_id). The auth_id expiration time is 10 minutes and is renewed on each authorization and heartbeat request. The values inside the auth_token are encrypted so the auth_id is not visible in plain text. Generally each authorization request will generate a new auth_id. However, if you pass an auth_token generated from a previous request as a query parameter in a new authorization request, our code will try to reuse the auth_id in the old auth_token (as long as it's not expired) and generate a new auth_token with the same auth_id.This allows you to switch between videos quickly without getting blocked for reaching the concurrent stream limit.

Q: Is concurrent streaming supported on the HTML5 player?

A: Yes.

Device Registration

Q: Are there any limits on calls made to the Device Management APIs?

A: No. The rate limits only applies for calls made to api.ooyala.com.

Q: When reaching a device limit for an account, what is the error provided by the player?

A: The player will throw a generic license server error. It is up to the publisher to determine what was the exact cause of the error. If device limits are being used, the publisher should call the last_result API after the DRM request. The last_result API will tell you what was the result of device registration (registration happens during DRM request). Here's more info about the last_result API:Device Registration API for Customer Support Portals.

Device limits are account wide. For example, if you have an account with a device limit of 3 and the PPV limit is only 1, only the first device that attempts playback will be allowed to watch the PPV. (Note that this device counts as one of the 3).

General

Q: How do I resolve the DRM Authorization error "User authorization failed" (Error code 3304 Suberror code 305)?

A: Make sure the viewer's browser has cookies enabled. Without cookies, there is no way to transmit the player token that you generated to authorize playback all the way through the Flash environment to our DRM server. Therefore, the license server does not authorize playback for the movie.

해당 내용이 도움 되었습니까?