nextcloud
checkToken verification fails when IMAP is used as backend.
Steps to reproduce
- Configure IMAP backend for authentication, with SSL
Expected behaviour
User should be able to maintain the session open more than 5 minutes
Actual behaviour
Sessions are closed after 5 minutes
Affected Authentication backend
IMAP (at least)
Server configuration
0.6.1 Ubuntu 18.04 Apache Mariadb 7.0.33 Nextcloud 15.0.7 Updated from previous version
I previously updated a core issue:
https://github.com/nextcloud/server/issues/11120
I will reproduce the key findings here:
So after several sessions of debug, we found lib/private/User/Session.php, line 680: function checkToken:
680 private function checkTokenCredentials(IToken $dbToken, $token) { 681 // Check whether login credentials are still valid and the user was not disabled 682 // This check is performed each 5 minutes 683 $lastCheck = $dbToken->getLastCheck() ? : 0; 684 $now = $this->timeFactory->getTime(); 685 if ($lastCheck > ($now - 60 * 5)) { 686 // Checked performed recently, nothing to do now 687 return true; 688 } 689 690 try { 691 $pwd = $this->tokenProvider->getPassword($dbToken, $token); 692 } catch (InvalidTokenException $ex) { 693 // An invalid token password was used -> log user out 694 return false; 695 } catch (PasswordlessTokenException $ex) { 696 // Token has no password 697 698 if (!is_null($this->activeUser) && !$this->activeUser->isEnabled()) { 699 $this->tokenProvider->invalidateToken($token); 700 return false; 701 } 702 703 $dbToken->setLastCheck($now); 704 return true; 705 }
Nextcloud is checking the password again after 5 minutes. Unfortunately, external_user must be missing something here, and the test always fails. As a result, the token is invalidated and the session must start again.
As a mitigation (in order to avoid user's rage) we have changed the time to 5000 minutes:
685 if ($lastCheck > ($now - 60 * 5000)) {
This is something we would rather don't do, as it opens the door to unsynced password problems.
hmm, do you have the users only registered over user_external and not on an other user backend as well?
no you explicitly should not have more than one backend which authenticates the same username... this issue reminds me of #3 which is caused by the admin having multiple backends (nextclouds own and user_external IMAP) for the same usernames... that's why I'm asking...
@ChristophWurst do you have an idea what could be causing this?
Then this issue is a real bug of user_external, and not a misconfiguration.
@ediazcomellas considering that user_external only does the authentication itself and not the session management, it could also be an issue in the core of nextcloud... anyway, as long as this is not reliably reproducible (seems still to depend on some other unknown factor(s), because it's still working for most users (inkluding me) with the IMAP backend) it's quite hard to discover what's going wrong... If you have an idea how to fix it, you're more than welcome to provide a PR...
