Flag for disabling locally

Created on 12 January 2024, about 1 year ago

Problem/Motivation

This module is enabled in our configuration, but when the site runs locally or in CI environments, we don't want it to do anything. Is there any flag we can set (like in settings.php) that will prevent the module from doing anything?

πŸ’¬ Support request
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States brockfanning

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @brockfanning
  • πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU

    I don't think there's all that much that the module is doing.

    I am assuming you don't mean that the /saml/* routes should be inaccessible. Just don't use them.

    Then there are a few settings that change 'regular login':

    • Roles allowed to use Drupal login also when associated with a SAML login (drupal_login_roles, array -- in -dev version, this can be set to ['anonymous'] to allow everyone, per πŸ’¬ Design of map_users_roles setting is problematic Fixed . In a currently-released version you must set all allowed roles.)
    • Recently: Auto redirect Drupal login screen to SAML (login_auto_redirect, bool - default false)

    Is it specifically those things (probably the first) that's messing with your local/CI ability to do something? Because I can't think of any other, from the top of my head.

    I don't see the list of settings that influence 'regular' behavior growing much beyond this. So I'm not convinced that an extra configuration option will improve anything. So maybe this is more an issue of documenting this in the README?

  • πŸ‡ͺπŸ‡¨Ecuador jwilson3

    Here is my use case:

    1.- On LOCAL, I cannot use drush uli to login as existing users, because the Drupal login functionality is disabled in favor of University SSO.

    2.- On LOCAL, when I try to create a user I get an exception:

    The website encountered an unexpected error. Please try again later.
    
    Drupal\Core\Entity\EntityStorageException: SP private key not found. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
    Drupal\samlauth\SamlService->getSamlAuth('acs') (Line: 793)
    Drupal\samlauth\SamlService->getAttributeByConfig('user_name_attribute') (Line: 179)
    samlauth_user_presave(Object)
    call_user_func_array(Object, Array) (Line: 409)
    Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'samlauth') (Line: 388)
    Drupal\Core\Extension\ModuleHandler->invokeAllWith('user_presave', Object) (Line: 416)
    Drupal\Core\Extension\ModuleHandler->invokeAll('user_presave', Array) (Line: 215)
    Drupal\Core\Entity\EntityStorageBase->invokeHook('presave', Object) (Line: 900)
    Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('presave', Object) (Line: 529)
    

    3.- I cannot easily disable the samlauth module on LOCAL because it is required by the university-wide distro so I have to also manually edit the distro module dependencies first, then disable the module. This is cumbersome to do manually and hard to document for other devs.

    It would be great if this module had a flag to disable the samlauth_user_presave() hook and other Drupal touchpoints that I can add to settings.local.php to disable the module on LOCAL so that I can create user accounts with different levels of user roles for testing, without having to enable/disable the module and modify the distro module dependencies each time I sync database from PROD.

  • πŸ‡ΊπŸ‡ΈUnited States brockfanning

    I was also suffering from the "SP private key not found" error, when trying to run my automated tests in a CI environment where the key files don't exist (Github Actions in our case).

    In my case, luckily I am able to "drush pmu samlauth" before running the automated tests, so that's the workaround I'm using for now. However I could understand how that would be impossible in the situation that @jwilson3 describes.

  • πŸ‡ΊπŸ‡ΈUnited States jdleonard Austin, TX, USA

    There's a patch that works around item 2 in #3 at https://www.drupal.org/project/samlauth/issues/2925171#comment-14904456 πŸ“Œ Use externalauth::register event vs hook_user_presave Needs work

    • roderik β†’ committed 9f3302b9 on 8.x-3.x
      Issue #3414466 by roderik, rhezios, jwilson3: Prevent samlauth from...
  • πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU

    I'm going to set "fixed", among others for attribution to kick in. Feel free to reopen with extra info / response.

    ===

    Ah, that pesky hook_user_presave. Thanks for pointing me to it. I see it interferes with new user creation.

    Fixed now. I added code that should have the same effect as #2925171-16 but does not need an extra flag.

    For the rest, I'm still not convinced that we need a new flag for "disabling locally". All other reported issues have to do with restricting local login... which can all be unset. And I put some drush commands in the README (see the above commit).

    @jwilson3:

    1.- On LOCAL, I cannot use drush uli to login as existing users, because the Drupal login functionality is disabled in favor of University SSO for all user roles. I dont see an option for login auto-redirect nor is the anonymous user listed as a checkbox in the UI for allowed roles.

    I don't know why drush uli isn't working. It works for me locally Unless my memory is failing me: we are not restricting drush uli because "a user who gained drush access already can do pretty much anything anyway".

    There is now an option for auto-redirecting /user/login to SAML β†’ , which wasn't there yet when you wrote your comment.

    So both cases look like custom code additions. A module flag can't override that custom code, you'll need to get people to change the custom code. (If they are looking for some module config option to use for the basis to decide whether to restrict login: I suggest either of the options we're discussing/documenting here.)

    You don't need to have the "Anonymous" role listed as a checkbox in the UI for allowed roles. What you are looking for is the "Authenticated" role, which every user has. Check that, and every user is allowed to log in.

    4.- It is also less than ideal to have to go to the module configuration screens to change the roles that are allowed to use local Drupal login, this university site has 30 roles.

    5.- Both options 3 and 4 are cumbersome to do manually and hard to document for other devs.

    Not dependent on the number of roles. Just check "Authenticated" and you're good to go. I included the drush command in the README, which seems pretty easy to document: drush config:set --input-format=yaml samlauth.authentication drupal_login_roles '["authenticated"]'.

  • πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU
  • πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024