[inkly]

A refresh token is good for seven days and for a new pair each time, and POST /v1/users/refresh never read the account again. A copy of a token went on working after the password was changed, and after the account was gone.

What changes

• The account numbers its sessions (SessionVersion on the user row, added by the migration). The refresh token carries the number the row had when it was made, in the standard jti claim: Common's claims have no field for it, and every service reads them.
• The refresh reads the account again and answers 401 when it is gone or at another session.
• A password change (PUT /v1/users/current/password) and the reset from the command line add one to the number: every session opened before ends.
• A new account starts at a number of its own, not at 0: the database gives the id of an account that is gone to the next one made.
• Saving a profile leaves the number alone.

For the callers

• PUT /v1/users/current/password now answers with the body of a login (token and user), where it answered with the user alone: the session that made the change goes on with that pair. The dashboard stores it in ReCasaOS/CasaOS-UI (pull request to come); an older dashboard ignores the body and is asked to sign in again when its token runs out.
• A token made before this change says nothing of its session and is of session 0, like the accounts that were there: the update signs nobody out.

Tests

route/v1_sessions_test.go, each failing before its change:

• a copied token, and the one it was renewed into, after the password changed; the session that changed it goes on;
• the token of an account that is gone;
• the token of an account that is gone, when the next account gets its id;
• a token of before the update: good, then ended by a password change;
• a token of before a reset from the command line;
• a profile saved from a row read before the sessions ended.

go test ./... passes on the four packages.