akvo / akvo-mis / #1337

90%

push

coveralls-python

Fix platform console sign-in and invitation sessions (#506)

* Authenticate only tenant-less accounts on the platform console

The console resolves no tenant, so `login` called `authenticate` with
`tenant=None`. `TenantAwareBackend` reads a null tenant as "no tenant
context" and falls back to walking every account with that email
address, in whatever order the database returns them, returning the
first whose password matches.

An operator who also holds a workspace account under the same address,
having reused its password when accepting the invitation, was therefore
handed the workspace row -- that account predates the invitation and so
comes first -- and was then refused by the operator check with "Sign in
at your workspace address, not the main site". The invite flow permits
the pair: `OperatorInviteSerializer` refuses a second tenant-less
account, not a workspace one. Reported from a deployment where the
invited operator was an existing workspace user; it cannot reproduce
with operators whose addresses are unique to the console.

A null tenant means two different things to that backend, and only one
of them is "search everywhere". On the console it is a requirement
rather than an absence: an operator belongs to no workspace.
`tenant_less_only` says so at the call site instead of leaving the
backend to infer it. The operator check downstream can only refuse a
wrong row; it cannot pick the right one.

Preferred over merely ordering tenant-less rows first, which would also
have fixed the shadowing. Ordering leaves the console's login form
checking a submitted password against every workspace in the install,
which is a cross-workspace credential test no amount of row ordering
removes.

The trade-off is a changed answer for a workspace account typed into
the console: 401 and the generic credentials failure, where it used to
be 400 and the base domain's message, because it now matches no row
here and never reaches the operator check. The oracle that mes... (continued)

8169 of 9283 branches covered (88.0%)

Branch coverage included in aggregate %.

15204 of 16573 relevant lines covered (91.74%)

0.92 hits per line