Open mvarblow opened 5 months ago
This looks indeed like something should be handled better. Although enabling external login, not having users pre-created, and not enabling registration together is also an incorrect configuration. Or did you do it deliberately?
This looks indeed like something should be handled better. Although enabling external login, not having users pre-created, and not enabling registration together is also an incorrect configuration. Or did you do it deliberately?
In this case, we are expecting that users will be pre-created. An administrator needs to provision the user manually to ensure their account is set up correctly in the OrchardCore site. But there will occasionally be cases where a user tries to sign in before their OrchardCore account has been provisioned. In this case, we'd expect an error. What the user gets instead is a page that seems to the user to be loading "forever". Of course it's actually in a redirect loop.
I see, thanks.
We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).
This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.
Describe the bug
If you enable an external identity provider such as Microsoft Entra ID and the configure the user settings to disable local sign-in and user registration, then users who have not been provisioned will not receive the "Site does not allow user registration" error as expected. Instead, they end up in an infinite redirect loop.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
If you look in the Orchard Core log file you'll see a warning: "Site does not allow user registration." This warning will be repeated many times, depending on how long the user allowed the redirect loop to continue as they waited for the page to appear. I would expect that the user should receive an error message similar to what was logged instead of being continuously redirected. If I locate the code in AccountController which is responsible for generating that log entry, it appears that this is what the author of the code also intended. Though I think they didn't consider this scenario where the "use external provider for login" option was enabled.
If "use external provider for login" were disabled, then the redirect wouldn't happen. Instead, the user would see the sign-in page with the error message. To fix this, it seems that the AccountController needs to account for this possibility and replace the RedirectToLogin response with a view which can display the error message.