Private by default
Every address under the pages domain (the main address and every <site>--<environment>) is always private. It asks for the PBS SoCal sign-in and opens only for:
- administrators,
- the site's owner,
- the people who manage the site, and
- whoever the environment is shared with.
That can't be switched off for a pages address. A site doesn't need a domain to work: people who sign in can use it at its pages addresses indefinitely.
Sharing
A share names who and which environments:
- A person, by the email they sign in with. People can be given view (open the environments named) or manage (work on the whole site). Only internal people can be made managers; outside guests can be given view, never manage.
- A persona, everyone holding a platform role, checked on every request, so a change to someone's role applies on their next page load.
- Everyone internal, a per-environment switch that opens it to everyone signed in who isn't an outside guest.
A share that names no environments opens every environment. Removing someone takes effect on their very next request, because access is checked every time, not just at sign-in.
Who may do what
| Shared with | Can manage | Owner | Administrator | |
|---|---|---|---|---|
| Open the environments shared with them | Yes | All | All | All |
| Publish and edit dev, promote, roll back | No | Yes | Yes | Yes |
| Add environments and domains | No | Yes | Yes | Yes |
| Share an environment, make a domain private, require approval | No | Yes | Yes | Yes |
| Make a domain public, move the main address | No | No | Yes | Yes |
| Add or remove managers, change the owner | No | No | Yes | Yes |
| Delete a site, take approval off, move past an approval step | No | No | No | Yes |
People who don't manage a site see only the environments they can open, in the portal and in anything the MCP tells them.
Making a site public
Public is a setting of a domain, not of a site or environment. Going public always takes two deliberate steps:
- Add a domain to an environment (never
dev), such ashello.pmgsc-data.org. It's added private. - Set that domain public. Only the owner or an administrator can, and in the portal it asks you to type the domain's name to confirm. If the environment requires approval, the request goes to Approvals first.
Only that one domain opens to anyone. The site's pages addresses keep asking for a sign-in, and setting the domain back to private closes it again immediately.
How sign-in works
Every request to a private environment, on every page, is checked before anything from the site is sent.
- Someone not signed in is sent to the PBS SoCal sign-in and brought back to the page they asked for. If they're already signed in to the portal, it happens with no click.
- The portal hands the sign-in across with a one-time code that's good for one minute and only for that browser, that site and that address. It only ever sends people back to an address that belongs to that site.
- Each site address then keeps its own sign-in cookie for an hour. The site never receives your portal session, so a site's pages can't act as you in the portal.
- Who may open the environment is checked on every request, against the live list of people and roles.
- API keys don't work on site addresses, and every private answer tells search engines not to index it.
Knowing who is reading
Inside a private environment a site can ask who is signed in. The platform answers at /_viewer with the person's email, name and platform role. This guide uses it to show your email in the header.
A site can use that to tailor what it shows, for example a team page that highlights your own team. The platform's only decision is who may open the environment; anything finer is up to the site.
At a public domain nobody is signed in, so /_viewer answers "nobody is signed in on this site".
For decisions that must be enforced on the server, not just in the browser, make the environment part of a Plexara Application: its endpoints run as the signed-in person, and its database can hold each row to that person. See Application security.
Security headers
A site can include a file called _headers to set browser security rules per path, such as which outside sources a page may load scripts from. Only security headers are allowed: content security policy, permissions policy, cross-origin policies and framing rules. Anything else, such as cookies or caching, is refused when publishing.
/*
Content-Security-Policy: default-src 'self'; img-src 'self' data:
Permissions-Policy: camera=(), microphone=()By default no other website can show your site inside a frame. The headers travel with each release, so rolling back restores the rules that release had.
Other protections
- Hidden files are refused. A file whose name starts with a dot, such as
.envor.git, can't be published. - Media folders can't become a second site. HTML, SVG, JavaScript and XML files in a mounted media folder are sent as downloads, never run as pages.
- Sites can't impersonate the platform. A site can't hold the sign-in and viewer paths, and a domain can't be added for the portal's own address or anything under the pages domain.
- Everything is audited. Every change to a site, by a person or an agent, is recorded.
- Templates are sandboxed. A site built from layouts is assembled with time and size limits, and a template can't reach the network or any file outside the site.