Clicking on an old verification link redirects you to the default return url and not the return url specified with the initial verification flow

[MilesNorton]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

I signed up with a new account using the following queries: return_to and after_verification_return_to, which are both different to the default_return_to url. Once I receive the email to verify my account and clicked on the link, I get redirected to the after_verification_return_to url which is expected.
Now, when I go back to my email and click on the verification email again it redirects me to the default_return_to url.

Please note I have also tested this from the normal verification service flow and it also produces the same bug which means it isn't specific to the after_verification_return_to url.

Reproducing the bug

1. Set up second domain that will be used for return to url's
2. Navigate to the registration page and make sure the second domain is set as the return_to and after_verification_return_to query params.
3. Sign up
4. Click on verification email link
5. Click on verification email link again

Relevant log output

No response

Relevant configuration

serve:
  public:
    base_url: http://localhost:4433/
  admin:
    base_url: http://localhost:4434/

selfservice:
  default_browser_return_url: http://localhost:8100
  whitelisted_return_urls:
    - http://localhost:8101/
  flows:
    registration:
      ui_url: http://localhost:8100/registration
      lifespan: 1h
      before: {}
      after:
        default_browser_return_url: http://localhost:8100
        password:
          hooks:
            - hook: session
    verification:
      ui_url: http://localhost:8100/verification
      after:
        default_browser_return_url: http://localhost:8100
      lifespan: 1h
      enabled: true

Version

v0.8.2-alpha.1

On which operating system are you observing this issue?

No response

In which environment are you deploying?

No response

Additional Context

No response

[aeneasr]

I get redirected to the after_verification_return_to url which is expected.
Now, when I go back to my email and click on the verification email again it redirects me to the default_return_to url.

This is kind-of expected. The after_verification_return_to is only triggered on success. It would probably show a screen like "thank you for verifying your address, here are the next steps ..." in your UI. If the link is expired or invalid, it would be strange to show that screen so we instead show the default URL. Or is the problem you describe that the verification link was actually valid and verified, and the second open of the link should end up in the same screen?

[MilesNorton]

@aeneasr yeah for my situation, we use the return url to brand the ui. If we don't have it, it would brand to a different ui which would confuse the user. My thoughts are that it should still redirect to the return url originally used with the verification flow or registration flow. I believe the second open (after they are verified) should use the return url and from there we can still determine if they are verified or not and decided to show them thanks for verifying or just redirect them to the login screen if they don't have a valid cookie.

[MilesNorton]

@aeneasr I've also noticed his issue with click on an old recovery link

[DanielHons]

When 2fa is enabled it seems the return_to is also going lost when Kratos asks for the second factor. I have two different installations with latest Kratos and hydra, both behave like this:
2fa disabled -> I get returned to the expected url, regardless whether I need to sign in or use an active session
2fa enabled -> when using a present session, redirection works. But if I need to sign in, I loose the return_to url when I enter the second factor.

Might be related to this issue (but I didn't dig into it)