Security and access model

Overview

Five layers decide what a visitor can do on RTEdge.net. Each one is set in a different place.

Each deployment is its own site

rt.ht is on the Public Suffix List, so browsers treat every name.rt.ht as a separate site. A deployment cannot set cookies for .rt.ht, and a.rt.ht and b.rt.ht do not share cookies, storage or sign-in sessions.

Session cookies are host-only. Every name.rt.ht and every custom domain therefore signs a visitor in separately, and signing out of one host leaves the others alone. The path routes of one host, such as name.rt.ht and name.rt.ht/docs/, share one origin, and so they share the sign-in session.

In the playground, the editor and the output of your code also run on separate origins.

Signing in and sessions

A visitor signs in by opening ::si on your host. RTCode.io shows its sign-in page, where the visitor picks GitHub, Google, Microsoft or Apple, and verifies the account with that provider. Multi-factor sign-in and passkeys work through the identity provider, if the account has them enabled. RTEdge.net adds no multi-factor layer of its own.

The result is a signed session for the host. It records the visitor's email, the provider and the time of sign-in. Sessions are signed with ECDSA P-384 and checked at the edge on every request.

If the visitor is still signed in to RTCode.io, ::si completes without asking for a provider again. GitHub sign-in needs an email address on the GitHub account.

You write no authentication code. A page reads the signed-in email with fetch('::su'), and a worker reads request.rt.user: a string, or null. For ordinary visitors, request.rt.user reflects only a verified session. See Adding sign-in.

Owners, editors and savers

Owner

The account that first deploys a route. Only the owner can delete the route or change its editors. The owner always passes both gates.

Editors

Accounts authorized to view, open the source and redeploy a route. They pass both gates; they cannot delete the route or change its editors. An editor's deploy keeps the owner and the saved editor list. See Editors for entry syntax and managing these permissions.

Saver

The account that saved a version. For a deploy by an editor, the saver is that editor. A version records the saver as its author and the owner as its committer.

Editors also see the route in the * index. See Domains and subdomains for the claim that every route's owner holds on its domain.

Who can view a deployment

edge:user is the view gate. When a deployment has at least one edge:user element that does not also carry edge:guest Experimental, RTEdge.net lets only the owner, the editors and the accounts the attribute lists see it.

The gate guards the root page, the exported o:= files and the requests that fall back to the worker. It does not guard explicit worker calls with /:. A worker that must authenticate checks request.rt.user itself. See edge:user and /:.

Who can open the source

The source is the full authored page, as saved at deploy time. Anyone can open it with ? unless the deployment has one of these:

• an edge:user element without edge:guest;
• an io:user element without io:guest, other than an edge worker;
• at least one <script type=worker edge> where not every edge worker carries io:guest.

When the source is private, the owner, the editors and the accounts listed by io:user may open it. Deploying any edge worker without io:guest therefore makes the source private by default. A deployment with no edge:user, no io:user and no edge worker, or with edge workers that all carry io:guest, has a public source. See io:user, io:guest and ?.

How the view and source gates combine

The two gates are independent, and neither attribute overrides the other. RTEdge.net applies these rules:

• Any edge:user without edge:guest also makes the source private. Only the owner, the editors and io:user permits can open it, and edge:user permits alone give no source access.
• An account listed in io:user but not in edge:user can open the source with ?, but cannot view the deployment.
• io:guest makes the source public only when it removes the sole protection: it cancels the io:user on its own element, or every edge worker carries it. A separate <meta io:user>, or any edge:user, keeps the source private.
• edge:guest Experimental on the same element as edge:user cancels that element's list, just as io:guest cancels io:user.

Permits

edge:user and io:user take a space-separated list of permits. The Editors field takes the same three forms.

person@domain.tld

That exact account.

domain.tld

Any account whose email domain is exactly that domain. example.com matches a@example.com, but not a@mail.example.com.

*

Any signed-in user. It never matches an anonymous visitor, who is asked to sign in instead.

Write permits and editor entries in lower case. Attribute values are lower-cased when you deploy. An attribute with an empty value still switches its gate on, so that only the owner and the editors pass.

What a denied visitor sees

See Error pages for every platform page.

Redaction is not secrecy

edge:redact and edge:remove change only the HTML that RTEdge.net serves. The source opened with ? still contains the redacted or removed content whenever the source is public, and every deploy also saves the complete source as a version. copy:redact works in the editor only and has no effect on a deploy.

To keep a value private, keep the source private (a non-guest edge worker, io:user or edge:user) and keep the value inside the private edge worker. See Keeping secrets out of deployments, edge:redact and edge:remove.

Order of checks

For a request to a deployed host, the checks that matter for access run in this order. Request routing has the complete order.

1. Platform suffixes answer first, on every URL of the host and without any access gate: the sign-in suffixes, ::qr, ::clear and /::edge.
2. ::owner and the ::kv viewer answer next.
3. Any other path that contains :, except ::meta, goes straight to the route's worker. No access gate applies.
4. A * index requires sign-in. A URL that ends in ?? redirects to the versions page.
5. RTEdge.net loads the deployment and its access rules. ?m=uo and the 404 for an undeployed route answer here, before any gate.
6. The source gate applies, when the deployment has source rules. A permitted source request is answered with the source.
7. The view gate applies, when the deployment has edge:user.
8. ::meta answers, then the exported files, then the page or the worker fallback.

Guarantees and limits

• Sessions are signed with ECDSA P-384, checked at the edge and honored for 24 hours. Each host holds its own session.
• Multi-factor sign-in and passkeys come from your identity provider.
• edge:user does not guard explicit worker calls (/:). A worker that needs a signed-in user checks request.rt.user itself.
• Match rules are exact: an email must be equal, a domain must be equal (subdomains do not match), and * means any signed-in user.
• edge:user and io:user are enforced by RTEdge.net. The playground does not enforce them, and it emulates only ::su and request.rt.user.
• A page behind edge:user has no social preview for visitors who are not permitted: they receive the 401 or 403 page instead.
• Redaction only changes the served HTML. It does not hide the source.

Related concepts

Request routing

The order in which a request is answered, including every access check.

Anatomy of a deployment

What a deploy produces, including the access rules compiled from your attributes.

Playground and edge differences

What the playground emulates of sign-in and access, and what only RTEdge.net does.

Architecture

How the editor, the output, the deploy pipeline and the edge fit together.

See also

• Editors
• Adding sign-in
• Restricting access
• edge:user
• io:user
• io:guest
• ::si ::sa ::su ::so
• Request.rt
• Error pages
• Glossary