The user must be (effectively) be logged in to use this function.
Adding the logged in check means they will be asked if they are not (like
everywhere else).
Merged from STABLE19
print_error()'s third parameter is the URL we jump to (defaults to
$CFG->wwwroot if not set) when we click the 'Continue' button, not the message
string parameter object.
Forward ported from MOODLE_18_STABLE
It was still using the 'old' get_config() interface, so the 'cookie'
set by ntlmsso_finish() wasn't retrieved at all, and the automatic
login always failed.
Signed-off-by: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Author: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Committer: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Author: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Committer: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Author: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Committer: Martin Langhoff <martin@catalyst.net.nz>
Now the DNs that indicate a course-creator role can also be contexts.
This way we support one more widely used practice in the weird and
wonderful LDAP world...
cache_flags is now the apropriate way to manage this kind of temp
data. It gives us time expiry and GC for free, so it's a perfect fit
for the job, as it simplifies the code a bit.
From Iñaki Arenaza - fix for
... I forgot to put the textlib conversion
call before the block of code that uses $extusername, so it
completely breaks the user validation process.
Fix a bug in ntlmsso_finish(), and tighten up user_login() to avoid a
pointless DB lookup if the password doesn't match the sesskey.
Hopefully this makes things work again...
(thanks I~naki for the testing!)
Several tidyups:
- use moodle_strtolower() for utf-8 correctness
- use sesskey as the key instead of IP addr to support
proxied users
- clean the sesskey after success!
- pull timeout out to a constant: AUTH_NTLMTIMEOUT
From Iñaki Arenaza...
Right now, if someone logs in via NTLM magic, we don't check if that
user is inside the contexts specified in the LDAP settings. I mean,
if I want to restrict my Moodle site to those users inside a given OU
or subtree of my LDAP directory, with the current code any valid user
in my whole AD domain (and if we are using a GC as the LDAP server,
the whole forest) can log in. We should check that the user is inside
one of the configured contexts before allowing his/her to log in.
Something along the lines of the attached patch could do it.
