You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cannot remove until enterprise flows are implemented in micro-frontend
First Open edX Named Release Without This Functionality
not sure
Rationale
As part of our re-platforming effort, we are replacing Django-server-side rendered frontend implementations in favor of React-based micro-frontend implementations. This ticket covers the login, register, forgot, and reset password pages (aka Logistration).
Removal
We will be removing the older implementation of login, register, forgot, and reset password pages:
As part of our re-platforming effort, we are replacing Django-server-side rendered frontend implementations in favor of React-based micro-frontend implementations. This ticket covers the login, register, forgot, and reset password pages (aka Logistration).
Migration
No response
Additional Info
The enterprise flows are still using this legacy implementation and we cannot remove this until those are migrated to the new micro-frontend.
It may also be worth checking to ensure that existing auth-related events and filters are supported in a robust manner, so that existing extensions relying on those mechanisms don't break.
[inform] This DEPR is in the Draft state. It can't move forward without a DEPR coordinator to help update it to match the updated DEPR template. No action is required, unless anyone wants to move this out of Draft.
We still need to investigate whether the custom fields have been added to thein the intervening time. @michaelwheeler do you know whether the auth MFE meets your needs at this time?
Picking this back up as part of the MFE-vs-legacy inventory (openedx/openedx-platform#38936). I audited the legacy logistration experience against frontend-app-authn to figure out what actually blocks this removal, the enterprise logistration logic is what's left.
The legacy page renders an enterprise-branded logistration experience (branded sidebar, generic-provider suppression, consent-gated SSO registration, branded errors, field handling) that the MFE doesn't. openedx/core/djangoapps/user_authn/views/login_form.py:176-190 deliberately keeps SAML/TPA (including enterprise SSO) users on the legacy page, with a TODO to drop that guard "as soon as the AuthN MFE is fully-featured." Until the MFE renders these flows, that guard - and the legacy page behind it - has to stay.
The backend groundwork for this is already done: enterprise logistration logic was decoupled into openedx-filters pipeline steps so it stays pluggable rather than built into the platform (openedx/openedx-filters#337, openedx/edx-enterprise#2551, openedx/openedx-platform#38105), including an enterpriseBranding payload seam for the authn MFE. The frontend counterpart doesn't exist yet, and because enterprise is meant to be pluggable, the right MFE shape (likely a plugin into authn slots rather than built-in code) is still an open question.
I've opened openedx/frontend-app-authn#1691 to track that MFE work. That's the concrete blocker for dropping the legacy login/registration UI - once it's done and the has_external_provider guard can be removed, this DEPR is unblocked.
@feanil there may be other lesser-used customisation options missing from frontend-app-authn too.
A concrete one that's a bit of a blocker for us is that the authn MFE doesn't support a method to reorder the registration fields. The legacy logistration supports the REGISTRATION_FIELD_ORDER setting.
We also hit some bugs in the authn MFE around its handling of custom extra registration fields added via PROFILE_EXTENSION_FORM and validation.
We'll take a look at that, some of the issues may be doable now but not properly documented or there may be alternative ways of doing them eg. via slots. We need to do further investigation before we're ready to drop the old page. @arbrandes and I will look into it.
Activity
kdmccormick commentedon Nov 21, 2022
Update:
michaelwheeler commentedon Nov 22, 2022
Regarding the first point mentioned by @kdmccormick, I was thinking specifically of the ability to add custom fields to the registration page.
It may also be worth checking to ensure that existing auth-related events and filters are supported in a robust manner, so that existing extensions relying on those mechanisms don't break.
robrap commentedon May 23, 2025
[inform] This DEPR is in the Draft state. It can't move forward without a DEPR coordinator to help update it to match the updated DEPR template. No action is required, unless anyone wants to move this out of Draft.
dianakhuang commentedon Feb 5, 2026
We still need to investigate whether the custom fields have been added to thein the intervening time. @michaelwheeler do you know whether the auth MFE meets your needs at this time?
kdmccormick commentedon Feb 5, 2026
Reference for custom registration fields (the legacy version, I believe): https://docs.openedx.org/en/latest/site_ops/install_configure_run_guide/configuration/customize_registration_page.html
michaelwheeler commentedon Feb 5, 2026
Hey @dianakhuang we are no longer using Open edX.
kdmccormick commentedon Feb 5, 2026
The existence of this PR implies to me that Custom Registration Field have been added to the MFE, but that the documentation is not yet complete:
feanil commentedon Sep 10, 2026
Picking this back up as part of the MFE-vs-legacy inventory (openedx/openedx-platform#38936). I audited the legacy logistration experience against
frontend-app-authnto figure out what actually blocks this removal, the enterprise logistration logic is what's left.The legacy page renders an enterprise-branded logistration experience (branded sidebar, generic-provider suppression, consent-gated SSO registration, branded errors, field handling) that the MFE doesn't.
openedx/core/djangoapps/user_authn/views/login_form.py:176-190deliberately keeps SAML/TPA (including enterprise SSO) users on the legacy page, with aTODOto drop that guard "as soon as the AuthN MFE is fully-featured." Until the MFE renders these flows, that guard - and the legacy page behind it - has to stay.The backend groundwork for this is already done: enterprise logistration logic was decoupled into
openedx-filterspipeline steps so it stays pluggable rather than built into the platform (openedx/openedx-filters#337, openedx/edx-enterprise#2551, openedx/openedx-platform#38105), including anenterpriseBrandingpayload seam for the authn MFE. The frontend counterpart doesn't exist yet, and because enterprise is meant to be pluggable, the right MFE shape (likely a plugin into authn slots rather than built-in code) is still an open question.I've opened openedx/frontend-app-authn#1691 to track that MFE work. That's the concrete blocker for dropping the legacy login/registration UI - once it's done and the
has_external_providerguard can be removed, this DEPR is unblocked.test: pin the legacy logistration tests to ENABLE_AUTHN_MICROFRONTEND…
samuelallan72 commentedon Sep 29, 2026
@feanil there may be other lesser-used customisation options missing from frontend-app-authn too.
A concrete one that's a bit of a blocker for us is that the authn MFE doesn't support a method to reorder the registration fields. The legacy logistration supports the REGISTRATION_FIELD_ORDER setting.
We also hit some bugs in the authn MFE around its handling of custom extra registration fields added via PROFILE_EXTENSION_FORM and validation.
cc @Agrendalath
feanil commentedon Oct 15, 2026
We'll take a look at that, some of the issues may be doable now but not properly documented or there may be alternative ways of doing them eg. via slots. We need to do further investigation before we're ready to drop the old page. @arbrandes and I will look into it.