Fluksio/app
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Adopt a member the portal vouches for

Browse Source 
A share link admits somebody at the portal, so this instance first hears of
them when they arrive rather than when a superuser types their code in.
An unmapped portal identity is now checked once against the portal's own
list of who may reach this instance and given an ordinary local account
only if the portal vouches for it.

Asking rather than believing the token is the point: a token stays signed
and valid until it expires, so trusting its claims would let one rebuild
the account somebody deleted here and deleting a user would stop being the
whole of the revocation.

The account-making itself moved out of the route, since both ways in build
the same thing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GPMNwB2mGBP5j7dXRopcPH
This commit is contained in:
stroblme
2026-09-02 17:50:29 +02:00
co-authored by Claude Opus 5
parent 058f16ec1d
commit 65272a135f
6 changed files with 181 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/interface/portal.md
+24 -6
View File
@@ -61,18 +61,34 @@ hijacked DNS entry or a mis-issued certificate from impersonating the portal.
## Letting someone else in
Anyone else on the portal reaches your instance only if a superuser there
admits them, and they arrive as a local user of their own rather than as you.
Anyone else on the portal reaches your instance only if you let them, and they
arrive as a local user of their own rather than as you. There are two ways,
and the difference is who starts.
### Share a link
On the portal, the share icon on your instance's row gives a QR code and a URL.
Whoever opens it, signed in to Fluksio on that device, joins. It works once and
expires in fifteen minutes; **New link** replaces it, which is also how a link
you would rather not have sent is cancelled.
Nothing has to be entered on the instance. It learns of the new member when
they first arrive and asks the portal who they are, then gives them their local
account.
### Take a code
For a machine whose owner would rather admit people at the machine itself.
1. **They**: **Instances → Join an instance**, and copy the code. It is
bound to their portal account and expires in fifteen minutes.
2. **You**, on the instance: **Settings → Remote access → Add remote
user**, and enter the code.
3. They now see the instance under **Instances**, marked *Shared by*,
with **Open** and nothing else. Renaming, re-keying and removing stay with
you.
The instance redeems that code against the portal using its own credential.
Either way they now see the instance under **Instances**, marked *Shared by*,
with **Open** and nothing else. Renaming, re-keying and removing stay with you.
The instance redeems the code against the portal using its own credential.
A portal session cannot do this, which is what stops somebody you let in from
letting others in.
@@ -83,6 +99,8 @@ a superuser and with no password.
| From | Action | Effect |
|---|---|---|
| The portal | share dialog → **Remove** | that member stops reaching it from the portal; their user on the machine stays until it is deleted there |
| The portal | **Leave**, on a row shared with you | gives up your own access to somebody else's instance |
| The portal | **New code** | rotates the credential and drops the current link |
| The portal | **Remove** | deletes the registration and cuts the connection |
| The instance | **Disconnect** | unilateral and immediate — the portal's tokens stop verifying here whatever the portal still has on file |