auth Files

Verify login now accepts only a signed handshake token that carries this provider's name. Before, LoginHandler accepted any token with a user::address handshake signed with the service secret. That included handshake tokens an application issues for its own purposes, which are not login confirmations, and confirmations issued by another verify provider. A session token, which has no handshake, caused a nil dereference. All of these now get a 403.

One behaviour change. An application that mints its own handshake tokens and sends them to the verify login endpoint has to set the provider name on them. Tokens from the provider's own confirmation request already carry it.

The login error paths no longer log the token. Six error branches of LoginHandler passed the raw request to the error response, which logs the URL with ?token= in it. An expired session token sent as ?token= was logged in full, and it stays usable as a cookie because the auth middleware refreshes expired tokens. A handler built without a confirmation store logged a confirmation link that could still be redeemed.

Also in this release: the provider tests fail with the address when a test server port is taken, where before they failed later on a client timeout that did not name the cause.

Full detail on the token check in [#319].