Validate user login capability on each request.#2883
Merged
somiaj merged 1 commit intoopenwebwork:developfrom Feb 1, 2026
Merged
Validate user login capability on each request.#2883somiaj merged 1 commit intoopenwebwork:developfrom
somiaj merged 1 commit intoopenwebwork:developfrom
Conversation
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.
drgrice1
force-pushed
the
validate-user-login-each-request
branch
from
22eddd9 to
326890f
Compare
pstaabp
approved these changes
Jan 31, 2026
Member
pstaabp
left a comment
pstaabp
left a comment
There was a problem hiding this comment.
Checked for the basic authentication method.
somiaj
approved these changes
Feb 1, 2026
Contributor
somiaj
left a comment
somiaj
left a comment
There was a problem hiding this comment.
Confirmed it fixed the issue raised.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.