edge:user

The edge:user attribute restricts who may view a deployment on RTEdge.net. Visitors must sign in, and only the accounts it lists, plus the route's owner and editors, see the page. Everyone else gets a sign-in or "not authorized" page.

Syntax

html
<meta edge:user="alice@example.com example.com">
<meta edge:user=*>
<meta edge:user="">

The attribute can go on any element, including elements inside <template>. <meta> is the usual choice.

Value

A space-separated list of permits. Each permit is one of these:

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 edge:user=self has the same effect as an empty value: only the owner and the editors pass.

Description

edge:user is the view gate of a deployment. When at least one element carries it, RTEdge.net lets only the owner, the editors and the accounts matching a permit see the page. An anonymous visitor is asked to sign in, and a signed-in visitor who does not match is turned away.

The attribute is read when you deploy. It does nothing in the playground.

PlaygroundRTEdge.net
Gate enforcedNo. The playground does not enforce access attributes.Yes. Visitors must be the owner, an editor or match a permit.
Who the visitor isThe account you are signed in with in the editor, seen through ::su and request.rt.user.The visitor signed in on that host.
The attribute in the deployed pageIt stays in your source.It is removed from the served HTML, and kept in the authored source that ? opens.

Usage notes

What the gate guards

The gate guards the root page, the exported o:= files and the requests that fall back to the worker. It also stands in front of ::meta, ?ogo and the social-preview parameters.

It does not guard explicit worker calls with /:, which go straight to the worker. A worker that must authenticate checks request.rt.user itself. Platform suffixes such as ::si, ::qr and /::edge answer before the gate.

It makes the source private too

Any edge:user without edge:guest also makes the source private: the source opened with ? is limited to the owner, the editors and the io:user permits. edge:user permits alone give no source access. An account listed in io:user but not in edge:user can open the source, but cannot view the deployment. See io:user and how the two gates combine.

Matching

A permit matches a visitor by exact email, by exact domain (the text after @) or with *. Subdomains do not match: example.com does not match a@mail.example.com. The visitor must be signed in for any of them to match, which is why * means any signed-in user and never an anonymous visitor.

Permits are lower-cased when you deploy. Write permits, and the entries of the Editors field, in lower case.

What visitors see

VisitorResponse
Anonymous401 page "You are not authenticated.", with a "Sign in" link (::si).
Signed in, not permitted403 page "You are not authorized.", with a "Sign in as a different user" link (::sa).
Owner, editor or matching permitThe page.

See ::si ::sa ::su ::so and Error pages.

Social previews

The social tags, ?ogo and the preview parameters are produced after this check. Crawlers and visitors who are not permitted receive the 401 or 403 page, so a protected page has no social preview for them. See Query parameters.

At deploy time

RTEdge.net reads every edge:user when you deploy and compiles the permits into the deployment's access rules. To change them, deploy again. The attribute, like every attribute with an i:, o:, io:, edge:, h: or worker: prefix, is removed from the served HTML. It stays in the authored source.

edge:guest

edge:guest Experimental on the same element as edge:user cancels that element's edge:user, just as io:guest cancels io:user. On any other element it has no effect.

Note: edge:guest is experimental and may change.

Owner and editors

The owner and the editors of a route always pass the gate, whatever the attribute lists. Editors are set in the Code dialog. See Owners, editors and savers.

Examples

Restrict a page to one company

html
<meta edge:user=example.com>
<h1>Team page</h1>
<p>Only signed-in example.com accounts, the owner and the editors see this page.</p>

Deploy it, and a visitor with an @example.com account signs in and sees the page. Anyone else gets the sign-in or "not authorized" page.

Require sign-in only

html
<meta edge:user=*>
<h1>Members</h1>
<p>Any signed-in user may view this page.</p>

* matches any signed-in user. Anonymous visitors are sent to sign in first.

Name accounts and a company

html
<meta edge:user="alice@example.org example.com">
<h1>Review</h1>
<p>Alice, and everyone at example.com.</p>

Alice can view the page, and so can every @example.com account. Alice cannot open the source unless an io:user permit lists her.

Specifications

Not part of any specification. edge:user is an RTCode.io and RTEdge.net attribute. The 401 and 403 responses use the status codes of:

Specification
HTTP Semantics (RFC 9110)

Availability

FeaturePlaygroundRTEdge.netNotes
edge:userNoYesRead when you deploy. The playground does not enforce it.
* as a permitNoYesAny signed-in user.
edge:guest ExperimentalNoYesCancels the edge:user on its own element.

See also