Moodle

error notice on line 188 of login/index.php seems to show that $userauth is not set

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Won't Fix
  • Affects Version/s: 1.9
  • Fix Version/s: None
  • Component/s: Authentication
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE

Description

Upon login, $userauth is not set leading to a notice. That seems to prevent the following lines from correctly executing. However, some where else in the code, users are still asked to reset their password if needed.

So, if appropriate, $userauth = get_auth_plugin($user->auth); should be added before line 188.

Or, the subsequent code may be redundent and should be eliminated.

Or, notices should be suppressed if this is not an error.

Using latest CVS of Moodle 1.9 Beta

Activity

Hide
Eloy Lafuente (stronk7) added a comment -

Hi Gary,

well spotted!

Right now that's 100% doing nothing!

IMO that stuff should go to complete_user_login(), exactly like the 'auth_forcepasswordchange' one (at least to have all the password expiration possibilities in the same place). There, the $userauth is available and ready to perform any action.

Note that that will require to change slighthy the block of code being moved:

  • $urltogo is not defined yet, so cannot be passed, so something like this should be added:

if (isset($SESSION->wantsurl) and (strpos($SESSION->wantsurl, $CFG->wwwroot) === 0)) { $urltogo = $SESSION->wantsurl; /// Because it's an address in this site unset($SESSION->wantsurl); } else { // no wantsurl stored or external - go to homepage $urltogo = $CFG->wwwroot.'/'; unset($SESSION->wantsurl); }

Or alternative, we can:

1) If the expire is near... in complete_user_login(), set $USER->expirewarning with the value of $userauth->change_password_url() (or standard change_password, if ! $userauth->can_change_password()

and then, in login/index.php, if $USER->expirewarning, show a notice box allowing to change password or continue (and unset that attribute).

2) If the expire has happened... in complete_user_login(), just redirect to the change_password_url.

I really think we should move that function from there. For your consideration... ciao

Show
Eloy Lafuente (stronk7) added a comment - Hi Gary, well spotted! Right now that's 100% doing nothing! IMO that stuff should go to complete_user_login(), exactly like the 'auth_forcepasswordchange' one (at least to have all the password expiration possibilities in the same place). There, the $userauth is available and ready to perform any action. Note that that will require to change slighthy the block of code being moved:
  • $urltogo is not defined yet, so cannot be passed, so something like this should be added:
if (isset($SESSION->wantsurl) and (strpos($SESSION->wantsurl, $CFG->wwwroot) === 0)) { $urltogo = $SESSION->wantsurl; /// Because it's an address in this site unset($SESSION->wantsurl); } else { // no wantsurl stored or external - go to homepage $urltogo = $CFG->wwwroot.'/'; unset($SESSION->wantsurl); } Or alternative, we can: 1) If the expire is near... in complete_user_login(), set $USER->expirewarning with the value of $userauth->change_password_url() (or standard change_password, if ! $userauth->can_change_password() and then, in login/index.php, if $USER->expirewarning, show a notice box allowing to change password or continue (and unset that attribute). 2) If the expire has happened... in complete_user_login(), just redirect to the change_password_url. I really think we should move that function from there. For your consideration... ciao
Hide
Michael de Raadt added a comment -

Thanks for reporting this issue.

We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

Michael d;

lqjjLKA0p6

Show
Michael de Raadt added a comment - Thanks for reporting this issue. We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported. If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed. Michael d; lqjjLKA0p6
Hide
Michael de Raadt added a comment -

I'm closing this issue as it has become inactive and does not appear to affect a current supported version. If you are encountering this problem or one similar, please launch a new issue.

Show
Michael de Raadt added a comment - I'm closing this issue as it has become inactive and does not appear to affect a current supported version. If you are encountering this problem or one similar, please launch a new issue.

People

Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: