Extended Example of Rights Locker

This scenario illustrates a complete, end-to-end example of how Rights Locker works in operation, including two of the APIs that are part of Rights Locker.

The idea is to manage entitlements for a Video on Demand (VOD) asset. A viewer account can then be granted access to the content (with Rights Locker API). At the time of playback, the system checks if the authenticated user account is authorized to access a given piece of content.

In the example below, the asset is my_asset_id. Similarly, with the Backlot API, you can either create a publishing rule or use an existing one. In this example, the user decides to reuse the publishing rule ID my_publishing_rule_id.

  1. Update the publishing rule my_publishing_rule to set the require_user_entitlement field to true. Make a request to the Backlot API server at https://api.ooyala.com.
    [PATCH]/v2/publishing_rules/my_publishing_rule_id{  
       "secure_playback_token":{  
          "enabled":true,
          // expiration time is in seconds 
     "expiration":600,
          "require_user_entitlement":"true"
       }
    }
  2. Add an entitlement for the viewer account identified as gz7XwF_1p2qYM to the asset using the creation route for Rights Locker detailed in Rights Locker API Reference. (The account ID is actually constructed with something like the algorithm described in Your Users, Your Accounts: Security so that only the provider knows who the actual viewer is.) Make a request to the Rights Locker API server at http://rl.ooyala.com:
    [POST]/v2/entitlements/providers/932nf90r3mkoewfmungedID/accounts/my_account_id/content{  
       {  
          “assets”:[  
             {  
                “content_id”:“my_asset_id”,
                “publishing_rule_id”:“my_publishing_rule”,
                “external_product_id”:“12345”,
                “start_time”:20130902,
                “end_time”:20140902
             }
          ]
       }
    }
    The viewer with account my_account_id has now be given an entitlement to asset my_asset_id, according to the rules specified by the my_publishing_rule_id publishing rule.
  3. At playback, send a request for authorization to Ooyala’s authorization servers.

    The example below (split across several lines for readability) shows an authorization request with an embedded, URL-encoded Ooyala Player Token (OPT), including the user's account ID (account_id%3Dmy_account_id).

    Make a request to the http://player.ooyala.com authorization service:

    [GET] http://player.ooyala.com/sas/player_api/v1/authorization/embed_code/my_asset_id?domain=test.com& supported_formats=smooth&embedToken=http%3A%2F%2Fplayer.ooyala.com%2Fsas%2Fembed_token%2FFoeG1Q2jqbkH9m%2FU5MHg0YTHZIPHGNsr%3F account_id%3Dmy_account_id%26api_key%3DFo%26expires%3D1376069474%26signature%3DnSYMwiVFzbGE5O%252BWhEbXvm1M

    The system retrieves the asset and assigned publishing rules. The system then checks if the user account is authorized based on those rules, as described in How Authorization Works.

    In the majority of cases (based on the Ooyala Player without customization), verification of entitlement occurs automatically with your calls to the Player Authorization API; no additional programming is required, as long as you have setup the prerequisite configuration for Rights Locker described in Prerequisites to Rights Locker.

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