Web pages on screens Reaching pages that aren't public Topic 3 of 4

Reaching pages that aren't public

Topic 3 of 4

Much of what is worth showing is not on the open web. A live dashboard sits behind a login. An internal report lives on your own network. A plain browser pointed at either gets a login wall or nothing at all.

A Screenly screen does not have to be an anonymous visitor. It can prove who it is as it makes the request, so a server treats it as a trusted client and serves the page. That proof can travel in more than one way: the screen can send credentials along with the request, such as a token in a custom header, or present a certificate that identifies the device itself, which is mutual TLS.

The result is that a screen can show the same protected pages your own staff see, without anyone weakening the security around them by opening a page up or passing a password around.

This is the request-level half of reaching private content. The network-level half, putting the device on your private network so it can reach internal systems at all, is covered in Integrations.