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.

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

Yes. As of 1.27, you can use a verification strategy of FormField. This is configured on the tenant: https://fusionauth.io/docs/v1/tech/apis/tenants/

You then provide the one time code in the oneTimeCode request body parameter. More about this in the email verification docs: https://fusionauth.io/docs/v1/tech/apis/users/#verify-a-users-email

Note that this feature only works with email gating at the current time, which is a reactor feature requiring a paid license.

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

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

It looks like the issue was our mail server. We are using Mailgun SMTP service for our mail sending and this offers a tracking feature.

This tracking feature adds a invisible image to the html code in order to get request for stats. If I deactivate this feature, the HTML_IMAGE_ONLY_12 error is gone and the mail are no longer marked as SPAM. We don't have any issues with our other applications because sent emails are bigger in text content.

The JWT (id_token or access_token) will contain the email_verified claim with a value of true or false, so if you wish to limit privilege based upon this state, that would be a good way to do it.