Validate user login capability on each request. #2883
+45
−38
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently the login capability of a user is only ever checked on initial sign in, and never again. So if a user logs in, and then the status or permission level of the user is changed so that the user no longer has the `allow_course_access` behavior or `login` permission level, then the user's current session remains valid, and the user may continue to work in the course (including submitting answers). This changes that so that those things are checked on each request. So, for example, if a user is dropped (status changed to "D"), then the next thing the user tries to do in the course that involves a request to the server will result in the user being logged out. This was reported for the Shibboleth authentication module in issue openwebwork#2827, but really is an issue for all authentication modules. So this more generally fixes issue openwebwork#2827 for all authentication modules. This has been tested for all functional authentication modules (i.e., for all but the `CAS` and `Moodle` authentication modules. If the `CAS` module is fixed this should work for that as well. I plan to remove the `Moodle` authentication module in another pull request. Note that this is done in such a way that no new database queries are needed. To make this happen the user record is cached in the `check_user` call, and then can be used any time after that. Future plans are to take this much further. There are many times in the code that the database record for the current user is fetched from the database, and now this cached user record from the current authentication module could directly be used instead.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the login capability of a user is only ever checked on initial sign in, and never again. So if a user logs in, and then the status or permission level of the user is changed so that the user no longer has the
allow_course_accessbehavior orloginpermission level, then the user's current session remains valid, and the user may continue to work in the course (including submitting answers).This changes that so that those things are checked on each request. So, for example, if a user is dropped (status changed to "D"), then the next thing the user tries to do in the course that involves a request to the server will result in the user being logged out.
This was reported for the Shibboleth authentication module in issue #2827, but really is an issue for all authentication modules. So this more generally fixes issue #2827 for all authentication modules.
This has been tested for all functional authentication modules (i.e., for all but the
CASandMoodleauthentication modules. If theCASmodule is fixed this should work for that as well. I plan to remove theMoodleauthentication module in another pull request.Note that this is done in such a way that no new database queries are needed. To make this happen the user record is cached in the
check_usercall, and then can be used any time after that. Future plans are to take this much further. There are many times in the code that the database record for the current user is fetched from the database, and now this cached user record from the current authentication module could directly be used instead.