Adding sign-in

How sign-in works

Four suffixes drive sign-in. Append one to any URL of a deployed host. The platform answers them before your files or your worker are consulted.

After ::si, the visitor picks GitHub, Google, Microsoft or Apple on the RTCode.io sign-in page. The browser then returns to the URL it started from, without the suffix and with its query and hash, and the host holds a session for the visitor. If the visitor is already signed in to RTCode.io, the return needs no provider interaction. See ::si ::sa ::su ::so for every detail.

Add sign-in and sign-out buttons

Appending to location.pathname keeps the current path, query and hash, so each action returns the visitor to the same page.

<button id=signin>Sign in</button>
<button id=signas>Switch account</button>
<button id=signout>Sign out</button>
<script type=module>
  signin.onclick = () => location.pathname += '::si'
  signas.onclick = () => location.pathname += '::sa'
  signout.onclick = () => location.pathname += '::so'
</script>

Read the signed-in user

In a page, fetch('::su') returns the signed-in email as a JSON string, or null. In an edge worker, request.rt.user has the same value.

null means that there is no valid session on this host. The path in front of ::su does not matter, because identity is per host. ::sud Experimental also returns the provider the visitor signed in with.

<output id=who></output>
<script type=module>
  const user = await fetch('::su').then(r => r.json()) // string email or null
  who.value = user ?? 'signed out'
</script>

Sign in without leaving the page

Experimental The popup forms of the suffixes, ::sic, ::sac, ::sitc, ::soc and ::suc, run the action in a popup window. The popup posts { rt: { user } } to its same-origin opener with postMessage and closes, so your page never navigates. ::suc posts the current user at once, and ::soc signs out and posts null.

<button id=login>Sign in</button>
<output id=me></output>
<script type=module>
  const show = user => me.value = user ?? 'signed out'
  addEventListener('message', e => { if (e.origin === location.origin && e.data?.rt) show(e.data.rt.user) })
  login.onclick = () => open(location.pathname + '::sic') // popup signs in, posts { rt: { user } }, closes
  show(await fetch('::su').then(r => r.json()))
</script>

Protect a worker API

Worker calls with /: are not covered by edge:user, so a worker that needs a signed-in user checks request.rt.user itself and answers 401 when it is null.

<script type=worker edge>
  export default {
    fetch: request => request.rt.user
      ? Response.json({ hello: request.rt.user })
      : new Response('Sign in', { status: 401 })
  }
</script>

<script type=worker edge>
  export default {
    fetch: async (request, { KV }) => {
      const { user, route } = request.rt
      if (!user) return Response.json({ error: 'Sign in first', signIn: '::si' }, { status: 401 })
      const kv = KV.open({ user, route }) // call synchronously, never await the namespace
      const visits = (await kv.get('visits', 'json') ?? 0) + 1
      await kv.put('visits', JSON.stringify(visits), { metadata: { at: Date.now() } })
      return Response.json({ user, visits })
    }
  }
</script>

Sign in inside a cross-site embed

Experimental ::sh is an ES module for pages that run inside an iframe on another site. Importing it adds a hidden helper frame to your page, and after sign-in the session is stored from inside the embed. register() returns an object with open('i'), open('a') and open('o') to sign in, sign in as another account and sign out. See the example on the ::si ::sa ::su ::so page.

Keep ::s out of your own paths

Sign-in in the playground

The playground emulates only part of the sign-in surface:

• ::su answers same-output-origin requests, including fetch('::su') from a playground worker, with the email of the account you are signed in with in the editor, or null. The answer carries Cache-Control: no-store.
• request.rt.user in a playground worker shows the same account.
• ::si, ::sa, ::so, ::sit, ::sud and the popup suffixes are not emulated. Sign in or out in the editor instead.

Both emulated answers come from the editor hook sync.requestRT, which by default adds the signed-in account's email as user. See sync. The editor consults it for each worker call and each ::su lookup, and it must answer within 5 seconds. If it does not, or if the editor is disconnected, user is null.

Troubleshooting

::su returns null after signing in

The session belongs to the host that the visitor signed in on, and lasts 24 hours. Check that the page and the ::su request use the same host, then sign in again.

A path returns a 501 page

The path contains ::s followed by letters that are not a sign-in action. Rename the route, file or worker path.

"Required email address is missing."

The GitHub account has no email address that GitHub reports. Add one in GitHub's profile settings, or sign in with another provider.

"Session has expired! Please sign in again!"

The RTCode.io sign-in has expired. Sign in again in the editor.

The popup posts nothing

The visitor closed it before finishing, or the opener is on another origin. The popup posts only to a same-origin opener.

See also

• ::si ::sa ::su ::so
• Restricting access
• Security and access model
• Request.rt
• sync
• Storing data in KV
• Building a full-stack app
• Playground and edge differences