Change Details

Allow granular permissions to be defined and assigned to roles. Security will be implemented two-fold, firstly the User and Admin values in the status field on users will now be used for determining if a user is currently active or not. These checks will be done before applying roles to the current user. The next stage is every page will implicitly require permissions at an action level. These permissions will mostly be defined implicitly, such as `PageWelcomeTemplate/create`, and as such don't need to be declared or tested by the page. `InternalPageBase` will still handle the actual security barrier and displaying this to the user, but only in the capacity of implementing the decision. `SecurityManager` will be responsible for making the decision. Identification checking will be done on a role-by-role basis. If a role requires (or rather, is not exempt) from identification checks, it won't be considered by `SecurityManager` in the list of rights granted to a user, unless the check is a rejection, in which case it will be considered to see if the user would have had that right to choose a more correct error condition (not allowed vs not identified) == User changes == * [ ] The user status column values will be replaced with "Active". * [ ] The checkuser column will also be dropped. == Roles == Roles are to be defined in a single place, probably a static class called `RoleConfiguration`. * [ ] Create three roles - user, admin and checkuser. Assign rights approximately as they are defined currently, skipping duplicated rights as needed, such that a checkuser access is distinct from tool admin, but such that they can perform the tasks they need to * [ ] Role allocation to users will be done by a new database table storing a unique set of user IDs and role names. Table to be managed using the standard `DataObject` infrastructure. * [ ] Migrate all users to relevant roles. {F7389} == Page access control == * [x] Kill off `getSecurityConfiguration()`. * [x] Modify `InternalPageBase` to pass authorisation requests to a helper class. * [x] Create some way for pages to explicitly skip all access checks (so you don't get access denied errors because you're not logged in while loading the login form...). This is to only be used for "critical" pages that break the tool if they're forbidden at any time, such as the login form. * [x] Implement some explicit rights check barrier that pages can use for determining user access, similar to `barrierTest` in cases such as displaying an edit button vs a view button * [x] Kill off `barrierTest()` accesses from templates. This was a bad idea when I wrote it. == Security manager == Rough process will be: 1) Request received by security manager for rights check 2) Security manager requests roles for user. 3) Check identification status of user 4) Split roles user has by `($roleRequiresIdentification && $userIdentified || !$roleRequiresIdentification)` 5) Cache steps 2 through 4. 5) Take first pile of roles and check the requested right exists in the set. If so, return success. 6) Take the second pile of roles and check the requested right exists in the set. If so, return ERR_NOT_IDENTIFIED. 7) Return general failure. * [x] Implement it * [ ] Unit test the hell out of this. * [ ] Caching (check performance when not remote) == Registration == * [ ] Generalise the registration form, so different instances can assign users to a different initial role. * [ ] Figure out the UX for getting to the right signup form. Perhaps a pre-signup step along the lines of a wizard? == User management == * [ ] The standard promote/demote workflow actions are now not applicable. We need a way of granting/removing roles from users. Special:GroupPermissions is probably going to be the inspiration for this. * [ ] Think of a way to stop tool admins granting themselves checkuser access. Probably something similar to `$wgAddGroups` defined in `RoleConfiguration` * [ ] Adapt the user status buttons as applicable - probably won't need many changes. == Misc == * [ ] Update documentation * [ ] Deprecate `User::isCheckuser()` * [ ] Deprecate `User::isAdmin()` = Todo checklist for various things = == `barrierTest` Shenanigans == * [x] `main-with-data.tpl` looks at a setBan barrier test, this needs to be ripped out, should be easy * [x] `RequestData` does a barrier test to check private data access. This must be moved, and is probably hard to deal with, as it makes assumptions that the reserving user is allowed private data access. * [x] `templates/welcome-template/list.tpl` * [x] `templates/bans/banlist.tpl` * [x] `templates/email-management/main.tpl` * [x] `templates/email-management/template-table.tpl`

