Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-70424

Prevent authentication type from being disabled when it is not available on the server.

XMLWordPrintable

    • MOODLE_310_STABLE, MOODLE_311_STABLE, MOODLE_39_STABLE, MOODLE_400_STABLE
    • MOODLE_310_STABLE, MOODLE_39_STABLE
    • MDL-70424-auth-avoid-changes
    • Hide

      1) Set auth to only be manual users:

      php admin/cli/cfg.php --name=auth --set=manual

      2) Confirm that only manual is still set:

      php admin/cli/cfg.php --name=auth
      manual

      3) As an anon user visit the login page: /login/index.php

      4) Confirm there are no errors and you can still login with a manual account

      5) Confirm that still only manual auth is still set:

      php admin/cli/cfg.php --name=auth
      manual

      6) Login as admin and visit /admin/settings.php?section=manageauths which rechecks the plugins

      7) Confirm manual is gone (it is forced on so is redundant)

      $ php admin/cli/cfg.php --name=auth

      8) Set auth to only be a fake broken plugin, and a good plugin:

      php admin/cli/cfg.php --name=auth --set=foobar,ldap

      9) Confirm that both are set:

      php admin/cli/cfg.php --name=auth
      foobar,ldap

      10) As an anon user visit the login page and loads fine

       

      /login/index.php

      11) Confirm that the broken auth is still enabled:

      php admin/cli/cfg.php --name=auth
      manual,foobar

      12) Login as an admin and visit:

      admin/settings.php?section=manageauths

      13) Confirm this has the side effect of refreshing the auth config and now only the valid auth plugin of 'ldap' is left:

      $ php admin/cli/cfg.php --name=auth
      ldap

       

       

       

      Show
      1) Set auth to only be manual users: php admin/cli/cfg.php --name=auth --set=manual 2) Confirm that only manual is still set: php admin/cli/cfg.php --name=auth manual 3) As an anon user visit the login page: /login/index.php 4) Confirm there are no errors and you can still login with a manual account 5) Confirm that still only manual auth is still set: php admin/cli/cfg.php --name=auth manual 6) Login as admin and visit /admin/settings.php?section=manageauths which rechecks the plugins 7) Confirm manual is gone (it is forced on so is redundant) $ php admin/cli/cfg.php --name=auth 8) Set auth to only be a fake broken plugin, and a good plugin: php admin/cli/cfg.php --name=auth --set=foobar,ldap 9) Confirm that both are set: php admin/cli/cfg.php --name=auth foobar,ldap 10) As an anon user visit the login page and loads fine   /login/index.php 11) Confirm that the broken auth is still enabled: php admin/cli/cfg.php --name=auth manual,foobar 12) Login as an admin and visit: admin/settings.php?section=manageauths 13) Confirm this has the side effect of refreshing the auth config and now only the valid auth plugin of 'ldap' is left: $ php admin/cli/cfg.php --name=auth ldap      

      This issue is a continuation of MDL-64865. The previous issue add tracks to the auth disabling but it did not offer a solution to the root of the problem.

      Summary

      To reproduce the issue:

      1. As an admin, go to /admin/category.php?category=authsettings .
      2. Enable an extra authentication plugin (say) - "LDAP server".
      3. Review mdl_config table, notice that row with name="auth" will contain the value "email,ldap".
      4. Remove from the code directory auth/ldap.
      5. As a non logged user (e.g. use another browser) open the login page login/index.php
      6. Notice that "LDAP server" authentication was quietly (no trace of disabling it anywhere) removed. To confirm, review mdl_config table, the "auth" row now just contains "email"

      You can bring the auth/ldap directory back now - but that will not re-enable LDAP authentication plugin.

      Story behind the issue

      The behavior above creates a condition race when some work is done on the backend server (Moodle code is updated,  moved, copied, etc). We have experienced that seemingly random disabling of the authentication plugins in our production systems. Each time there was no trace of why did this happen. And because it happened very rarely (we are talking about few times in the last 10 years) the issue was hard to pin-point. I suspect it was happening somewhere during our deployment process.

      What next?

      Some ideas:

      • Don't ever disable the plugin.
      • If we really should / need to disable it - then at least log it.

            brendanheywood Brendan Heywood
            tusefomal Ferran Recio
            Sam Marshall Sam Marshall
            Eloy Lafuente (stronk7) Eloy Lafuente (stronk7)
            Janelle Barcega Janelle Barcega
            Votes:
            5 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 0 minutes
                0m
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 hour, 25 minutes
                1h 25m

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.