We remove the local<->eauth switching tabs entirely. The only way to see
the eauth login page is if the url contains an "eauth" query parameter.
(Entering the local ship name into the eauth form still brings you to
the normal login screen.)
The "proceed as guest" blurp no longer shows the guest identity, and we
clarify the language to indicate that it is not guaranteed to result in
access to content.
Both of those changes help simplify the look and feel of the login page.
Various users had complained that it was confusing, given that logging
into your own ship is still the common case, and not everyone knows what
"euauth" is.
For applications redirecting to the login page, it is still recommended
to add the ?eauth GET parameter if non-local sessions are supported. For
applications that don't it should now be more obvious that logging in
through eauth won't do anything (since it's not presented as an option).
We also remove some debugging prints that somehow remained in the
javascript.
XML files can have only one <?xml ... ?> declaration, however they may have more than one <?xml-... ... ?> tag.
Commonly, there will be an <?xml-stylesheet ... ?> tag on RSS feeds.
This commit allows for that.
Contrary to the argument made by 4affae8, this is the _actually correct_
behavior. Not creating server-side resources in response to GETs
respects the expected method semantics, and more importantly, serving a
404 is an important signal for clients trying to connect to a channel
they were using previously. Without that, they have no way of telling
whether, when reconnecting, if their channel was reaped in the mean time
or not.
The "empty PUT" affordance provided by 34148f9 makes requiring a PUT
request for channel creation more reasonable.
We leave the general refactoring done by #6789 in place, but do
emphasize the reasoning given here with a few additional comments.
Instead of auto-redirecting the login page if we're already logged in,
we simply present it as normal. If we're logged in as the local
identity, we present just a "continue" button in place of the +code
input field. If we're authenticated through eauth, or as a guest, we
present a smaller "proceed as" link underneath the login form.
This way, when apps redirect to the login page because the visitor isn't
_sufficiently_ authenticated, eyre doesn't just throw them right back
into the app with still insufficient creds.
Previously, we would reject this with a 400 error. Considering the
request body is expected to contain "array of requests" and that arrays
may be empty, we really should not be rejecting the requests.
Prior to 156ca21472, sending the empty array would have been convenient
for channel creation. Empty arrays getting rejected forced clients to
inject a faux poke (commonly hi-ing oneself). With that recent change,
the most common case for wanting to PUT the empty list of requests is
largely obsolete, but one can still imagine it being useful for clients
that want to keep their channel alive without necessarily being
connected to it. This also implements sloppier clients from running into
400 responses when they submit an empty "command queue" for whatever.
Regardless, there seems to be no clear reason why the empty request list
_shouldn't_ be accepted and processed as normal.
We add a small test to ensure eyre accepts this.
Previously, a channel could only be created by sending a PUT request,
and a GET request to receive the channel's stream would only succeed
after channel creation had happened that way. This forces client
libraries, that generally have an explicit "set up" step before allowing
normal operation, to do strange things, like sending faux pokes
(commonly hi-ing oneself) before connecting to the channel's stream as
normal.
Here, we update the GET request handling for channels to allow requests
for non-existent channels. When this happens, the channel will be
created, and eyre tracks the request as normal.
We do some... gentle restructuring... of +on-get-request:by-channel to
let the new creation case share code with the "already exists" codepath.
In the process, we find that duct-to-key was never getting updated in
the case where we replace the original channel request/connection with
the new incoming one. We fix this, it's trivial. We also identify two
other areas with vaguely-incorrect behavior, but consider them less
important and out of scope.
We also add a test case for "create channel through GET".
Previously, for endpoints bound to agents, we would pass the request
onto the agent even if the agents wasn't currently running.
Here, we make eyre check to see if the agent is actually running, before
passing the request on. If the bound agent is not running, eyre serves a
503 synchronously instead.
This way, we avoid cluttering up the gall queue for the bound agent.
Instead of setting a new timer every time, we wait to hear a new %nack
for a %leave to do so, accumulating any unacked %leaves in the state for
up to ~m2. When the timers comes back, we re-send all outsanting %leaves
and skipp setting up a new timer.
The change introduced in 5422715c9b makes it very frequent for subscribers
to get stale facts on the subscriptions they are trying to leave so to not
clutter their dojo, we put the log under the %odd flag
+on-gall-response might detect the symptom of a bug, where we are
getting a %fact for a channel that has since been deleted. (Meaning that
subscription should have been cleaned up, and we shouldn't have received
the %fact.) We want to issue a %leave, but need to take care to do so
with the same identity that the subscription was opened on.
Previously, we would forcefully get the identity from the non-existent
channel, resulting in a crash. Now, we encode the identity into the wire
instead, so that we may retrieve it from there, even when the channel is
long gone.
Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
As of RFC 5789, PATCH is a valid HTTP request method. The $method:http type,
however, did not include it.
Here, we add it to the $method:http type, so that it now includes all nine
standard HTTP methods.
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)
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 fact that the target bone of a flow that we have received is a
naxplanation doesn't guarantee that there will be a naxplanation
flow (i.e. we have actually sent one) so instead of crashing, we just
continue processing the next bone.
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.
This was removed when the logic for re-subscriptions was taken from %ames
into the generator. Sorting allows us to keep the current (last) subscription
as the last in the list, and in this case we check if it received an ack for
a naxplanation—see https://github.com/urbit/urbit/issues/6065#issuecomment-1322011137—
in which case it's safe to be corked.
