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.
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.
