Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 120 Next »

You can use the APIs locally with the DWS (to use the Control Cloud APIs for interacting with a player, see Remote+DWS). There are two ways to access these APIs:

  1. You can choose to use no authentication.

  2. You can choose to use digest authentication. Digest authentication uses a username and a password. The username is always “admin”. The password can be set in three ways:

    1. Use the default, which is the player serial number

    2. Set it through the setup package

    3. Set it using a custom script

Once the password is set, you need to authenticate to access the local DWS APIs. To do this:

  • Use BrightSignOS 8.1.21 or higher, such as 8.2, and 8.3 (except 8.3.39.x). Note that BOS 8.3.39.3 and 8.4.6 and higher may have some unexpected behaviors.

  • Turn on the local DWS in BrightAuthor:connected in the Control tab of the remote DWS. See DWS Access in Remote Diagnostic Web Server for more information.

  • Call the desired API using digest authentication with the local DWS username and password. Note that digest authentication is fairly insecure when used over an insecure transport (HTTP).

The URL prefix is always http://player_ip/api

Advanced Usage

If you choose to set the registry "bbhf" directly instead of through the BrightAuthor:connected UI (described in step 2, above), note that: 

  • bbhf is in the networking section of the registry 

  • If bbhf is set, the BSN.cloud DWS is enabled, and all DWS APIs are enabled. 

  • If bbhf is unset, only the "legacy" DWS and the "legacy" DWS APIs are enabled. The legacy DWS is pre-BSN.cloud and does not use BSN.cloud functions.

All POST and PUT API calls have response and request bodies of type JSON.

API Definitions

The listed APIs are prefixed with the version /v1. To preserve backwards compatibility, BrightSign will create a /v2 version for any API changes and attempt to retain the semantics and behavior of /v1 but this may not be possible. We can not guarantee that this document will be current in every case./packet-capture/ 

Downloading a File From Player Storage

To directly download a file from player storage, add ?contents&stream to the end of the URL. Here is a sample workflow (assuming a base URL of http://192.168.0.12/api/v1):

  1. Create a snapshot on the SD card under the remote_snapshots using POST /v1/snapshot

  2. The response will be the name of the snapshot (for example, img-2021-12-29-10-49-27.jpg).

  3. To directly download the snapshot created on the player: GET http://192.168.0.12/api/v1/files/sd/remote_snapshots/img-2021-12-29-10-49-27.jpg?contents&stream

  4. If you enter only ?contents, you get the file in the base64 encoding.

Using HTTPS with the Local DWS

Generating a Self-Signed Certificate and Key

To do this, choose one of the following two methods:

  1. Run this code: 

    openssl req -nodes -new -x509 -keyout dws.key -out dws.crt

  2. OR run the following code and use the 'dws.key' and 'dws.crt' files. The other files can be deleted later.

    openssl req -newkey rsa:4096 -keyform PEM -keyout ca.key -x509 -days 3650 -outform PEM -out ca.cer

openssl genrsa -out dws.key 4096

openssl req -new -key dws.key -out client.req

openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key -set_serial 101 -extensions client -days 365 -outform PEM -out dws.crt

Making the Certificate and Key Files Accessible

The operating system will look for files with known names at the root of the default storage. To make the certificate and key files you generated findable, either:

  • Name the files dws.crt and dws.key, OR

  • Put the names of the files in the networking registry using the keys ldws_cert_file_name, ldws_key_file_name

Then put the files at the root of the default storage.

  • No labels