Having to log in twice #32538
Labels
0. Needs triage
Pending check for reproducibility or if it fits our roadmap
25-feedback
bug
feature: authentication
needs review
Needs review to determine if still applicable
Comments
aronmal
added
0. Needs triage
|
Related: #33769. See my analysis. |
|
If you can, please try #33772 with the instructions from https://docs.nextcloud.com/server/latest/admin_manual/issues/applying_patch.html and report back if the added errors logs show up in your nextcloud.log. |
|
I just applied the patch and I will reach back when this bug happen again. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Please apply #33930 as well and sen your logs after you reproduce this issue the next time. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Restart your web server to flush the opcache |
|
OK, I restarted the container now and also the Redis container. I will let you know about the next incident. |
|
Any update? |
|
Not so far. |
|
Just happen again. |
|
|
|
This double (or triple!) need to login sometimes happens to me aswell. |
|
Hi, please update to 24.0.8 or better 25.0.2 and report back if it fixes the issue. Thank you! |
|
I currently cannot reproduce on 25.0.2 |
|
I also haven't noticed this bug so far. I will close this issue. |
|
Bug is still present |
|
In which nc version did you test? |
|
Version Nextcloud Hub 3 (25.0.2) |
4 tasks
|
See #40799 for a small improvement of the error handling. Double login most likely means the PHP session vanished. |
(re)read #40799. |
8 tasks
|
My instance is effectively unusable. Attempting to log in produces a long loop of #40799 messages until suddenly I do seem to get logged in. Looking at the log for such a "successful, but actually not" login, the session token stays valid for about three requests out of the couple dozen that are needed to load the UI. Then I get a (I did apply a few of the additional log info patches, hence why the messages below don't exactly match the code for v27.1.5) |
|
@sclu1034 is it a clustered setup? |
|
No, just a single Docker container on my home NAS. |
|
Another observation: When logging like this in public function isTokenValid(CsrfToken $token): bool {
if (!$this->sessionStorage->hasToken()) {
return false;
}
$sessionToken = $this->sessionStorage->getToken();
$token = $token->getDecryptedValue();
$isEqual = hash_equals(
$sessionToken,
$token
);
\OC::$server->getLogger()->debug('Validating CSRF token: {sessionToken} == {token}', [
'app' => 'core',
'user' => $uid,
'sessionToken' => $sessionToken,
'token' => $token
]);
return $isEqual;
}The resulting log for a chain of failed logins will look like this: I.e. the token that failed to validate on the first request will be the one checked against on the next request, and so on. |
|
So I just caught one of the "kicked out after the session timed out over night": (Read bottom up) Navigating to But then for every subsequent request another CSRF token is generated at server/lib/private/Security/CSRF/CsrfTokenManager.php Lines 58 to 59 in 81ed6d6 And they also all fail at server/lib/private/User/Session.php Lines 897 to 902 in 81ed6d6 Evidently they didn't share the session from the initial url=/ request.
Which is then confirmed by the eventual CSRF validations. The right token is the one from the page, and it properly matches the one generated for |
that matches observations of @juliushaertl. he had auth issues on CI which went away once the service worker was blocked |
|
Is that confirmed to be the actual cause, though, or just correlation? E.g. if the underlying issue is a race condition, the service worker might simply be the only request fast enough to trigger it. |
|
Here's another case: This time, the |
|
Even weirder case, now the flow for Or in this instance, where I first reload the page, which creates a new token for the form. Then I submit the form, and it creates a new token before validating the login. |
|
I can confirm this bug. My instance is nearly unusable. Has anyone already found a workaround? |
Do any of you have a reverse proxy in front? Make sure any caching/caching manipulation is completely off. |
joshtrichards
added
the
needs review
|
Hi i hope it was clear what i mean Nextcloud Version: 29.0.7 |
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
I am running my own server. I am usually logged in. Since a long time, I am getting auto locked out. Should be always after about a week I think, which I do not like, but for security reasons it hasn't bothered so far. But what bothered me is, I need to login twice. I also have 2FA enabled and thought it might be because of that and when I visit:
https://mydomain.com/apps/calendar/ -> redirects to: https://mydomain.com/login?redirect_url=/apps/calendar/
So I thought it was a problem with the '?redirect_url=' part, but can't reproduce this in incognito.
I login, have to login again, 2FA code, and then being logged in. But when I do this in a incognito tab, I only have to login once plus the 2FA code. This must mean, I seem not to be fully auto logged out (?), because I only have a page refresh the first time which maybe clears my login cookies or something in that direction, so it recognizes the second login attempt?
Steps to reproduce
Expected behavior
Only having to login once and enter the 2FA code.
Installation method
Manual installation
Operating system
Debian/Ubuntu
PHP engine version
PHP 7.4
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
No response
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "memcache.local": "\\OC\\Memcache\\APCu", "memcache.distributed": "\\OC\\Memcache\\Redis", "memcache.locking": "\\OC\\Memcache\\Redis", "filelocking.enabled": "true", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 6379, "timeout": 0 }, "datadirectory": "***REMOVED SENSITIVE VALUE***", "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "next.mal-noh.de", "next.limited-dev.de" ], "dbtype": "mysql", "version": "23.0.4.1", "trusted_proxies": "***REMOVED SENSITIVE VALUE***", "overwriteprotocol": "https", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "updatechecker": true, "updater.release.channel": "stable", "maintenance": false, "theme": "", "loglevel": 0, "default_language": "de", "default_locale": "de", "default_phone_region": "DE", "mail_smtpmode": "smtp", "mail_smtpsecure": "tls", "mail_sendmailmode": "smtp", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "587", "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "trashbin_retention_obligation": "auto, 30", "versions_retention_obligation": "auto, 60", "overwrite.cli.url": "https:\/\/next.mal-noh.de" } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: