Pages behind a login

A screen has no keyboard and nobody sitting at it, so a page that expects someone to log in needs one of these.

They escalate. Start at the top.

The browser extension

For a page with an ordinary username and password form, or basic auth.

Install the Screenly browser extension and link it to your workspace. Log in to the page as yourself, then add it as content through the extension, and tick Save Authentication. That step is the whole point: without it you have added an unauthenticated URL.

Three limits worth knowing before you rely on it:

It stores what the site gave it and does not refresh anything. When the site expires or rotates the token, you log in again.

It survives a player reboot, as long as the stored session and the site’s cookie both hold.

It cannot get past multi-factor authentication or SSO, because neither can be completed on a player.

JavaScript injection

For a page that needs shaping rather than authenticating: dismissing a banner, hiding navigation, scrolling to one panel, or filling a simple login form.

Screenly can run JavaScript against the page as it loads. There is no dashboard control for it: it is set through the API, the CLI, or the MCP server. See JavaScript injection, and the worked examples in the Screenly Playground.

Client certificates

For internal dashboards where IT would rather the device proved its identity than held a password.

Each screen holds its own certificate. The page is served only to devices presenting one, so there is no shared password anywhere and access is revoked by removing a certificate.

This needs ScreenlyOS 26.2.0 or newer. It is not available on Screenly Anywhere.

1. Open the screen’s Actions tab and choose Download certificate. The file is named after the device, such as srly-y358c2nss7i40ly.pem. Repeat for each screen that needs access.
2. On the same tab, choose Download CA certificate. This is the authority that signed every device certificate, and your server needs it to validate the chain.
3. On the content item, open Advanced and turn on Allow sending client certificate, then save.
4. Configure your web server to require and verify a client certificate.

Trusting the right thing

Every Screenly device certificate is signed by the same Screenly certificate authority. That gives you two ways to configure the server, and the difference matters.

Trust the CA, and match on the common name. Point your server at the CA certificate, then check that the presented certificate’s common name is one of your device ids. The name is the device’s own hostname, the srly- string in the filename.

Or trust the device certificates directly. Skip the CA and give the server only the .pem files for the screens you want, which is an allowlist rather than a chain check:

cat srly-device1.pem srly-device2.pem > screenly_trusted_devices.pem

This is tighter and needs no name matching, at the cost of updating the bundle whenever you add or replace a screen. It suits a small, stable set of screens; the CA route suits a fleet that changes.

Either way, NGINX, Apache, HAProxy and Caddy all support this, as do Cloudflare Access and most API gateways if you would rather terminate it at the edge.