Redirect To for classic login doesn't work

[dan.woda]

The HAR isn’t revealing anything. I took a look at your logs and it looks like the result url is still null on those requests. I am thinking that must be the issue.

I am going to try and escalate this to a senior support engineer and see if they have more advice.

[joralf]

Hi @dan.woda

Thanks so much! Just for reproduction steps:

• Create a new tenant
• Connect Vue.js client
• Setup callback url
• Add Sendgrid API key
• Create user from auth0 interface (so user doesn’t create itself)
• Ask for password reset after user validated it’s email

[nicolas_sabena]

Hi @joralf

This is a really long thread, so apologies in advance if I missed anything.

To answer your questions:

{{ application.callback_domain }} is not replaced, but when I hardcode the URL it is working for verification mails

It will be replaced only for the Redirect To field (not the Subject field). It will only have a value if the application that requested the password reset has at least one callback URL. You can use Liquid syntax to provide a default value if needed. E.g.:

{{application.callback_domain | default: "https://default-domain.com"}}/after_password_change

Note that while the variable is called “callback_domain”, it should really be “callback_origin”, as it will include the protocol (e.g. https://).

Redirect is not triggered after password reset, is this a feature or a bug?

It should trigger a redirect as long as the Redirect To field contains a value.
I went over the information you sent to Dan, and the .HAR file suggests that at least when that test was conducted there was no Redirect To setting for the password change template. The tenant also shows that the template currently doesn’t have a Redirect To value.

Can you try setting the Redirect To value for the template one more time and try again? If it is still not working let me know and I’ll try the flow from my side.

[joralf]

Hi @nicolas_sabena,

I found the cause of the redirect not triggering for password change, it’s a UI issue. Here’s the reproduction steps:

• Create a new tenant
• Connect Single Page App
• Add Redirect Url to verification email
  
  
• Select change password from dropdown
• The Redirect Url is filled in and you can’t press the save button (it’s disabled). This let me to believe that this Redirect Url was already persisted for change password OR it was set globally and can’t be different per type of action.
• If you change the prefilled Redirect Url to something else you can save it. I then changed it back to the value it should be and now it works
• This goes for all the other options as well, here’s a screenshot how it looks after you filled in Redirect Url for verification email (notice disabled save button AND Redirect Url filled in)

I’ll try the liquid syntax now and let you know if it worked…

[nicolas_sabena]

Hi @joralf. Thanks for the explanation of the UI issue. I’ll pass the feedback along to the team to improve the experience.

As for the verification email and redirection: did you try the flow? After verifying your email, what happened?

[joralf]

Hi @nicolas_sabena,

Yes I tried the email verification flow with the settings above. As you can see from the log {{ application.callback_domain }} is not replaced with the first item in the list of Allowed Callback URLs, instead it throws a bad request error with the following JSON being rendered in my browser. It does verify the email though, so when you navigate manually to the application you can fill in your credentials and you’re good to go.

{
name: "BadRequestError",
code: "invalid_result_url",
description: "invalid result url: ?supportSignUp=true&supportForgotPassword=true&email=mymail%40gmail.com&message=Your%20email%20was%20verified.%20You%20can%20continue%20using%20the%20application.&success=true&code=success",
statusCode: 400
}

I thought it maybe had to do with the protocol not being https, but when I add google as first item in the list of Allowed Callback URLs the same happens.

If I do a password change with the same settings and I fill in {{ application.callback_domain }} as RedirectUrl it does work, so it seems to only occur for the email validation flow.

I have setup a test case in my private tenant test-joralf in case you want to check it.

Here’s the log for email validation:

{
  "date": "2019-12-16T09:20:17.610Z",
  "type": "fv",
  "description": "invalid result url: ?supportSignUp=true&supportForgotPassword=true&email=mymail%40gmail.com&message=Your%20email%20was%20verified.%20You%20can%20continue%20using%20the%20application.&success=true&code=success",
  "connection": "Username-Password-Authentication",
  "connection_id": "con_L8ftdJSJu4fZLWRJ",
  "client_id": "KSmw355ymd4pVAPOcObpFQh1UxJKuwIZ",
  "client_name": "All Applications",
  "ip": "89.20.164.66",
  "user_agent": "Chrome 79.0.3945 / Mac OS X 10.14.6",
  "details": {
    "query": {
      "email": "mymail@gmail.com",
      "user_id": "auth0|5df74c47ab63ea0edf6dfaa0",
      "tenant": "test-joralf",
      "client_id": "KSmw355ymd4pVAPOcObpFQh1UxJKuwIZ",
      "connection": "Username-Password-Authentication",
      "resultUrl": "{{ application.callback_domain }}",
      "includeEmailInRedirect": true
    }
  },
  "user_id": "auth0|5df74c47ab63ea0edf6dfaa0",
  "user_name": "mymail@gmail.com",
  "strategy": "auth0",
  "strategy_type": "database",
  "log_id": "90020191216092018758000482016725977466104171282317705250",
  "_id": "90020191216092018758000482016725977466104171282317705250",
  "isMobile": false
}

And here’s the one for password change:

{
  "date": "2019-12-16T09:18:23.147Z",
  "type": "scp",
  "description": "You can now login to the application with the new password.",
  "connection": "Username-Password-Authentication",
  "connection_id": "con_L8ftdJSJu4fZLWRJ",
  "client_id": "oxTBbl2sVSmr1vvq4ho2DxV76CBtFSG0",
  "client_name": "Test app",
  "ip": "89.20.164.66",
  "user_agent": "Chrome 79.0.3945 / Mac OS X 10.14.6",
  "details": {
    "email": "mymail",
    "body": {
      "newPassword": "*****",
      "confirmNewPassword": "*****",
      "_csrf": "yk0znz73-TG8FCt6ttPoE4vInMNFi4R8iaAo",
      "ticket": "O8Mn8QFX36iCyYN6Ens9EqeMVbAgUSq3"
    },
    "query": {
      "user_id": "5dee293d8545dd0ea6e85f9e",
      "email": "mymail",
      "username": null,
      "newPassword": null,
      "tenant": "test-joralf",
      "client_id": "oxTBbl2sVSmr1vvq4ho2DxV76CBtFSG0",
      "connection": "Username-Password-Authentication",
      "resultUrl": "{{ application.callback_domain }}",
      "markEmailAsVerified": true,
      "includeEmailInRedirect": true
    }
  },
  "user_id": "auth0|5dee293d8545dd0ea6e85f9e",
  "user_name": "mymail",
  "strategy": "auth0",
  "strategy_type": "database",
  "log_id": "90020191216091824557000481952025476526148824647197524002",
  "_id": "90020191216091824557000481952025476526148824647197524002",
  "isMobile": false
}

[nicolas_sabena]

Is it possible that you are creating users via the Management API v2? If so, those users won’t have an associated application, meaning that application.callback_domain will be blank. The only way to have an application associated with the signup is when using the public signup endpoint (i.e. when users click on the “sign up” link on Lock when they are asked to log in to an application).
Can you try it by using the public signup endpoint and let me know how it goes?

If you expect to create users using the Management API, you’ll need to provide a fallback URL like this:

{{application.callback_domain | default: "https://default-domain.com"}}/after_password_change