* feat: post handler to sync provider_data
this allows us to read provider_data metadata from a remote metadata url. reuses code from the task that currently processes all proiderconfigs in a batch
ENT-5482
* feat: lint fixes
* test: add test for sync_provider_data
* test: add case for update
* fix: lint fix
* fix: lint fix
* feat: use exc_info to report error better
* feat: update log message
This commit avoids raising AuthEntryError when auth_entry is None.
At some point of the authentication flow, when the auth_entry is
missing from the auth URL (eg. auth/login/tpa-saml/?idp=idp), the
request session stores auth_entry: None causing this edited line to fail
which stops the login from completing.
* feat: choose signing cert explicitly in saml metadata
when parsing, we want to explicitly choose the use='signing' cert instead of accidentally choosing the encryption one
ENT-677
* test: test for parse_metadata_xml
* feat: also address case when signing key is absent
in this case we consider the 'use'-less keydescriptior as if it's for both signing and encryption
* test: test case for missing use=signing attribute
* test: fix test failure
rest-condition has not been updated for a while, and with DRF 3.9 it is no longer needed since the ability to combine Permission classes using boolean operators is now provided by DRF directly.
We squashed migrations in this djangoapp a while back.
This is the followup work to remove the migrations that were
squashed and to convert the squashed migration into a 'normal'
migration.
https://openedx.atlassian.net/browse/ARCHBOM-1177
Modify the existing login api in a way that
it will allow the user to login via username as well.
currently it is only allowing email to log the user in.
VAN-445
Modify the existing login api in a way that
it will allow the user to login via username as well.
currently it is only allowing email to log the user in.
VAN-445
This change associates users signing in using oauth providers when tpa is required, verifying that only a single database user is associated with the email.
For more information as to why this was added in a separate pipeline, check edx-platform#25935.
Since we are handling the MFE redirection in login_and_registration_form()
we don't need to handle it here. It's redirecting the enterprise users to
MFE instead of FE which is currently handled in login_and_registration_form()
view.
VAN-425
