fix(session): Do not update authtoken last_check for passwordless

[ChristophWurst]

Summary

The column oc_authtoken.last_check is used to debounce the password checks of the login password encoded in app passwords. If instances have set auth.storeCryptedPassword to false, the password column stays NULL and there is no password check. In that case we keep the last_check column updated without any actual check performed. This is superfluous.

How to test

1. Set auth.storeCryptedPassword => false, in config/config.php
2. Open the user security settings and generate an app password
3. Open the oc_authtoken table, find the last row and set last_check to 0
4. Run curl -u "USER:APPPASSWORD" https://localhost/apps/files
5. Look at the updated row in oc_authtoken

Master: last_check is set to the current timestamp. This indicates that there was an UPDATE query.
Here: last_check remains 0.

Note: in reality last_check will stay at the time of token creation. You can skip setting last_check to 0 but then you have to wait more than five minutes between creating and using the token.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[ChristophWurst]

/backport to stable28

[ChristophWurst]

/backport to stable27

[nickvergessen]

Does this reintroduce #29678 ?

[ChristophWurst]

Does this reintroduce #29678 ?

Good catch but I don't think so. The old issue was that we missed to updated last_check when we actually did check the password. Here we skip the update intentionally because no checks are performed.

For the path of password checks the token update is still in place:

server/lib/private/User/Session.php

Line 787 in cc42b2e

$this->tokenProvider->updateToken($dbToken);

The unit test added covers an assertion for the token update.

[ChristophWurst]

Does this reintroduce #29678 ?

Good catch but I don't think so.

Tested by setting the last_activity to 0 and the timestamp is updated.

[kesselb]

/backport to stable26

[kesselb]

/backport to stable29