Broken redirect users to the first Allowed Callback URL

Help
1

The suggestion in the documentation not working anymore. Also a bit confusing that the UI shows double curly braces with spaces, but docs just mention one, which is the valid one?

{{application.callback_domain}} was working perfectly couple of weeks ago.

3

@attila.csnyi I was able to reproduce this issue when sending the email using the “Try” button for the email template. However, when sending the email from Lock the redirect url was updated to use the fist Allowed Callback Url as expected. It appears to work when using both single and double curly braces. Some macros are not available when using the “Try” button as the email template is not associated with a specific client.

4

Dear @matt01 Thanks for your time.

You mean that via lock any syntax is working, but with resending verification email via website can not add the right redirect url as the template not associated with a specific client?

So that’s why I see the following error when I click on the verify link from that email?

{

name: "BadRequestError",
code: "invalid_result_url",
description:"invalid result url: ?email=EMAIL&message=This%20URL%20can%20be%20used%20only%20once&success=false",
statusCode: 400

}

Thanks for the confirmation.

5

@attila.csnyi:

Yes, when the email is initiated by the Lock widget (or Auth0.js) the single or double curly brace syntax appears to work as expected. When you use the “Try” feature for an email template from the Auth0 Dashboard, the email will not have a value for “{{application.callback_domain}}” because the “Try” feature is not associated with a particular client and there is no associated callback domain.

It appears that the “BadRequestError” error you are receiving when clicking the verify link is a result of trying to use the same link multiple times. The verify links are one-time use URLs.

I hope this helps.
Matt

1 Like
6

Thank you @matt01 make sense to me, thanks again for the reason. :sunglasses:

1 Like
7

This is most probably an issue with headers or cookies not being forwarded correctly to the shiny proxy, not an issue with Auth0 but with cloudflare + the shiny proxy (shiny-auth0), why do you need a CDN for a shiny server?

I do not understand the logic on why to do that, each time you run a report you’ll be asking for dynamic data, rendering the CDN useless. Assuming you still need it, i do not know the details of how Cloudflare CDN interacts with the proxy, but i’d try checking the configuration of Cloudflare to see if there’s any pass-through that you can apply to avoid headers/cookies to be lost, i know e.g. Cloudfront from Amazon has this.

If that doesn’t work, you can try modifying the proxy to make it work, it’s possible you need to capture the variables differently when using Cloudflare CDN, but i don’t know that really.
https://downloadwhatsapp.ooo/https://messenger.red/ https://hotstar.onl/

1 Like