Purchase access to watch this video.

Unlock course for £159

Already purchased access? Login

Adding playback restrictions to secure video playback

Connect GitHub

Transcript was automatically generated and may be inaccurate.

  1. –

    Whilst it's all good being able to play videos, it's not good if some body can
  2. –

    copy the video
  3. –

    attack from your web page, put it on their own web pages, and then begin
  4. –

    streaming your
  5. –

    content, especially if you're placing this content behind a paywall and require
  6. –

    customers
  7. –

    to purchase access in order to view it.
  8. –

    To combat this, Mux allows you to create playback restrictions.
  9. –

    At their simplest, playback restrictions specify the hostnames that a video can be
  10. –

    watched, so
  11. –

    if you have a website foo.com and you add a playback restriction for foo.com,
  12. –

    the video
  13. –

    would not play on a web page host doing a bar.com or indeed any other domain.
  14. –

    We can create playback restrictions via the Mux API.
  15. –

    This is something you'll only need to do once, so this makes a good candidate
  16. –

    for an
  17. –

    Artisan command.
  18. –

    Let's create a new Artisan command, called "CreateMuxPlaybackRestrictionCommand".
  19. –

    We'll use the playback restrictions API class from the Mux SDK, so we'll need
  20. –

    to
  21. –

    again go back to our Mux service provider class and add a binding for this,
  22. –

    just like
  23. –

    we did with the configuration and direct uploads API.
  24. –

    If we go back to our Artisan command class, we can now type hint this class in a
  25. –

    constructor.
  26. –

    We need to create a new "CreatePlaybackRestrictionRequest" instance.
  27. –

    We'll set the "allowed_domains" as an argument.
  28. –

    And also set "allow_no_referrer" to "false".
  29. –

    For the "allowed_domains", we can accept this as an argument from the command.
  30. –

    Let's also update our command signature.
  31. –

    And add that argument.
  32. –

    Now that we have the request, let's send it to Mux.
  33. –

    And if the request was successful, let's print the ID of the newly-created
  34. –

    playback restriction.
  35. –

    Let's run the command.
  36. –

    We also need to specify a hostname as an argument, so far we've been using
  37. –

    localhost to access
  38. –

    our application.
  39. –

    However, we're going to need to use the IP address 127.0.0.1 instead, as Mux
  40. –

    playback restrictions
  41. –

    don't allow the hostname localhost.
  42. –

    Run the command.
  43. –

    And it looks like we forgot to call the parent constructor in our command's
  44. –

    constructor.
  45. –

    Let's go fix that.
  46. –

    Simply add "parent::__construct".
  47. –

    Try running the command again.
  48. –

    And you see we've now got a playback restriction ID.
  49. –

    Let's copy this into a new environment variable.
  50. –

    We'll call it "MUX_PLAYBACK_RESTRICTION_ID" and paste that.
  51. –

    And as before, let's map this to a configuration value.
  52. –

    Open your config/services.php file.
  53. –

    And add "playback_restriction_id".
  54. –

    Reference in the "MUX_PLAYBACK_RESTRICTION_ID" environment variable.
  55. –

    If you look at the Mux docs, it says that we should pass the playback
  56. –

    restriction ID
  57. –

    in our JWT payloads, so we'll update the playback method in our JwtFactory
  58. –

    class to
  59. –

    include this parameter.
  60. –

    In your JwtFactory class, simply add this as a new claim.
  61. –

    And reference the new configuration value.
  62. –

    We could add this additional claim to the "thumbnail" method as well, but that
  63. –

    would prevent
  64. –

    third-party access where it's actually wanted, such as for building with social
  65. –

    media previews
  66. –

    when sharing pages on websites like Facebook, LinkedIn, and Twitter.
  67. –

    If we added playback restrictions to thumbnail URLs, then those services would
  68. –

    not be able
  69. –

    to load the image due to requesting it from a different domain.
  70. –

    If we go back to the browser and refresh, we shouldn't see any differences when
  71. –

    trying to
  72. –

    watch the video from the domain included in the playback restriction.
  73. –

    However, if we try and view the video from a different domain, i.e. one
  74. –

    generated by
  75. –

    sail:share, then playback should fail as the exposed URL is not 127.0.0.1 that
  76. –

    we included
  77. –

    in the playback restriction.

Resources