The 14-to-15 state migration was released in urbit-os-v2.142
so we add a new ames-state-16 to account for the removal of
.num-live from $pump-metrics.
This also adds several `$+` shorthand type name for better
prettyprinting in nest-fails situations, all related to the types in
$ames-state.
(note: ames states 14 and 15 are the same, ane tha migration
just re-retrieved our own %rift—first introduced in state-12-to-13)
Keeping a queue of nonces to match the outgoing %pleas we send lets us
recover the nonce for the %done we receive in response. This is
important in the nack case, where we may want to eagerly serve the HTTP
client an error page response, instead of waiting for the timeout timer
to fire.
Instead of doing formal network traffic on the host-side whenever a
login attempt gets initiated, we now do it no earlier than when we're on
the client-side. This has the important property that network traffic
can only be initiated by authenticated HTTP requests. The previous
implementation, where hosts sent pleas when an unauthenticated HTTP
client said then wanted to log in, was vulnerable to abuse.
So now, formally, the eauth flow starts at the client's confirmation
screen. There is an optional step preceding this, where an attempt is
started on the host (and data is still stored for this), but to get the
redirect target, the host uses remote scry to get the eauth URL out of
the client ship.
Hosts now also give attempt-specific return URLs, useful in case they
are accessible (or even serving different content) from different
hostnames.
aka "mirage" aka "eyre oauth"
With Eyre now supporting both local identity authentication, and fake
guest identities, the logical next step is to support authentication
with real non-local identities. Here, we implement that, building on top
of the groundwork laid by #6561.
The primary change is adding a %real case to Eyre's $identity type, and
implementing an http<->ames<->ames handshaking protocol into Eyre for
negotiating approval of login attempts made by unauthenticated HTTP
clients.
The authentication flow, where a "visitor" logs into a "~host" as their
own "~client" identity can be described in brief as follows:
1) Visitor makes an HTTP request saying they are ~client.
2) ~host tells ~client, over Ames, about its own public-facing hostname.
3) ~client responds with its own public-facing hostname.
4) ~host forwards the visitor to ~client's eauth page.
5) Visitor, there already logged in as ~client, approves the login
attempt.
6) ~client shares a secret with ~host over Ames, and forwards the
visitor to ~host's eauth page, including the secret in the request.
7) ~host sees that the secrets received over Ames and HTTP match, and
gives the visitor a new session token, identifying them as ~client.
The negotiating of hostnames/URLs via Ames is crucial to keeping this
handshake sequence secure.
Discovering a ship's public-facing hostname happens when successful
local logins are made by reading out the Host header from the request.
Users may hard-code a value to override this.
Each eauth login attempt comes with a unique nonce. Both the host and
client track the lifetime of these. The corresponding Ames flow (which
goes from ~host -> ~client) is corked when the login attempt gets
aborted, or its associated session expires.
The logout functionality has been updated to let clients ask to be
logged out of sessions on other ships.
%name now returns the identity of the session associated with the
request. %host will always return the @p of the ship *handling* the
request.
The latter becomes especially important for guest sessions, who can only
interact with agents on the local ship, but will still need to specify
who that ship is.
aka "the open eyre" aka "universal basic identity"
Urbit already supports presence on the clearnet, but fails to expose any
of its interactive affordances to unauthenticated users. Here, we
improve this situation by granting "guest identity" @ps to every
unauthenticated HTTP request, and extending the channels functionality
to them.
Sessions no longer represent only the local identity. Instead, each
session has either the local identity, or a fake guest identity
associated with it.
Every request that does not provide a session key/cookie gets assigned
a fresh one with a guest identity on the spot. As a result, every
single request has an identity associated with it.
The identity of a request gets propagated into userspace, if the request
ends up there.
For normal HTTP requests, this means the src.bowl gets set to that
identity for both the watch and poke of the request. For backwards
compatibility, the authenticated flag on the request noun gets set at
normal: only true if the request came from the local identity.
For channel requests, this means the src.bowl gets set to that identity
for any pokes and watches it sends, and it can only send those to agents
running on the local ship.
The scry endpoint remains unchanged in its behavior: only available to
the local identity.
Notable implementation detail changes in this diff include:
- Factored all gall interactions out into +deal-as.
- Sessions no longer represent exclusively the local identity. This
matters a lot to +give-session-tokens, %code-changed, and logout
handling.
- Session management got factored out into explicit +start-session and
+close-session arms.