Allow granular permissions to be defined and assigned to roles. Security will be implemented two-fold, firstly the User and Admin values in the status field on users will now be used for determining if a user is currently active or not. These checks will be done before applying roles to the current user. The next stage is every page will implicitly require permissions at an action level. These permissions will mostly be defined implicitly, such as `PageWelcomeTemplate/create`, and as such don't need to be declared or tested by the page. `InternalPageBase` will still handle the actual security barrier and displaying this to the user, but only in the capacity of implementing the decision. `SecurityManager` will be responsible for making the decision. Identification checking will be done on a role-by-role basis. If a role requires (or rather, is not exempt) from identification checks, it won't be considered by `SecurityManager` in the list of rights granted to a user, unless the check is a rejection, in which case it will be considered to see if the user would have had that right to choose a more correct error condition (not allowed vs not identified) == User changes == * [ ] The user status column values will be replaced with "Active". * [ ] The checkuser column will also be dropped. == Roles == Roles are to be defined in a single place, probably a static class called `RoleConfiguration`. * [ ] Create three roles - user, admin and checkuser. Assign rights approximately as they are defined currently, skipping duplicated rights as needed, such that a checkuser access is distinct from tool admin, but such that they can perform the tasks they need to * [ ] Role allocation to users will be done by a new database table storing a unique set of user IDs and role names. Table to be managed using the standard `DataObject` infrastructure. * [ ] Migrate all users to relevant roles. {F7389} == Page access control == * [x] Kill off `getSecurityConfiguration()`. * [x] Modify `InternalPageBase` to pass authorisation requests to a helper class. * [x] Create some way for pages to explicitly skip all access checks (so you don't get access denied errors because you're not logged in while loading the login form...). This is to only be used for "critical" pages that break the tool if they're forbidden at any time, such as the login form. * [x] Implement some explicit rights check barrier that pages can use for determining user access, similar to `barrierTest` in cases such as displaying an edit button vs a view button * [x] Kill off `barrierTest()` accesses from templates. This was a bad idea when I wrote it. == Security manager == Rough process will be: 1) Request received by security manager for rights check 2) Security manager requests roles for user. 3) Check identification status of user 4) Split roles user has by `($roleRequiresIdentification && $userIdentified || !$roleRequiresIdentification)` 5) Cache steps 2 through 4. 5) Take first pile of roles and check the requested right exists in the set. If so, return success. 6) Take the second pile of roles and check the requested right exists in the set. If so, return ERR_NOT_IDENTIFIED. 7) Return general failure. * [x] Implement it * [ ] Unit test the hell out of this. * [ ] Caching (check performance when not remote) == Registration == * [ ] Generalise the registration form, so different instances can assign users to a different initial role. * [ ] Figure out the UX for getting to the right signup form. Perhaps a pre-signup step along the lines of a wizard? == User management == * [ ] The standard promote/demote workflow actions are now not applicable. We need a way of granting/removing roles from users. Special:GroupPermissions is probably going to be the inspiration for this. * [ ] Think of a way to stop tool admins granting themselves checkuser access. Probably something similar to `$wgAddGroups` defined in `RoleConfiguration` * [ ] Adapt the user status buttons as applicable - probably won't need many changes. == Misc == * [ ] Update documentation * [ ] Deprecate `User::isCheckuser()` * [ ] Deprecate `User::isAdmin()` = Todo checklist for various things = == `barrierTest` Shenanigans == * [x] `main-with-data.tpl` looks at a setBan barrier test, this needs to be ripped out, should be easy * [x] `RequestData` does a barrier test to check private data access. This must be moved, and is probably hard to deal with, as it makes assumptions that the reserving user is allowed private data access. * [x] `templates/welcome-template/list.tpl` * [x] `templates/bans/banlist.tpl` * [x] `templates/email-management/main.tpl` * [x] `templates/email-management/template-table.tpl` == Other assorted crap == * [ ] Admin-only comments should probably be renamed.

