This issue may occur if the Forgot Password email template is still enabled in FusionAuth. To resolve this:

Disable the Forgot Password email template at the tenant level:
Navigate to Tenant > Edit Tenant > Email tab > Template Settings.
Set the Forgot Password template to Feature Disabled.

Check the application-specific settings:
If you have an application-specific template set up, ensure the Forgot Password template is also disabled under the Application settings.

Verify API configuration in the PHP client (if applicable):
If you’re using the PHP client, ensure sendForgotPasswordEmail is explicitly set to "false" (as a string with quotes), not just false (boolean). This ensures the value is passed correctly.
These steps should prevent FusionAuth from sending its own Forgot Password email when the API is called, resolving the double-email issue.

@zaalbarxx sorry for the delay. I might be missing it (sorry not a PHP person) but I don't see where that confusion comes into play. I know that some of our docs had to get updated because of a change that we made during our 1.50 release that required to request further details in our scopes request.

This release makes significant changes to the default behavior of new Applications with regard to scopes in OAuth workflows. The database migration will update existing Applications to behave in a backwards compatible manner. See the OAuth Scopes documentation for more information, in particular the Relationship, Unknown scope policy, and Scope handling policy configurations.

https://fusionauth.io/docs/release-notes/#version-1-50-0

Let me know if that still isn't making sense, or if there is a spot you were hung up on and I would be happy to update our docs. Or even better feel free to add a PR.

@apeksha-barhanpur

My apologies, I mistakenly believed you had a support plan with FusionAuth (let me know if I am mistaken).

Regarding your question --

Have you had a chance to review the troubleshooting guide that we publish for email?
https://fusionauth.io/docs/v1/tech/admin-guide/troubleshooting#troubleshooting-email

Lastly, a good tip is to remove FusionAuth completely from the email equation by using SWAKS. SWAKS will complete an email exchange with just your email provider credentials (thereby removing FusionAuth from the equation). If SWAKS fails, then would offer good troubleshooting information.
http://www.jetmore.org/john/code/swaks/

Thanks,
Josh

A couple of things:

https://fusionauth.io/docs/v1/tech/troubleshooting/#troubleshooting-email has troubleshooting tips worth checking out.

The UI copy doesn't copy the SMTP password, so double check that as well.

You want to look at https://fusionauth.io/docs/v1/tech/lambdas/samlv2-response-populate/ This can update the email/nameId before it is sent over to the special SP.

You will want to create a separate application and set the Response Populate Lambda to the lambda which does this transformation. This can be done via the UI as illustrated here: https://fusionauth.io/docs/v1/tech/samlv2/

Yes. That’s how it currently works.

We have on the roadmap a more flexible identity system but don't have a current timeline for implementation. Here's the tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/1

Ensure you are not using a reply address from @fusionauth.io; if you are this will fail our DMARC policy.

