Problem/Motivation
In issue #3023470: Provide consistent response from createDrupalUser and calling functions and commit d492750c \Drupal\ldap_user\Processor\DrupalUserProcessor::provisionDrupalAccount() returns FALSE if DrupalUserProcessor::createDrupalUser() returns FALSE, however DrupalUserProcessor::createDrupalUser() doesn't always return a Boolean, once $this->saveAccount() is called the function effectively returns NULL meaning that the if statement at the end of DrupalUserProcessor::provisionDrupalAccount() will always evaluate to FALSE even if the user has been created.
In reality the result of this is that when for example LDAP SSO creates a new User by the user navigating to /user/login/sso, instead of the User being automatically logged in they will be taken back to the login form with the error message Sorry, your LDAP credentials were not found or the LDAP server is not available. You may log in with other credentials on the login form., however in reality the new User is still created so by navigating to /user/login/sso again they are automatically logged in on every future login attempt.
Comments
Comment #2
aaronmchaleSo this patch technically fixes the issue but since
$this->saveAccount()doesn't actually return anything and the next lineif (!$this->account) {as far as I can tell will never actually evaluate toTRUE, so I'm not totally convinced that the error handling in place to catch and inform of the User Entity saving failing will work.If the User Entity does fail to save
\Drupal\Core\Entity\EntityStorageExceptionwill be thrown (see EntityInterface::save), which as far as I can tell means that this is redundant:So, I'm setting to needs review because technically speaking the user-facing issue is resolved, but in my opinion
DrupalUserProcessor::createDrupalUsershould either: always returnTRUEbeyond$this->saveAccount()and the if statement after it should just be removed, or wrap$this->saveAccount()in a try catch block and returnFALSEif\Drupal\Core\Entity\EntityStorageExceptionis thrown. However, I'm not at all a fan of catching exceptions like that, because if an exception is thrown in the Entity Storage you really need that to bubble up so that the administrator becomes aware of it. So in my opinion the end ofDrupalUserProcessor::createDrupalUserreally should just look like:Because, again, if something did do wrong at
$this->saveAccount()the next line will never be reached because\Drupal\Core\Entity\EntityStorageExceptionwill be thrown.Comment #4
grahlHi Aaron
Thanks for the detailed feedback, your explanation makes perfect sense. I've therefore removed the unreachable check as suggested from the 4.x branch (since we already got another TRUE result in 3.x in the other issue). The return values are a bit of a mess in 4.x at the moment so it returns nothing but I'll fix that in #3023470: Provide consistent response from createDrupalUser and calling functions.
Comment #5
aaronmchale@grahl great thanks for that