Form Field verification strategy still sends a link for verification

[AliMirlou]

Form Field verification strategy still sends a link for verification

Hi,
I chose the Form Field verification strategy in tenant settings and also checked the email template to make sure it's correct but the email is still sent with a link, not a one-time code.
What could be the problem here?

I'm currently using FusionAuth 1.32.1, deployed by the helm chart. I have also checked the release notes of later versions but there were no mentions to this.

[mooreds]

From https://fusionauth.io/docs/v1/tech/core-concepts/tenants#email

The process by which the user will verify their email address. Using the "Form Field" method works only when the Unverified behavior is Gated.

However, one thing to note is that Form verification is only allowed for plans with a paid edition. You will receive a message in the UI, but it is also documented in the API docs: https://fusionauth.io/docs/v1/tech/apis/tenants

Gated - verification is required before a user can complete login. The use of this value will require a paid edition of FusionAuth.

I am going to close this out because I think this is not a bug. If you try this with:

• Verification strategy set to Gated and
• have a valid license key (Starter edition should work fine)

and it still fails to work, please re-open.

[AliMirlou]

@mooreds Well it does seem like a bug since I can enable this feature and it doesn't give me an error regarding my free plan or the gated unverified behavior being disabled. It just accepts the new settings but just doesn't work.

Also this means that the Form Field verification strategy is also a paid feature, am I not right? Isn't it better to show a message for that as well? Because it's really confusing to have a free feature which can not be used until a specific paid feature is enabled!

[AliMirlou]

@mooreds Also I don't seem to have the ability to re-open my issue. Can you not close the issue before it's confirmed by the author or at least before some time has passed without a reply? Because now that you have closed it, no one would notice my later replies.

[mooreds]

Hiya @AliMirlou , sorry, I thought we had things set up so you could re-open. I just did so. That's good feedback to wait.

Form Field verification strategy is also a paid feature

Yes, that is correct.

Well it does seem like a bug since I can enable this feature and it doesn't give me an error regarding my free plan or the gated unverified behavior being disabled.

It does look like if you select 'Gated' there is an error message displayed unless you have a license.

[AliMirlou]

@mooreds Exactly. The "Unverified Behavior" shows a proper error but the "Verification Strategy" doesn't. Wouldn't it be better if it also showed an error instead of accepting the setting but ignoring it?

[mooreds]

@AliMirlou great point! I'll file a bug stating that we should have two new error messages:

• if verification strategy is form field and unverified behavior is not Gated, inform the user that this combo won't work
• if verification strategy is form field and the user is using community edition, inform the user a license is required

Does that make sense to you? Once that issue is filed, would you be okay with me closing out this issue?

[AliMirlou]

@mooreds Yeah, that makes it clear. Also maybe update the documentation of "Verification Strategy" to make it clear that it's actually a paid feature?

[robotdan]

Not sure I understand the issue here, can you expand upon this? The error message looks correct to me. All of this looks to be working as designed. Regardless of the strategy you select, we have to send an email because that is how we perform email verification. Email templates are customizable by the user of FusionAuth.

Why can't you use a verification strategy of field and a not gated config when not licensed? What happens if you configure it this way?

[AliMirlou]

@robotdan The "Form Field" verification strategy will be strangely ignored and the email will still be sent with a clickable link!
I even checked the email template variables and realized that the verificationOneTimeCode variable in "Email Verification" and "Registration Verification" templates is always null, no matter the configuration.

[mooreds]

Why can't you use a verification strategy of field and a not gated config when not licensed? What happens if you configure it this way?

From the docs

"The process by which the user will verify their email address. Using the "Form Field" method works only when the Unverified behavior is Gated."

[robotdan]

@robotdan The "Form Field" verification strategy will be strangely ignored and the email will still be sent with a clickable link!

If we send a link or a code is determined by the themed email template. I could make a short code clickable, or a long code clickable.

"The process by which the user will verify their email address. Using the "Form Field" method works only when the Unverified behavior is Gated."

This makes sense - have we tested it to ensure this we are actually ignoring the strategy type based upon the gated config value? If so, then it sounds correct that we could change the validation behavior based upon the license type.

[AliMirlou]

@robotdan I sent a screenshot of the email template at the beginning of the issue and there, it's clear that if the variable which holds the short code is available, then it would be printed in the email instead if the clickable link. But the variable is always null.

[robotdan]

It looks like the issue -wether intentional or not, is that an assumption was made that form field was only usable when gating was enabled. While this is correct in some sense - it does not allow for someone to build their own form to collect the short code and complete verification.

So it looks like the correct behavior will be to not assume - and if Form Field is configured, w/out gating - generate the short code (OTP) and assume that the integrator will build this form out of band and call the Verify Email or Verify Registration API directly.

[robotdan]

Handling via #2681.