Client-side redirect to /continue results in 401

Help
1

Hey there,

This is my first official post in the community forums. Love your product, you are doing an awesome job!

I am on my 3rd day of debugging a problem I am having with redirect from a rule and I am asking you knowledgeable folk for help:

I have a pretty barebones POC tenant set up with a rule to redirect users to a custom sign-up flow. When this flow is done, I am redirecting users to /continue via client-side redirect, including the original state passed by the rule - window.location = 'https://${tenant}/continue?state=${state}'.

If the user has not verified his/her email, this call returns a 302 status, I can see output from the rule webtask being called with ā€˜redirect-callbackā€™, all is well.

If the user has verified their email before the /continue call then this returns a hard 401, no output from rule webtask no entry in Logs in the dashboard.

I have a similar setup on a production tenant and it seems to work fine, so Iā€™m guessing itā€™s some tenant misconfiguration. Any ideas what I might be doing wrong here?

All users are username/password for these flows.

Thanks again for any help!
Gabriel

2

Hi Gabriel,
Iā€™m having the exactely the same problem? Did you manage to solve it?
Regards,
Helena

3

Hey!

I tracked the problem to using the management api for verifying emails. Apparently PATCHing users via the api with { ā€œemail_verifiedā€: true } or using the management dashboard to force verify a userā€™s email will somehow invalidate the rule ā€œsessionā€ resulting in a hard 401.

Getting a verification ticket via POST /api/v2/tickets/email-verification and immediately following the ticket url in the response seems to avoid the problem. This seems to be the same mechanism that is used for the standard verification email.

Please let me know if this works for you too if you end up using the approach.

Thanks,
Gabriel

3 Likes
4

Thanks Gabriel for sharing that!