Flag for disabling locally

Created on 12 January 2024, 6 months ago
Updated 28 January 2024, 5 months 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

Production build 0.69.0 2024