Previously they also had to have a valid JWT cookie which led to a weird
corner case where a user was logged in but still showed the login form
resulting in some confusion and odd behavior.
This change gives precedence to the session token to determine whether
or not someone is logged into the LMS but ensures that if you go through
the login flow, you refresh your JWT cookies. This should not cause any
breakage for MFE flows that might redirect to the LMS login page since
the JWT would get refreshed if it's out of date but the session is
valid.
A variety of updates were made to improve the toggle documentation:
* Added comments to help ensure that the waffle(), waffle_switches(),
waffle_flags() anti-pattern won't be contagious (copied).
* Some minor toggle_description updates.
* Removed empty toggle_target_removal_date annotations for
non-temporary toggles.
* Removed empty optional toggle_warnings annotations.
* Removed empty optional toggle_tickets annotations.
* Removed deprecated toggle_category, toggle_status,
and toggle_expiration_date annotations.
* Fixed some indents, use cases, and implementations.
ARCHBOM-1721
For some SAML providers, learners are redirected to MFE and breaking
the flow. Check for running pipeline and if the provider is a SAML
provider keep them on FE.
VAN-425
If edxloggedin cookie is not present but the user is authenticated;
user is redirected to authn MFE and then back to dashboard instead
of the desired redirect URL (e.g. finish_auth) resulting in learners
not enrolling into the courses.
VAN-415
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.
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.
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).
See context here: https://django-ratelimit.readthedocs.io/en/latest/cookbook/429.html#context
For now we continue to fall back to django's default 403 handler for 403
but provide a new 429 template that we use for ratelimit exceptions.
This commit also updates a logistration test that relied on the old 403
behavior of django-ratelimit instead of the newly added 429 behavior.
This adds a toggle to allow operators to prevent user registration and login via username/password authentication, forcing the platform to only support login and registration using third-party auth such as SAML.
Co-authored-by: Umar Asghar <mrumarasghar@gmail.com>
