verified flag on user - and 403 on api

stdr

Hi there,

I'm aware that gated email-verification is a paid feature.

Nevertheless, you state the api shall be fully functional without a license key.

The way gating is behaving is confusing to me:

if tenant is set to "not verify", new users get a verified=true entry. This plain wrong imo - the email has not been verified, as another system shall take this task.
If tenant is on verify, initial verify is false (correct), but I did not find a way to suppress the emails - is there one?
the verified=true can not be patched to false, neither to true, neither set in the backend to any value.
using the two step flow - in theory - could help to set at least true - But:
calling PUT /api/user/verify-email endpoint ends in a 403 answer on free edition (but works correctly on our pro edition...) Is that intended?
The SkipVerification flag has no effect on patch / put, it seems.

So, how could an external system handle verification, but keep fa as the master for the flag?

Thanks!

joshua

@stdr

Thanks for the recommendations. Please feel free to log a feature request if you feel there should be changes to future versions of FusionAuth

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

I would recommend reviewing the two guides that we have for this topic for additional context and understanding

If tenant is on verify, initial verify is false (correct), but I did not find a way to suppress the emails - is there one?

Can you elaborate on this? Typically, if you would like the user to verify, then they would need to receive an email to prove that they were the owner of this email inbox. There is an option to add skipVerification to the user when they are created

https://fusionauth.io/docs/v1/tech/apis/users/#request-body

skipVerification [Boolean] OPTIONAL Defaults to false
Indicates to FusionAuth that it should skip email verification even if it is enabled. This is useful for creating admin or internal User accounts.

the verified=true can not be patched to false, neither to true, neither set in the backend to any value.

Yes, this is accurate. There is a feature request open to add this functionality.

using the two step flow - in theory - could help to set at least true - But:
calling PUT /api/user/verify-email endpoint ends in a 403 answer on free edition (but works correctly on our pro edition...) Is that intended?

Can you confirm this is the endpoint you are accessing?

https://fusionauth.io/docs/v1/tech/apis/users/#request-12.

Can you show us the endpoint and the command you are executing (a curl statement would be great)?

I was able to hit this endpoint and verify a user on the community edition

curl --request POST \
  --url https://local.fusionauth.io/api/user/verify-email/-iKYnahLUQtrkji3b1aObXQyqpukVsCHZbcMaANsa-U \
  --header 'Authorization: bf69486b-4733-4470-a592-f1bfce7af580' \
  --header 'X-FusionAuth-TenantId: 30663132-6464-6665-3032-326466613934' \
  --cookie 'fusionauth.locale=en_US; fusionauth.sso=ApwcxEfyfhymWTP0R0XKonTzvdz87hzR2UzEUV4XB1sH'

but your workflow may be different.

I hope this helps and let us know.

Thanks
Josh

joshua

I should also add, that skipVerification only works on a POST currently. When you are using this property, typically this is in the context of a user create or a user registration create. However, having a PATCH/PUT work for the verified attribute would likely be a solution in the same vein as those offered under issues 1319 and 285 mentioned previously.

Thanks,
Josh