Fixing tests which were failing on running alone.
Main root cause was the mongodb client connection error.
On running all tests this mongodb connection establishes by some other test.
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
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.
Instead of optionally not logging usernames and emails, do so by
default. This mostly removes some complexity from the app and is makes
it so that it's more secure by default.
I considered the question of allowing people to log usernames and
e-mails if they wanted to but opted not to for a couple of reasons:
* It would involve adding a new feature flag that would be the opposite
of the SQUELCH_PII_IN_LOGS which would be a bit confusing. When do you
use which one? or do you need both? etc.
* There is still a way to correlate the messages to eachother and in
most cases also to a specific user(email being the exception).
