This reverts commit 0517603b6d.
This was masking a LabXchange error by blowing up with:
"Stack trace builtins:AttributeError: 'NoneType' object has no attribute 'status_code'"
The management command to generate certificates for users on a course's
allowlist (formerly whitelist) now allows for database arguments to
allow it to be called outside of a manual shell.
The mobile app is getting unexpected 403s from
/oauth2/exchange_access_token/, but we have been unable
to pinpoint from where they are coming. This commit
introduces a temporary exception handler to provide stack info
for 403s on this endpoint to try to track down the source.
Requires the ENABLE_403_MONITORING setting to be set to
True to enable the logging.
ARCHBOM-1667
We use django-ratelimit to limit per IP login attempts, and then we use
django-ratelimit-backend to limit per username login attempts. This
change replaces the usage of django-ratelimit-backend with another
instance of django-ratelimit so that both limits can be managed by one
library.
This is the first step in being able to fully excise
django-ratelimit-backend from edx-platform. Note that we're still using
the `RateLimitMixin` in openedx/core/djangoapps/oauth_dispatch/dot_overrides/backends.py
because studio and the admin UI still relies on that for rate limiting.
Those login paths will have to be updated before we can remove the mixin
from our auth backend.
Mobile apps load HTML (and other) XBlocks individually using the
render_xblock endpoint. This is an attmept to reduce the number
of requests and JS processing needed to do so by detecting when
we have math content in HTMLBlocks and only adding the Mathjax
resources when necessary.
This is controlled by the "courseware.optimized_render_xblock"
CourseWaffleFlag. For maximum safety, we currently only optimize
in this way when directly hitting HTMLBlocks, and not for
ProblemBlock or VerticalBlock.
This was made as part of edX's Hackathon XXV.
The rate limiting library computes the rate limit by chunking time since
the epoch into chunks of whatever your period is. It then adds some
consistent offset based on your key. This means that at certain times,
you are closer to the end of your rate limit time period than others.
So moving 1 minute into the future would put you into the next time
chunk and your rate limit would be reset.
I updated the test to test rate limit at the same time as the initial
call to ensure that we don't end up on the other side of a time chunk
boundary by accident. We were seeing times in CI where it
would occasionally fail because time chunking wasn't in our favor.
