We have students ranging in age from 5 to 18, and we want the littlest kids to be able to log in with very simple passwords (e.g., "cat", "dog", etc.). Those are obviously dangerous passwords to use on an Internet-accessible system, and yet older students, not to mention the teachers of these younger students, need to be able to access the same moodle from outside the school network.
So I'm contemplating writing an IP-based login restriction mechanism for these younger students' accounts.
As far as I can tell, Moodle does not currently have a feature like this for limiting logins. (I know the quiz module, at least, has an IP-range-limiting feature.)
Are others interested in a feature like this? Is it already there in some form I haven't recognized?
Cheers,
Matt
mdl_user_auth_criteria ( id integer, userid integer, criteriaid integer ); mdl_auth_criteria ( id integer, # from what network (if specified) is auth allowed? network text, netmask text, # between which dates (if specified) is auth allowed? begindate integer, enddate integer, # between which times of day (if specified) is auth allowed? begintime integer, endtime integer, );
...but now I realize the roles/capabilities system could perhaps take care of these same things quite naturally. I'll need to learn more about it to know if we could have (or there already is) an "authenticating user" role and there could be capabilities like "can authenticate from xxx.xxx.xxx.xxx/yy network at (optionally) date/time".
I need to implement *something* relatively soon here, and I'd rather implement something that fits naturally into Moodle and that other people could also use. So if you're interested at all, please let me know.
Cheers,Matt
While it's not already there in the form you need, part of the infrastructure is available.
There was some talk during the 1.6 (or 1.7 can't remember it now) planning, to make the authentication system behave like the Unix PAM auth system, where you can stack modules. The idea was to be able to have multiple auth subsystems enabled at the same time. (Edit: I've found the thread where it was discussed: http://moodle.org/mod/forum/discuss.php?d=31863)
The final result wasn't like PAM, but the login logic was changed a bit and several constants were defined (in lib/authlib.php) to be able to make stackable modules a possibility, but we didn't change the login logic.
So instead of auth plugins returning true/false, they should return AUTH_OK, AUTH_FAIL, AUTH_DENIED, AUTH_ERROR (these names don't match with the names used by Martin L. in his description but are the same conceptually). And the login code (probably inside authenticate_user_login()) should implement the loop Martin L. describes.
This way, implementing new types of black lists should be as easy as adding new auth plugins. They are self contained (no need to patch core further), have their own settings storage (no need to add/modify tables) and can be ordered the way you want to get almost any desired effect (e.g. block this ip range irrespective of the user vs block this user if it comes from this ip range).
What do you think?
More as I progress....
--matt
Dare I propose an auth plugin that has its own database table(s)?
As far as I know, there's nothing that prevents auth/enrol plugins from having their own tables. For instance, enrol/authorize and enrol/paypal have several of them, so auth/blacklist-user-ip[*] could have their own tables too
Saludos, Iñaki.
[*] the auth plugin name must conform to PARAM_SAFEDIR specifications (see clean_param() in lib/moodlelib.php)
And thx for the SAFEDIR tip. I had already counted filenames in the source tree with '-' and '_', and decided on auth/blacklist_ipaddr...looks like both hyphens and underscores are acceptable, though.
Cheers,
Matt
I've created a tracker issue and submitted an initial patch to make the necessary core changes:
http://tracker.moodle.org/browse/MDL-20772
What do you think?
Thanks,
Matt
Sorry about the delay. This last 2 weeks at work have been like a black hole, absorbing all my time.
I'll comment on the tracker
Saludos, Iñaki.