Restricting access

Choose what to protect

Restrict viewing with edge:user

Put edge:user on any element, usually a <meta>. List the accounts that may view the deployment, as emails, domains or *. The attribute guards the root page, the exported o:= files and the requests that fall back to the worker.

<meta edge:user="example.com alice@example.org">
<h1>Roadmap</h1>
<p>Visible to example.com accounts and Alice.</p>

See edge:user.

Restrict the source with io:user

Anyone can open the source of a deployment with ? unless the deployment has source rules. Add io:user to list who may open it.

<meta io:user=example.com>
<h1>Public page, private source</h1>

The source is private as soon as the deployment has one of these:

• an io:user element without io:guest, other than an edge worker;
• an edge:user element without edge:guest;
• an edge worker without io:guest.

See io:user.

Use both gates

The view gate and the source gate are independent, so you can combine them.

<meta edge:user="example.com alice@example.org">
<meta io:user=example.com>
<h1>Team page</h1>

• Any edge:user also makes the source private. edge:user permits give no source access on their own.
• An account in io:user but not in edge:user can open the source, but cannot view the deployment.

See how the two gates combine.

Keep a worker demo's source public

Deploying an edge worker makes your source private by default, to the owner and the editors. Add io:guest to every edge worker whose source you want to share.

<iframe src=:></iframe>
<script type=worker edge io:guest>
  export default { fetch: r => new Response(r.url) }
</script>

See io:guest.

Write permits

edge:user and io:user take a space-separated list of permits. The Editors field takes the same 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.

An empty value

An empty or whitespace-only value. Only the owner and the editors pass, but the attribute still switches its gate on.

self Experimental

Accepted and dropped at deploy time, so self alone has the same effect as an empty value: only the owner and the editors pass.

Domain matching is exact: example.com does not match a@mail.example.com, so list each subdomain you want. Write permits and editor entries in lower case.

Add editors

Editors can view protected pages, open protected source and redeploy the route. They pass both gates without appearing in the attributes. A viewer or source-access permit alone does not grant editing rights. See Editors for entry syntax and how the owner adds or removes collaborators.

Protect worker APIs yourself

edge:user does not guard explicit worker calls with /:. Check request.rt.user in the worker and answer 401 when it is null. See Protect a worker API and /:.

Redaction does not hide the source

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. To keep a value private, keep the source private and keep the value inside a private edge worker. See Keeping secrets out of deployments.

Check what visitors see

Open the deployment in a private window to test the anonymous case. ::su shows who you are on a host, and ::owner Experimental tells you whether you own the route. A protected page has no social preview for visitors who are not permitted. See Error pages.

What happens at deploy

RTEdge.net reads the attributes when you deploy and compiles them into the deployment's access rules. The attributes are removed from the served HTML, and they stay in the authored source. To change who may view or open a deployment, edit the attributes and deploy again.

See also

• Editors
• Security and access model
• Adding sign-in
• edge:user
• io:user
• io:guest
• edge:redact
• ?
• Error pages