The "Allow SAML users to login directly with Drupal" is not working as expected. When the checkbox is not flagged, SAML users can still login via Drupal; when it's flagged, they can't.
In fact the check on the authmap table happens only when the corresponding variable is TRUE:
function samlauth_check_saml_user($form, $form_state) {
if (variable_get('samlauth_drupal_saml_login', FALSE)) {
if (form_get_errors()) {
While on branch 8.x-3.x the same variable has the opposite meaning:
function samlauth_check_saml_user($form, FormStateInterface $form_state) {
if (!\Drupal::config('samlauth.authentication')->get('drupal_saml_login')) {
if ($form_state->hasAnyErrors()) {
Possible solutions:
- Fix the current logic and keep existing values as is, breaking the backward compatibility
- Fix the current logic and run an update on any existing variable
- Update the variable description or use a different variable
Comments
Comment #2
nironan commentedFirst attempt, following option #1
Comment #3
nironan commentedFound another bug on the same check.
At line 126, there's a call to function samlauth_find_unique_id_by_user_id($uid), which runs a db_select using the uid account. The result is checked at 127 via is_null(), which is always TRUE since the result of fetchField() is either the samlauth username or FALSE (hence: never NULL). This results in local non-SAML accounts being denied the login.
Attached is patch which checks that sets the form to error only when the fetchField() result is not false .
Comment #5
roderikThank you; committed. (I also changed the checkbox description to be equal to what it was in D8, even though it's now even longer. Mainly I think the "Drupal login is hidden" bit was confusing, since that technically has no effect.)
I agree we should just change the behavior (option 1). We can't know with 100% certainty, but it's likely that what people want their site to do, is what the checkbox setting actually says.