The %kroc task was introduced in ames-state-10. The way the
migration works, is that queued-events are transformed right
away into the latests version, and the state is done step-wise in
different arms, but in one go as part of the +molt arm.
This means that all states from %10 need to handle cleaning up
the %kroc task, with the addition that we were already handling
another tasks, %snub, from ames-state-9 until ames-state-11.
This means that we need to handle both tasks in two different
ames-states, and from them only the %kroc task.
This also adds several $+ to the ames types, that make nest-failures
easier to read.
The guest identities (#6561) and EAuth (#6598) features will both be
released as part of Zuse 412K, so their +load logic can be collapsed
into a single step.
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.
We probably want something slightly fancier, like a banner or something,
that also shows up on the login page (and perhaps other "system" pages),
but for now this should suffice.
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.
+on-kroc was cluttered with ad-hoc logic to indentify stale flows from
failed resubscriptions that were not properly %corked. Here we move
that logic to a generator that, if not in dry mode, will call %ames with a
(list [ship bone]) to %cork them.
Another option would be to move the logic in the generator to a state
update in ames, which will trigger possibly thousands of %ames messages
to be sent, on every ship that runs the state migration—these flows are
not causing a problem that neds to be addressed, and only take extra
space.
If we decide that this needs to be run by everyone, one solution could be
to set up a timer (maybe taking advantage of the fact that ships don't get
the OTA a the same time) that will eventually poke %hood with a
%helm-ames-kroc task.
