How to show a page behind HTTP basic auth on a TV without typing the password

Step 1Put the page behind HTTP basic auth

If the page already shows the browser's sign-in box, skip to step 2. Otherwise, add basic auth at the reverse proxy in front of it. Create one username per screen or per group of screens, with a long random password; a screen never needs a person's account.

1. Caddy

   Hash the password once (caddy hash-password prompts for it), then protect the site or a path. Caddy 2.8 renamed the directive from basicauth to basic_auth; current releases (2.11) use the new name and still accept it with bcrypt hashes.

   status.example.com {
     basic_auth {
       lobby-tv $2a$14$Yu3…hashed-bcrypt-password…
     }
     reverse_proxy statusboard:3000
   }

2. nginx

   Create the password file with htpasswd -B -c /etc/nginx/screens.htpasswd lobby-tv (the -B flag uses bcrypt), then:

   server {
     server_name status.example.com;
     location / {
       auth_basic           "Screens";
       auth_basic_user_file /etc/nginx/screens.htpasswd;
       proxy_pass           http://statusboard:3000;
     }
   }

3. Serve it over HTTPS and test

   Basic auth sends the password with every request, encoded but not encrypted, so on plain HTTP anyone on the path can read it.

   In a private browser window the page asks for a username and password and loads completely once you enter them.

Step 2Add the page in DisplayOps with its credential

1. Create the content

   In the portal, Content+ New content, type Website, and paste the page's address:

   https://status.example.com/board?kiosk

   Leave the username and password out of the address.

2. Tick the HTTP authentication option

   Tick The page asks for a username and password (HTTP authentication) and fill in the username and password from step 1.

   The hint under the fields explains what happens: the password is stored encrypted and sent only to the screen, which answers the browser's login prompt itself, including for the page's own images, scripts and data. It works for Basic and Digest challenges from that address's origin only.

3. Save

   The content list shows a lock badge on items that carry a credential.

   Editing the item later shows the username and a blank password field with the placeholder stored; leave blank to keep; type a new password only when it changes.

4. Slideshows

   Each website item in a slideshow has its own lock button. Use it for the items that need a password; the credential is scoped to that item's origin.

Step 3Assign it and verify

1. Assign the content

   Open the display or a group and choose the content. The screen switches within seconds.

   If the agent has not yet updated to 0.2.2, the Device card on the display page shows the version; screens check for signed updates on their own and install them without a reflash.

2. Take a screenshot

   From the display page. A fully rendered dashboard, including charts and images, confirms the subresources authenticated as well as the page.

3. Watch the Now showing card

   If the server rejects the credential, the player reports http auth rejected by https://status.example.com (check the username and password) there. Correct the credential on the content item; every screen using it picks up the change.

How it works under the hood

For readers who need to sign this off:

• At rest: the password is encrypted with the organisation's secrets key (AES-256-GCM) inside the content record. Every API and portal response replaces it with a flag saying a password is stored.
• In transit: the plaintext is decrypted only into the desired state pushed to the screens that show that content, over the same authenticated channel that carries every other command. The device keeps it in a state file readable only by the agent's own user. Nothing logs it, and the screen's local pages never receive it.
• On the screen: the player enables the browser's DevTools request interception for the content's origin only (scheme, host and port), with authentication handling on. When the server challenges a request, the player provides the credential once. A second challenge for the same request means the server rejected it, so the request is cancelled and the error is reported instead of retrying forever. Cross-origin frames inside a slideshow are attached and covered the same way.
• Scope: one credential per content item, valid for that item's origin. A page that pulls data from a second protected origin needs that origin behind the same hostname.
• Rotation: the browser keeps a credential that worked until it restarts, so after changing the password on the server, update the content item and send Restart player if you want the switch immediately.

Combining it with Grafana, Metabase and others

This feature pairs naturally with tools that can be made anonymous inside a network but should not be public on the internet:

• Grafana: put an anonymous viewer org or the auth proxy behind a basic-auth route on your proxy. Screens anywhere on the internet can now show a private Grafana dashboard with variables and full features, and the proxy's allow-list is no longer needed.
• Public dashboard links from Metabase, Grafana or Power BI can be fronted by your own proxy with basic auth, which turns "anyone with the link" into "anyone with the password".
• Home Assistant is the exception: it has its own login form, and basic auth in front of it does not remove that form. Use trusted networks instead.
• Internal status pages, Uptime Kuma status pages, wiki pages, camera web UIs that show basic auth prompts work as they are, and so does a page you wrote yourself.

Doing it from the API

The API takes the same shape the portal uses. Create a website content item with a credential:

curl -X POST https://app.simpledisplayops.com/api/v1/content \
  -H "Authorization: Bearer sdo_live_…" -H "Content-Type: application/json" \
  -d '{"name": "Lobby status board", "type": "website",
       "config": {"url": "https://status.example.com/board?kiosk",
                  "auth": {"type": "basic", "username": "lobby-tv", "password": "…"}}}'

Responses return "auth": {"type": "basic", "username": "lobby-tv", "has_password": true}, never the password. Sending an update with the password omitted keeps the stored one; sending auth with an empty username removes the credential. Slideshow items carry the same auth object per website item.