What happened?
Description
We have a site with public registration that includes our own forms for the entire registration and login flow, including password resets. We have a bunch of frontend routes for this:
/register/login/reset-password/set-password
We set the corresponding general config settings (setPasswordRequestPath, setPasswordRequestPath, etc).
The problem is that even if a user triggers a password reset from our frontend form (/reset-password), they will get a link not to the frontend form /set-password, but to the corresponding Control Panel form (/admin/set-password). I think this is because those users have Control Panel access. But we still want to use our frontend forms for those users (because they are styled like the rest of the site, and have some additional instructions on them).
I think the issue is that Craft always uses the Control Panel forms as long as the users have access to the Control Panel, even if the request was triggered from a site request, not a CP request. Makes sense for some use-cases, but in our case it doesn't.
I know our custom forms worked back in Craft 3 when they were built, not sure when this behaviour changed. The issue exists both in the latest Craft 4 and 5 releases.
We need a way to ensure that the entire password reset flow will happen through our frontend forms, even for users with CP access. In particular
- If a user requests a password reset from our frontend form (
/reset-password), Craft should send the set-password link to our frontend form (/set-password), not the Control Panel form
- After the user sets a new password, they should be redirected to the frontend login form (
/login), not to the Control Panel login form
Maybe the controller endpoints (users/send-password-reset-email and users/set-password) could accept an optional parameter that tells them to prefer site forms over Control Panel forms, with a fallback to the existing behaviour?
Craft CMS version
5.5.6
PHP version
8.3
Operating system and version
No response
Database type and version
No response
Image driver and version
No response
Installed plugins and versions
What happened?
Description
We have a site with public registration that includes our own forms for the entire registration and login flow, including password resets. We have a bunch of frontend routes for this:
/register/login/reset-password/set-passwordWe set the corresponding general config settings (
setPasswordRequestPath,setPasswordRequestPath, etc).The problem is that even if a user triggers a password reset from our frontend form (
/reset-password), they will get a link not to the frontend form/set-password, but to the corresponding Control Panel form (/admin/set-password). I think this is because those users have Control Panel access. But we still want to use our frontend forms for those users (because they are styled like the rest of the site, and have some additional instructions on them).I think the issue is that Craft always uses the Control Panel forms as long as the users have access to the Control Panel, even if the request was triggered from a site request, not a CP request. Makes sense for some use-cases, but in our case it doesn't.
I know our custom forms worked back in Craft 3 when they were built, not sure when this behaviour changed. The issue exists both in the latest Craft 4 and 5 releases.
We need a way to ensure that the entire password reset flow will happen through our frontend forms, even for users with CP access. In particular
/reset-password), Craft should send the set-password link to our frontend form (/set-password), not the Control Panel form/login), not to the Control Panel login formMaybe the controller endpoints (
users/send-password-reset-emailandusers/set-password) could accept an optional parameter that tells them to prefer site forms over Control Panel forms, with a fallback to the existing behaviour?Craft CMS version
5.5.6
PHP version
8.3
Operating system and version
No response
Database type and version
No response
Image driver and version
No response
Installed plugins and versions