akvo / akvo-mis / #1336

90%

main: 91%

Pull #506

coveralls-python

Set the session cookie when an invitation is accepted

`set_user_password` assembled its own response: the serialized user and
a fresh access token in the body, and no `Set-Cookie`. `AUTH_TOKEN` is
the only thing the SPA bootstraps a session from, so accepting an
invitation signed the invitee in for exactly as long as the tab went
unreloaded. A plain refresh landed them back on the login page.

An operator met this on the return trip from inspecting a workspace,
which is two cross-origin navigations -- the console mints a one-time
code and hands off to the workspace's own host, and Exit inspection
navigates back -- so nothing held in memory survives either leg, and
the console had no cookie to recover from. It reads as being logged out
by exiting inspection, which is why it was reported that way; the
session was simply never persisted. The same endpoint serves workspace
user invitations and password resets, so every invited user had this,
not only operators.

`authenticated_response` already exists for exactly this, and its
comment says why: signing in and signing up hand back the same thing,
kept in one place so the two cannot drift apart. This was a third
caller that had drifted.

It also stamps `last_login`, which this endpoint did not. That is
plainly right for an invitation and defensible for a password reset,
the other flow through here: both hand back a working session, and a
reset showing up as a sign-in is a smaller wrong than a column that
disagrees with the session the response just issued.

The accompanying test asserts the cookie authenticates rather than
matching it against the token in the body. Those two are different
JWTs: `refresh.access_token` mints a fresh one on every read, so login
has always returned a body token and a cookie token that differ.

8170 of 9283 branches covered (88.01%)

Branch coverage included in aggregate %.

15203 of 16573 relevant lines covered (91.73%)

0.92 hits per line