Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

data.email not used for "forgot password" workflow anymore #1204

Closed
mcs opened this issue May 7, 2021 · 5 comments
Closed

data.email not used for "forgot password" workflow anymore #1204

mcs opened this issue May 7, 2021 · 5 comments
Assignees
Labels
architecture Feedback on designed behavior
Milestone

Comments

@mcs
Copy link

mcs commented May 7, 2021

data.email not used for "forgot password" workflow anymore

Description

Until v1.25.0 the "forgot password" workflow used the custom data.email from the DB table "users" if there was no identity email set. This is described as an expected feature:
https://fusionauth.io/docs/v1/tech/apis/users/#start-forgot-password-workflow
Beginning with v1.26.0 this doesn't work anymore and results in an HTTP error when using the FusionAuth Java client library:

status=422: Field errors: {}, General errors: [], Exception: -

Affects versions

1.26.0
1.26.1
1.27.0

Steps to reproduce

Steps to reproduce the behavior:

  1. Create a user without an identity email address, but with an custom data.email
  2. Switch to "Customizations -> Email Templates"
  3. Click on "send test mail" at the "forgot password" template.
  4. Start typing the username you created before. It will show up a completion where you can see the user's name.
  5. Click "Send" multiple times. The first time it prints an error message, the second time it additionally prints "EMail sent".
  6. Verify that no email was sent / received to the data.email address.

Expected behavior

The email is sent to the user's email address from his custom data section. In the following example to marcus.krassmann@somewhere.else.localhost:

{
  "active" : true,
  "connectorId" : "...",
  "data" : {
    "email" : "marcus.krassmann@somewhere.else.localhost",
  },
  "encryptionScheme" : "bcrypt",
  "firstName" : "Marcus",
  "fullName" : "Marcus Kraßmann",
  "id" : "...",
  "insertInstant" : 1585660375464,
  "lastLoginInstant" : 1620139551413,
  "lastName" : "Kraßmann",
  "lastUpdateInstant" : 0,
  "memberships" : [ {
    "groupId" : "...",
    "id" : "...",
    "insertInstant" : 1594987680309
  } ],
  "passwordChangeRequired" : false,
  "passwordLastUpdateInstant" : 1585660375464,
  "registrations" : [ {
    "applicationId" : "...",
    "id" : "...",
    "insertInstant" : 1585660375464,
    "lastLoginInstant" : 1620139551413,
    "lastUpdateInstant" : 0,
    "roles" : [ ... ],
    "username" : "...",
    "usernameStatus" : "ACTIVE",
    "verified" : true
  } ],
  "tenantId" : "...",
  "timezone" : "UTC",
  "twoFactor" : { },
  "username" : "...",
  "usernameStatus" : "ACTIVE",
  "verified" : true
}

Platform

  • Docker-Image: fusionauth/fusionauth-app:1.26.0 (and following)
@robotdan
Copy link
Member

robotdan commented May 7, 2021

This was removed due to some security concerns.

Are you able to use the user.email value for the email address instead? If not, can you describe your use case and this may help us identify a good way forward.

@mcs
Copy link
Author

mcs commented May 8, 2021

We use the data.email field because the email addresses are not always unique between different users. Some of our users have trust accounts for other clients, so there's more than one user per email address.

@mcs
Copy link
Author

mcs commented May 10, 2021

There is another follow-up problem:
If we try implementing the email sending logic in our own application, we still cannot use "Start the forgot password workflow using an API key" because we get HTTP response code 422 if no email is set. This is also true if the request body contains the property "sendForgotPasswordEmail": false.

@robotdan robotdan self-assigned this May 10, 2021
@robotdan robotdan added the architecture Feedback on designed behavior label May 10, 2021
@robotdan
Copy link
Member

Thanks for the feedback and use case details @mcs.

We are doing some additional internal review of this issue, and if we reverse this decision it will be out in the next patch or release. Thanks for your patience!

@robotdan robotdan added this to the 1.27.2 milestone May 10, 2021
@robotdan
Copy link
Member

Behavior reverted to pre 1.26.0 in 1.27.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Feedback on designed behavior
Projects
None yet
Development

No branches or pull requests

2 participants