# Pages behind a login


> 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 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](/community/save-web-pages-with-browser-extensions/) 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](/docs/developers/web-pages/javascript-injection/), and the worked examples in the [Screenly Playground](https://github.com/Screenly/Playground/tree/master/javascript-injectors).

## 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](/docs/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.

> [!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.

**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:

```bash
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.