fix: don't set session user in getCurrentUserId

[mosi-kha]

Fixes #1452

Problem

setSessionUser(), added in #1376, is called from the first line of getCurrentUserId(). loginWithApache() guards its whole login block on the active user not already being set:

$uid = $backend->getCurrentUserId();
if ($uid) {
    if (self::getUser() !== $uid) {     // <- guard
        ...
        $userSession->createSessionToken($request, $uid, $uid, $password);
        $userSession->createRememberMeToken($userSession->getUser());
        // token scopes, setupFS, post_login hook, UserLoggedInEvent
    }
    return true;
}

IUserSession::setUser() persists user_id into the session, so by the time control reaches the guard it's already satisfied and the entire block is skipped. No oc_authtoken row is ever created for that session.

Impact

Not just app passwords (#1452's original symptom). Session::validateSession() looks up a token by session id on every request that reuses the session cookie; with no row to find, it calls logout(), which strips the cookie. A client that authenticates once with a bearer token and relies on the cookie for follow-up requests gets a 401 on the very next request.

Confirmed independently on master and 8.11.0-dev: bearer request then cookie-only request goes 200 → 401 with the calls in place, 200 → 200 with them removed.

DAV also reaches this code, through its own handleApacheAuth() call site in apps/dav/lib/Connector/Sabre/Auth.php, separate from OC::handleLogin(). Confirmed 207 both before and after this change.

Why a revert

getCurrentUserId() is called before loginWithApache()'s guard, and there's no hook in between — nothing the app does inside getCurrentUserId() can both satisfy the guard and leave a token row behind, since satisfying the guard is what skips the code that creates the row. A "complete the login inside the app" approach was considered and dropped: it only works by keeping the guard closed on purpose, which means maintaining a parallel login path here that has to keep tracking core's.

The setupFS/keygen cost this avoided is real, but it's a separate, filed issue — after this revert, every bearer request without a session cookie re-pays it, same as before #1376.

Testing

composer lint && composer cs:check && composer psalm clean, no baseline changes.

No unit test added — tests/unit/ has no existing coverage of Backend.php, and this is only observable end-to-end (bearer request → cookie reuse), which needs a running server, not a unit fixture.

[solracsf]

Stand-by before merging, I'll try to write a regression tests here.

[solracsf]

Pushed a regression test covering the three bearer return paths: each must resolve the user id without IUserSession::setUser() being called. Red with the setSessionUser() calls, green without.

The psalm dev-master failure is unrelated to this PR, server 95b69fd removed IIndex::hasColumnAtPosition() on Aug 10 and Version01022Date20221202161257.php still calls it. Fix at #1493

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)