Tenant configuration for blocked domains should still allow self-service edit as long as email is not changing
Description
Blocked domains are intended to prevent self-service registration or self-service account edit from using protected domains.
For example, you may wish to provision all of your employees, and not allow an end user to create a new user, or change an email on their existing user to your corporate domain.
This all works as expected.
However, when using self-service edit, as long as my email is not changing, I should be able to change my password, or change my name, etc. (anything that is allowed of me via the configured form) when using a protected email domain (configured via blocked domains)
But it seems that we may be blocking the edit path all together when using a blocked domain unless disableDomainBlock: true is passed in on the API.
Observed versions
1.51.2
Affects versions
TBD
Steps to reproduce
Create a user with an email of user1@example.com
Add example.com to the blocked domain configuration for the tenant
Try to change your password or name in the self-service account form.
Expected behavior
It seems we should allow a user to change their email to something that isn't blocked, and change anything else about their user.
Assuming the validation really only needs to return a validation error for [blocked]user.email if the user is creating this user, or changing their email to a value in the blocked list. If the user is not changing their email address, we should not return a validation error I don't believe.
Needs more investigation, but on the surface seems like are doing this incorrectly.
Screenshots
If applicable, add screenshots to help explain your problem. Delete this section if it is not applicable.
Tenant configuration for blocked domains should still allow self-service edit as long as email is not changing
Description
Blocked domains are intended to prevent self-service registration or self-service account edit from using protected domains.
For example, you may wish to provision all of your employees, and not allow an end user to create a new user, or change an email on their existing user to your corporate domain.
This all works as expected.
However, when using self-service edit, as long as my email is not changing, I should be able to change my password, or change my name, etc. (anything that is allowed of me via the configured form) when using a protected email domain (configured via blocked domains)
But it seems that we may be blocking the edit path all together when using a blocked domain unless
disableDomainBlock: trueis passed in on the API.Observed versions
1.51.2Affects versions
TBD
Steps to reproduce
user1@example.comexample.comto the blocked domain configuration for the tenantExpected behavior
It seems we should allow a user to change their email to something that isn't blocked, and change anything else about their user.
Assuming the validation really only needs to return a validation error for
[blocked]user.emailif the user is creating this user, or changing their email to a value in the blocked list. If the user is not changing their email address, we should not return a validation error I don't believe.Needs more investigation, but on the surface seems like are doing this incorrectly.
Screenshots
If applicable, add screenshots to help explain your problem. Delete this section if it is not applicable.
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
Additional context
Add any other context about the problem here.