Pages behind a sign-in

Three ways to show a page that needs authentication: the browser extension, JavaScript injection, and client certificates for enterprise networks.

A screen has no keyboard and nobody sitting at it, so a page that expects someone to sign 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.

The Screenly browser extension, Save to Screenly, is available for Chrome and for Firefox 102 or newer. Both versions have the same options.

1. Install it, then select the Screenly icon in the toolbar. The pop-up asks for an API token: paste one and choose Sign In.
2. Open the page and sign in to it as yourself.
3. Select the Screenly icon, make sure Save Authentication is checked, and select Add to Screenly.

Save Authentication is the whole point. It saves your current sign-in for that site along with the page, exactly as your browser has it, so your screens can open the page without signing in. Without it you have added an unauthenticated URL.

The pop-up waits until Screenly has accepted the page and then shows Web page saved. If that takes more than about 30 seconds, or saving fails, it shows Failed to save web page, so try again.

The extension checks your workspace for the page you're on. If it's already there, the button reads Update Asset and Save Authentication shows how the page was saved, in Chrome or Firefox, on any computer. Update Asset is how you replace a saved sign-in: if a screen shows the site's sign-in page instead of the page you added, open the page signed in, check Save Authentication, and select Update Asset.

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 session, you sign in again and update the page.

It survives a player reboot, as long as the stored session and the site's cookie both hold. The same saved session is used when the page is rendered on our servers, the Screenly Anywhere screenshot path.

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 in a simple sign-in 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.5.1 or newer. It is not available on Screenly Anywhere. On Screenly Player Max and other x86 players, the certificate is held in the device's secure hardware.

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.

With the setting on, the player presents its own device certificate when it loads the page, and your server decides whether to talk to it.

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.

The first way is to 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.

[!IMPORTANT] Verifying the chain alone is not enough. Because every Screenly device shares that authority, a server that only checks the chain accepts a certificate from any Screenly player anywhere. The common name is what identifies your fleet.

The second is to 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.

[!NOTE] If the same host also serves people, do not require certificates on all of it. Put the signage feed on its own subdomain with strict certificate checking, and leave the human-facing side on normal TLS and SSO.