Sign in with a username and a password

[iderex]

The plainest sign-in, and the one every other route is compared against. It is
first because it fixes the shape of a session for the two routes that follow.

What this produces

A sign-in call that takes an address, a name and a password, and returns either a
session or a named error.

The password held for exactly as long as the request needs it and not stored,
logged, cached or included in any error the core produces.

A wrong password distinguished from an unreachable server and from a server that
answered in a shape the core does not recognise, because those three need three
different sentences and collapsing them is how a person ends up retyping a
correct password at a server that is off.

Done when

Sign-in succeeds against the fake server, each of the three failures above is a
distinct named error, and a test greps the produced error values and any log
output for the password and finds nothing. Blocked on #5, #4, #21.

[iderex]

The route landed as docs/decisions/0030-the-password-route.md, on ba11f25.

It answers the three things this issue asks for, and one of them by refusing to answer it in this route's own words.

The call takes the base address 0028 already resolved, the account name, the password and the device identity from #36, and answers with either the session 0005 fixes or one of 0004's fifteen kinds. There is no third answer and no field on the session naming which route produced it, because 0005 fixes that all three routes converge on one shape and a field naming the route is the thing every later caller branches on.

The password exists between the caller handing it over and the request carrying it being written, and that is the whole of it. It is not held for a renewal, which 0034 drives from a generation number and a rejection rather than from a credential, and not for a re-sign-in after the session ends, which 0034 refuses by name. It is not written into 0033's store, which holds the token alone, not into the cache, not into a diagnostic event, which 0071 excludes outright with no severity that admits it, and not into any of the fifteen payloads 0004 lists. It is not part of anything derived, so it is in no cache key, no store name and no correlator. The account name is treated differently rather than identically: 0068 puts it on the personal data list, so it reaches an event under 0071's rule for a named field, and 0006 already keeps it out of the key in favour of the identifier the server gave back.

The three failures are 0004's mapping arriving unchanged, and that is the decision rather than the absence of one. A refused credential is not-authenticated with the payload saying there was no token to present, which is the same kind and the opposite payload to the rejection 0034 acts on. A server that did not answer is server-unreachable or timed-out under 0007's split. An answer that does not parse, or that parses without the token, the account identifier or the validity statement, is answer-not-understood. The record adds no vocabulary here, because a sign-in reporting failures in its own words would be the first of eleven clients' worth of drift inside the call every client writes first. Two further answers at the same door are named so nobody adds a kind for them later: a 403 is not-permitted, and a server line with no password route is capability-absent.

The thing this issue does not name and the record decides is what a retried sign-in can leave behind. 0038's policy is kept rather than made special, because the password's exposure is the call and not the attempt, and a second attempt does not extend its life. What that costs is a timed-out whose payload says bytes reached the server, which may be a sign-in that succeeded with a token nothing here received, and the retry may produce a second. The residue is a session in the server's own device list that nothing here will ever end. An operator can end it from the server's own side and can only do that if somebody said it happens.

Both conditions here are untouched. Signing in against the fake server, proving each of the three failures is a distinct named kind, and grepping the produced error values and any log output for the password are statements about running code. There is no language chosen, no build and no test command in this tree, so nothing would go red if any sentence in the record were violated, and the fake server the conditions run against is #21.

One thing in the record is a claim rather than a decision, and it is marked as one there. Whether a password handed over as a plain string leaves bytes in memory after the reference is dropped is a property of whatever #11 chooses, and no reading of this tree settles it.