Skip to content

Sessions & sharing ​

The Sessions page lists every browser session you can open, in two tabs:

  • Mine — sessions minted on your own gateways.
  • Shared with me — sessions other people shared with you via a claim link.

Each row shows the service, the gateway, the hostname it serves on, time until expiry, and a state badge (active, expired, or revoked). Active rows have an Open button that takes you straight into the session viewer. The list refreshes itself every few seconds.

What a session is — a time-limited, token-bearing grant of access to one target — is covered in the gateway sessions guide. This page covers the console workflows.

Sessions on a team ​

Who can do what with a shared target's sessions depends on your team role:

  • The team's owner and managers hold full session authority on a team gateway — create, share, extend, relabel, and revoke, on any shared target, not just ones they created.
  • Members can't manage sessions, but they receive them: on a shared target, a member sees each session's credentials — the Copy affordance rebuilds the viewer link — so a session shared with the team is actually usable, not just visible.
  • Viewers and guests have no session surface at all. They see only shared targets that are publicly reachable without a session.

One target is held back: a gateway's own remote console. Its sessions don't relax to team members until the gateway has a console password set — the gateway's creator sees a Console password not set note on the row, and sets one on the gateway host (local console → Settings → Remote console password).

Raw (TCP) targets have no sessions at all, and the sessions control is also hidden on targets whose domains are all public — no token is needed to reach those.

Minting a session ​

Sessions are minted per target, from a gateway's detail page: open Gateways → your gateway, expand the target's sessions, and use the inline create row. Give it a label (free text — "for Alex", "demo Friday") and an expiry. The expiry field is freeform: 24h, 30d, 1y. Minting needs the gateway online and the target active.

The mint returns the session link once — copy it then. Afterwards, the Copy button on an active row rebuilds a viewer link from the session token and the target's domain.

Sending someone the raw session URL works, but anyone holding the URL gets in. For a named, sign-in-gated handoff, use Share on the session row instead:

  1. Share → Generate link mints a one-time claim link (https://…/share/<code>). It is shown once — copy it. The link itself expires after a short window, separate from the session's own TTL.
  2. Whoever opens the link signs in to Burrowee (GitHub OAuth — they are bounced through sign-in first if needed), and the session is claimed into their Shared with me list.
  3. After claiming, they are taken straight to the session viewer, and can come back to it any time from their own Sessions page — no need to keep the link.

The claim link is single-purpose: once used, send a fresh one for the next person. Revocation is unaffected by sharing — revoke the session and every claimed copy and share link dies with it. An expired claim link shows "ask the owner to send a fresh one".

Extend, relabel, revoke ​

On an active session row (in the gateway detail's per-target list):

  • Extend — set the expiry to a number of days from now, 1 to 365 (the dialog defaults to 30).
  • Relabel — click the label and type; the token is untouched.
  • Revoke — click, then confirm within 3 seconds. Links stop working immediately, and a revoked session cannot be revived — mint a new one.

These are live gateway operations: if the gateway is offline they fail with a "Gateway is offline" note.

Page-share sessions ​

A normal session opens the whole target. A page-share session lets the target application hand out a separate link per page instead — share one document, one dashboard, one record.

To mint one, switch on the Per Page Sharing toggle on the create row before clicking Create. The mint reveals a descriptor once:

  • the base token,
  • the share seed — treat it as a secret; anyone holding it can derive valid page tokens,
  • an example URL.

Rows of this kind carry a reveal control that can re-surface the stored seed later (with the same secret-handling warning).

The seed does nothing by itself — the target application must use it to derive per-page tokens. The reveal dialog links app developers to the integration guide.