Brightcove Player Sample: Password to View Video

Product(s)
Video Cloud
Brightcove Player
Role(s)
Player Developer
Topic(s)
Playback

In this topic, you will learn how to ask for a password to view the video.

Player example

In this sample you need to enter a password to play the video. You can either click the Sign In button or hit the Enter key once you have entered the password. For testing, the password is thepass. If you enter the incorrect password a JavaScript alert box pops up with an appropriate message.

See the Pen Password to View Video by Brightcove Learning Services (@rcrooks1969) on CodePen.

View the source code.

Using the CodePen

Here are some tips to effectively use the above CodePen:

  • Toggle the actual display of the player by clicking the Result button.
  • Click the HTML/CSS/JS buttons to display ONE of the code types.
  • Later in this document the logic, flow and styling used in the application will be discussed in the Player/HTML configuration, Application flow and Application styling sections. The best way to follow along with the information in those sections is to:
    1. Click the EDIT ON CODEPEN button in the CodePen and have the code available in one browser/browser tab.
    2. In CodePen, adjust what code you want displayed. You can change the width of different code sections within CodePen.
    3. View the Player/HTML configuration, Application flow and/or Application styling sections in another browser/browser tab. You will now be able to follow the code explanations and at the same time view the code.

Light security

This document has code for two different approaches to provide light security for viewing a video. Neither of these implementations are bullet proof ways to protect your videos from viewers you do not wish to play your videos. They do provide a small barrier that would take some knowledge and effort to find the correct password. If a completely secure method is needed to protect your videos see the Overview: Content Protection and Overview: Digital Rights Management (DRM) in Video Cloud documents to get you started. The next two sections of this document provide details of the two approaches.

Store the password in a video's custom field

In this approach a password custom field is read from the video and checked against the password entered in the form that overlays the player. For more about creating the custom field, see the Creating Custom Metadata Fields document.

The main advantages of this approach are:

  • Every video can have a different password.
  • If no password is entered in the custom field, the viewer of the video will NOT be prompted for a password.

The main disadvantages are:

  • A custom field must be added to the video configuration (a one time act).
  • A password must be entered for every video for which you wish to restrict viewing.

The code for this version of the plugin is detailed in this document and the plugin version is located here.

Pass credentials to plugin

Here the implementation logic is placed in a custom plugin, and the password for all videos viewed in the player to which the plugin is associated is passed as an option, as shown in the following screenshot.

The main advantage of this approach is:

  • One password works as valid credentials for all videos viewed with the player in which the plugin is loaded.

The main disadvantages are:

  • To use different passwords you must use different players.
  • A password will need to be entered for playing the video for every video viewed in the player.

The code for this version of the plugin follows very closely to the code detailed in this document (it is actually a bit simpler) and the plugin version is located here.

Development sequence

Here is the recommended development sequence:

  1. Use the In-Page embed player implementation to test the functionality of your player, plugin and CSS (if CSS is needed)
  2. Put the plugin's JavaScript and CSS into separate files for local testing
  3. Deploy the plugin code and CSS to your server once you have worked out any errors
  4. Use Studio to add the plugin and CSS to your player
  5. Replace the In-Page embed player implementation if you determine that the iframe implementation is a better fit (detailed in next section)

For details about these steps, review the Quick Start: Plugin Development guide.

iframe or In-Page embed

When developing enhancements for the Brightcove player you will need to decide if the code is a best fit for the iframe or In-Page embed implementation. The best practice recommendation is to build a plugin for use with an iframe implementation. The advantages of using the iframe player are:

  • No collisions with existing JavaScript and/or CSS
  • Automatically responsive
  • The iframe eases use in social media apps (or whenever the video will need to "travel" into other apps)

Although integrating the In-Page embed player can be more complex, there are times when you will plan your code around that implementation. To generalize, this approach is best when the containing page needs to communicate to the player. Specifically, here are some examples:

  • Code in the containing page needs to listen for and act on player events
  • The player uses styles from the containing page
  • The iframe will cause app logic to fail, like a redirect from the containing page

Even if your final implementation does not use the iframe code, you can still use the In-Page embed code with a plugin for your JavaScript and a separate file for your CSS. This encapsulates your logic so that you can easily use it in multiple players.

API/Plugin resources used

API Methods API Events API Properties Player Classes
play() loadstart mediainfo.customFields ModalDialog
on()      
one()      
muted()      
addChild()      

Player/HTML configuration

This section details any special configuration needed during player creation. In addition, other HTML elements that must be added to the page, beyond the in-page embed player implementation code, are described.

Player configuration

No special configuration is required for the Brightcove Player you create for this sample.

Other HTML

No other HTML elements are added to the page.

Application flow

The basic logic behind this application is:

  • Check if there is a password in the password custom field. If yes, pop up the Modal Dialog, if not, play the video.
  • In the ModalDialog display a form for the user to enter a password.
  • After a password is entered, and either the Sign In button is clicked or Enter key is pressed, check the entered password against the one stored in the video's metadata.
  • If the correct password is entered, play the video. If not, pop up an alert box with an appropriate message.

Display ModalDialog if needed

Find the code which is labeled:

// ### Display ModalDialog if password in video's custom field ###

After waiting for the loadstart event to be dispatched so the mediainfo object can be read, the password is received and checked if it is undefined. If yes, just play the video, otherwise display the ModalDialog that contains the password form. The uncloseable option is added so the user does not just press the ESC key and play the video.

Use event listeners to setup password check

Find the code which is labeled:

// ### Add event listeners to check password ###

Two event listeners are setup, one if the user clicks the button and the other if the user presses the Enter key. Once the dynamically created form is placed in newElement, it is available in the DOM. So you can then use JavaScript's querySelector() method to get a handle to the element and assign event handlers.

Check if password correct

Find the code which is labeled:

// ### Check entered password against saved password and act accordingly ###

After you get the value of the password input element you can compare to the password from the video's custom field. Then either play the video or popup and alert stating password did not match.

Application styling

There is a small amount of CSS to control the size of the player and the look of the form.

Plugin code

Normally when converting the JavaScript into a Brightcove Player plugin nominal changes are needed. One required change is to replace the standard use of the ready() method with the code that defines a plugin.

Here is the very commonly used start to JavaScript code that will work with the player:

videojs.getPlayer('myPlayerID').ready(function() {
  var myPlayer = this;
});

You will change the first line to use the standard syntax to start a Brightcove Player plugin:

videojs.registerPlugin('pluginName', function(options) {
  var myPlayer = this;
  ...
});

As mentioned earlier, you can see the plugin's JavaScript code in this document's corresponding GitHub repo: password-to-view.js.

Using the plugin with a player

Once you have the plugin's CSS and JavaScript files stored in an Internet accessible location, you can use the plugin with a player. In Studio's PLAYERS module you can choose a player, then in the PLUGINS section add the URLs to the CSS and JavaScript files, and also add the Name and Options, if options are needed.