You don’t necessarily want to remove this reply address, but it should not be using our email domain. Instead it should be an address that belongs to your organization, such as no-reply@example.com. (Or, even better: customersupport@example.com--I hate when I get an email I can't reply to, myself.)

Each email template also has the option to override that default value with a different value. So you may also want to audit each email template to ensure if it is using a different From address, it is also owned by your domain.

If you are using email verification, you can check this user state within your own app. (So, don't allow the attacker to access anything until their email address has been verified.)

In version 1.27.0 you can configure a gated login flow when the user is not verified (this is a 'reactor' feature requiring a paid license). This will enforce email verification before we even redirect to your app. You can then also configure FusionAuth to delete users after N number of days if the user has not verified their email address. This can assist with build up of accounts that are not actually in use.

I tried to specify both username and email and I got this error:

{ statusCode: 400, exception: { fieldErrors: { 'user.email': [ { code: '[blank]user.email', message: 'You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email].' } ], 'user.username': [ { code: '[blank]user.username', message: 'You must specify either the [user.email] or [user.username] property. If you are emailing the user you must specify the [user.email].' } ] }, generalErrors: [] } }

So basically I guess my best bet is to manually enforce uniqueness of username in my backend. But it could have been less cumbersome if I could delegate it to FusionAuth.

I guess what I am trying to emphasis here is the fact that just by saving username in user.data we will be able to have both username and email but applying rules such as uniqueness would require more manual labor. Cannot we just tell FusionAuth to make sure that user.data.username should be unique in that app or tenant?

Side note: Since my question is deviating from the OP I'll create a new post and reference this one.

I end up using a docker image of mailcatcher.

I use the default docker-compose.yml, but use this docker-compose.override.yml:

version: '3' services: mailcatcher: image: yappabe/mailcatcher ports: - "1025:1025" - "1080:1080" networks: - mailcatcher search: image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1 environment: cluster.name: fusionauth bootstrap.memory_lock: "true" discovery.type: single-node FUSIONAUTH_SEARCH_MEMORY: ${FUSIONAUTH_SEARCH_MEMORY} ES_JAVA_OPTS: ${ES_JAVA_OPTS} # Un-comment to access the search service directly # ports: # - 9200:9200 # - 9300:9300 networks: - search restart: unless-stopped ulimits: memlock: soft: -1 hard: -1 volumes: - es_data:/usr/share/elasticsearch/data fusionauth: depends_on: - search - mailcatcher environment: SEARCH_SERVERS: http://search:9200 SEARCH_TYPE: elasticsearch networks: - mailcatcher - search networks: search: driver: bridge mailcatcher: driver: bridge volumes: es_data:

Then I configure the SMTP settings to use the hostname mailcatcher and the port 1025. I can then send email and view it in the mailcatcher interface, at localhost:1080.

Here's the relevant dockerfile: https://github.com/yappabe/docker-mailcatcher/blob/master/Dockerfile

Here's more about mailcatcher: https://mailcatcher.me/

A couple of options:

You could optionally configure a different template for each tenant so you could hard code the correct URL in each template.

You could also add the correct URL to the tenant.data and then pull it out in the template during render so you could use the same template across tenants.

If the state parameter is working well for you for other APIs, you could open a feature request in GH to add this to the API in question.

Does SendGrid indicate why they are rejecting requests? In my experience, this is generally due to invalid creds, or a “From address” with a domain that does not match your SendGrid account.

So if a default template is being used with a no-reply@fusionauth.io address you may see a runtime error such as a rejected SMTP request.

Otherwise I'd make sure the IP address is in any whitelists, or share anything else that sendgrid logs.

Since both APIs are technically the same, is there a way to use the email template defined for the Setup Password with the Forgot Password API?

Yes. Navigate to 'Tenants -> your tenant -> Email' and you can set 'Setup password' and 'Forgot password' to be the same template.

There may be template variable differences, please consult the documentation and ensure you are checking for existence before you rely on them:

https://fusionauth.io/docs/v1/tech/email-templates/email-templates/#setup-password

https://fusionauth.io/docs/v1/tech/email-templates/email-templates/#change-password

Each user is unique within a tenant by email address. If a user in the same tenant wants to login with Facebook, Google, or LinkedIn, it will be the same User object.

You are correct. The verified flag exists on the corresponding user and the registration. You could optionally use the "verify registration" templatefor this purpose.

If you then ignored the verified: false flag on the registration in your code, it should not impact you.

Another option would be to listen for the user.registration.create event and then fire off an email on your end, or call the Email Send API to send a pre-made FusionAuth email template as a welcome event: https://fusionauth.io/docs/v1/tech/apis/emails/#send-an-email

This is unfortunately a known issue. See https://github.com/FusionAuth/fusionauth-issues/issues/629 for some discussion. There are some workarounds in some situations (allow lists in Office 365) but no general workaround.

You could use the skipVerification parameter (set it to true) on the user or registration create statement, and then the https://fusionauth.io/docs/v1/tech/apis/users#resend-verification-email call with sendVerifyEmail set to false.

This would give you a verificationId you could use with this API call: https://fusionauth.io/docs/v1/tech/apis/users#verify-a-users-email

I figured it out…. I just had to put state.client_id in parens so it resolved them together.

[#assign clientId = (state.client_id?string)!"dafb6ef6-a2a8-4d34-9d69-59bfed3e31aa" /]