Network allowlist for corporate gateways

The domains the hosted service uses, for a company network that sends traffic through a proxy, a secure web gateway or a firewall with an allowlist. Each table says which hosts to allow, which to exempt from TLS inspection, and which paths must not be buffered. Nothing here is needed on a network that does not filter traffic. Members on their own networks use the service with no setup at all.

This page is about the hosted service. A home-edition server runs at an address you choose, on your own network, so there is nothing of Botseon's to allow except the desktop app's update host, updates.botseon.com, if you use the desktop app's update checks or the Linux package repository.

The short version

Either allow two patterns:

• botseon.com
• *.botseon.com

or allow this minimum host list:

Then add the sign-in hosts your members use, from the table below, and exempt the hosts listed under TLS inspection and response buffering.

Sign-in hosts

Members sign in with an emailed link or code, or with an identity provider. Allow only the rows for the methods your organisation uses.

The desktop app signs in through the system browser, so its sign-in uses the same hosts.

Computer hosts

A bot's computer has no hostname of its own on the internet, and nothing connects to it from outside. Your network never needs one entry per computer. Every computer is reached through one host, screen.botseon.com, with the computer's ID in the path:

• wss://screen.botseon.com/screen/<computer id>/<display>

So screen.botseon.com, or the *.botseon.com wildcard, covers every computer in your organisation, including ones created later.

What a bot's computer does on the internet comes from Botseon's servers, not from your network. To let it into a site that allows only known addresses, see Egress IP ranges.

Exempt from TLS inspection

A TLS-inspecting proxy decrypts and re-encrypts traffic with its own certificate. Exempt these hosts from inspection, or the feature named beside each one stops working:

For desktop machines behind an inspecting proxy, also exempt app.botseon.com and updates.botseon.com. The desktop app makes its own sign-in, update and machine requests from its main process, which trusts the certificate authorities built into the app rather than a proxy certificate added to the machine's trust store, so an inspected connection is refused. The update feed and the Linux package repository are also checked against Botseon's own signing keys, so inspection would add nothing there.

Exempt from response buffering

A bot's answer streams to the browser as it is written, over Server-Sent Events (text/event-stream). A gateway that buffers a response until it is complete, to scan it, holds the whole answer back: the member sees nothing until the bot has finished, and a long run can time out at the gateway. Turn off response buffering and content scanning for these paths on app.botseon.com:

• /api/runs/*/events, the web app's live run stream
• /api/client/v1/events, the desktop and phone apps' live stream

If your gateway can set this only per host, turn it off for app.botseon.com. The two WebSocket hosts, screen.botseon.com and voice.botseon.com, must not be buffered either.

Phone notifications

The phone app receives notifications through Apple Push Notification service on iPhone and Firebase Cloud Messaging on Android. Botseon's servers send to those services, and the phone connects to Apple or Google, never to Botseon, for them. If your network restricts phones, follow Apple's and Google's own guidance for allowing push notifications.