The 'None' auth needs to be locked down or removed to avoid troubles with multi institutions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Fix Released
|
High
|
Robert Lyon | ||
16.04 |
Fix Released
|
High
|
Unassigned | ||
16.10 |
Fix Released
|
High
|
Unassigned | ||
17.04 |
Fix Released
|
High
|
Unassigned | ||
17.10 |
Fix Released
|
High
|
Robert Lyon |
Bug Description
When there are multiple institutions/
Things that need to be changed to avoid this problem:
1) When an institution tries to add the 'None' auth option it needs to check to see if there are any other institutions present and only allow it if institution count = 1
2) Conversely if the only institution uses 'None' auth then you shouldn't be allowed to add a new institution until that auth is removed
3) And when you are able to add "None" you should probably get some prominent message with "Do you really want to do this? You know, it means that anybody will be able to log in without any authorization"
Also as part of this change it would be very good to add a ctime (and maybe userid) field to the auth_instance table to record when one adds/edits auth details to see when things changed as this human error can cause big problems for users.
Changed in mahara: | |
milestone: | none → 17.04.0 |
Changed in mahara: | |
milestone: | 17.04.0 → 17.10.0 |
Changed in mahara: | |
status: | In Progress → Confirmed |
tags: | added: usermanualupdate |
On further discussion with Robert, we've agreed that the best thing to do is simply to remove the "none" authentication method from Mahara core entirely. So the plan is roughly this:
1. Remove the "auth/none" plugin directory from Mahara
2. Put the auth/none code into a separate git repository, so it can be downloaded and installed separately by sites that actually do want to use it.
3. Put migration code in place, that will find any institutions that have "None" as their only auth method, and set up an Internal auth method for them.
4. Further migration code that finds any users who are set to a "None" auth method, and converts them to an Internal auth method (without a password)
5. A note in the README that indicates that the "none" auth method was removed and that if you're a site that is seriously using it, you should add the plugin back into your site before running the upgrade script, or your users will be migrated from "None" to "Internal"
6. Make sure that the migration code in steps 3 & 4 checks to see if you have, indeed, downloaded and installed the new optional None plugin. And if you have, it doesn't migrate the users, because apparently you actually are using the plugin.
7. And optionally, to provide better support for sites that do the "copy-over" upgrade, make the migration code check to see if you have the *old* version of the "None" plugin present in your site, and if so, disable it.