Steps to reproduce
#9008 doesn't work if the user never had a password to begin with. This is the case in my environment as none of my users were created with a password, they were all created via user_saml. Specifically, when a user doesn't have a password and an exception is raised, updatePassword() isn't called.
|
try { |
|
$this->provisioningManager->provisionSingleUser($configs, $user); |
|
$password = $this->credentialStore->getLoginCredentials()->getPassword(); |
|
|
|
// FIXME: Need to check for an empty string here too? |
|
// The password is empty (and not null) when using WebAuthn passwordless login. |
|
// Maybe research other providers as well. |
|
// Ref \OCA\Mail\Controller\PageController::index() |
|
// -> inital state for password-is-unavailable |
|
if ($password === null) { |
|
// Nothing to update, might be passwordless signin |
|
$this->logger->debug('No password set for ' . $user->getUID()); |
|
return; |
|
} |
|
$this->provisioningManager->updatePassword( |
|
$user, |
|
$password, |
|
$configs |
|
); |
|
} catch (CredentialsUnavailableException | PasswordUnavailableException $e) { |
|
// Nothing to update |
|
return; |
|
} |
I am not sure why the password logic is split between two places like this when it seems the only place updatePassword is used is in the tests. Could all of this logic be moved into the updatePassword function for simplicity and also to help fix this regression? I am not a NC dev so I don't know if this split is a requirement for some reason.
I have monkeypatched this in my environment by always calling updatePassword with the empty string as a password, which is then overriden in the function by the master password; this is not an issue since none of my provisionable users have a password set anyway, I always use master password.
Expected behavior
All provisioned users can log in, regardless of if they have ever set a password or not.
Actual behavior
Users that have a password set and have signed in via SSO will be able to use provisioned accounts with master password. Users that have never set a password inside Nextcloud will cause an error when attempting to use provisioned accounts with master password.
Mail app version
3.5.0-rc2 + patch
The bug continues to exist in 3.5.0 final.
Mailserver or service
Dovecot
Operating system
Alpine Linux Edge
PHP engine version
PHP 8.2
Web server
Nginx
Database
PostgreSQL
Additional info
No response
Steps to reproduce
#9008 doesn't work if the user never had a password to begin with. This is the case in my environment as none of my users were created with a password, they were all created via
user_saml. Specifically, when a user doesn't have a password and an exception is raised,updatePassword()isn't called.mail/lib/Http/Middleware/ProvisioningMiddleware.php
Lines 70 to 92 in 3fc016f
I am not sure why the password logic is split between two places like this when it seems the only place
updatePasswordis used is in the tests. Could all of this logic be moved into theupdatePasswordfunction for simplicity and also to help fix this regression? I am not a NC dev so I don't know if this split is a requirement for some reason.I have monkeypatched this in my environment by always calling
updatePasswordwith the empty string as a password, which is then overriden in the function by the master password; this is not an issue since none of my provisionable users have a password set anyway, I always use master password.Expected behavior
All provisioned users can log in, regardless of if they have ever set a password or not.
Actual behavior
Users that have a password set and have signed in via SSO will be able to use provisioned accounts with master password. Users that have never set a password inside Nextcloud will cause an error when attempting to use provisioned accounts with master password.
Mail app version
3.5.0-rc2 + patch
The bug continues to exist in 3.5.0 final.
Mailserver or service
Dovecot
Operating system
Alpine Linux Edge
PHP engine version
PHP 8.2
Web server
Nginx
Database
PostgreSQL
Additional info
No response