0bef57591d
Contingent on new feature toggle `VERIFY_USER_CHANGE_UNCONDITIONAL`, check for request/response user mismatches on all requests, not just those setting a session cookie on the response. This is intended to *restore* an older behavior. I believe that almost all requests used to set a new session cookie, and for some reason no longer do, so this is really just an attempt to return to that previous behavior no matter whether a new session cookie will be set. (Previously, the cookie-to-be-deleted check would still have been in effect, so this is actually a slight change from the earlier behavior -- the logout response will now be included, and then quickly ignored due to a later check.) The off-by-default switch moves several lines of code out of a try block, but also out from under an if guard that checks for certain cookie conditions. The movement out of the try block should be irrelevant, since neither of the relocated lines should be raising a SafeCookieError. However, there is some chance that they could raise other exceptions when called from their new location (and new situations), hence the use of a feature toggle -- we'll want to make it easy to switch the new behavior off quickly if we start seeing an increase in errors. Once the change is well-exercised, we can remove the toggle and the old call locations. I'm not entirely sure about the change to the `verify_error` utility function in the unit tests, but it seems like even unauthenticated requests in Django end up with a user and session on the request object, so this is probably a close-enough way to mock that out. I duplicated a couple of tests to test with feature toggle on/off. ref: ARCHBOM-1952
Open edX -------- This is the root package for Open edX. The intent is that all importable code from Open edX will eventually live here, including the code in the lms, cms, and common directories. If you're adding a new Django app, place it in core/djangoapps. If you're adding utilities that require Django, place them in core/djangolib. If you're adding code that defines no Django models or views of its own but is widely useful, put it in core/lib. Note: All new code should be created in this package, and the legacy code will be moved here gradually. For now the code is not structured like this, and hence legacy code will continue to live in a number of different packages.