Allow granular permissions to be defined and assigned to roles. Security will be implemented two-fold, firstly the User and Admin values in the status field on users will now be used for determining if a user is currently active or not. These checks will be done before applying roles to the current user. The next stage is every page will implicitly require permissions at an action level. These permissions will mostly be defined implicitly, such as `PageWelcomeTemplate/create`, and as such don't need to be declared or tested by the page. `InternalPageBase` will still handle the actual security barrier and displaying this to the user, but only in the capacity of implementing the decision. `SecurityManager` will be responsible for making the decision. Identification checking will be done on a role-by-role basis. If a role requires (or rather, is not exempt) from identification checks, it won't be considered by `SecurityManager` in the list of rights granted to a user, unless the check is a rejection, in which case it will be considered to see if the user would have had that right to choose a more correct error condition (not allowed vs not identified) == User changes == * [ ] The user status column values will be replaced with "Active". * [ ] The checkuser column will also be dropped. == Roles == Roles are to be defined in a single place, probably a static class called `RoleConfiguration`. * [ ] Create three roles - user, admin and checkuser. Assign rights approximately as they are defined currently, skipping duplicated rights as needed, such that a checkuser access is distinct from tool admin, but such that they can perform the tasks they need to * [ ] Role allocation to users will be done by a new database table storing a unique set of user IDs and role names. Table to be managed using the standard `DataObject` infrastructure. * [ ] Migrate all users to relevant roles. {F7389} == Page access control == * [x] Kill off `getSecurityConfiguration()`. * [x] Modify `InternalPageBase` to pass authorisation requests to a helper class. * [x] Create some way for pages to explicitly skip all access checks (so you don't get access denied errors because you're not logged in while loading the login form...). This is to only be used for "critical" pages that break the tool if they're forbidden at any time, such as the login form. * [x] Implement some explicit rights check barrier that pages can use for determining user access, similar to `barrierTest` in cases such as displaying an edit button vs a view button * [x] Kill off `barrierTest()` accesses from templates. This was a bad idea when I wrote it. == Security manager == Rough process will be: 1) Request received by security manager for rights check 2) Security manager requests roles for user. 3) Check identification status of user 4) Split roles user has by `($roleRequiresIdentification && $userIdentified || !$roleRequiresIdentification)` 5) Cache steps 2 through 4. 5) Take first pile of roles and check the requested right exists in the set. If so, return success. 6) Take the second pile of roles and check the requested right exists in the set. If so, return ERR_NOT_IDENTIFIED. 7) Return general failure. * [x] Implement it * [ ] Unit test the hell out of this. * [ ] Caching (check performance when not remote) == Registration == * [ ] Generalise the registration form, so different instances can assign users to a different initial role. * [ ] Figure out the UX for getting to the right signup form. Perhaps a pre-signup step along the lines of a wizard? == User management == * [ ] The standard promote/demote workflow actions are now not applicable. We need a way of granting/removing roles from users. Special:GroupPermissions is probably going to be the inspiration for this. * [ ] Think of a way to stop tool admins granting themselves checkuser access. Probably something similar to `$wgAddGroups` defined in `RoleConfiguration` * [ ] Adapt the user status buttons as applicable - probably won't need many changes. == Misc == * [ ] Update documentation * [ ] Deprecate `User::isCheckuser()` * [ ] Deprecate `User::isAdmin()` = Todo checklist for various things = == `barrierTest` Shenanigans == * [x] `main-with-data.tpl` looks at a setBan barrier test, this needs to be ripped out, should be easy * [x] `RequestData` does a barrier test to check private data access. This must be moved, and is probably hard to deal with, as it makes assumptions that the reserving user is allowed private data access. * [x] `templates/welcome-template/list.tpl` * [x] `templates/bans/banlist.tpl` * [x] `templates/email-management/main.tpl` * [x] `templates/email-management/template-table.tpl` == Other assorted crap == * [ ] Admin-only comments should probably be renamed.