Verification code always fails

[ltguillaume]

Describe the bug
Just updated to v3.2.0 and every verification code sent by mail fails.

To Reproduce
Steps to reproduce the behavior:

1. Fill in verification code received by mail
2. See: "Your verification code is incorrect or has expired"

Expected behavior
Just like the login URL, the verification code should work.

Desktop (please complete the following information):

• OS: Win10
• Browser: latest Chromium, latest Firefox

Additional context
Wondered about whether this had anything to do with timezone differences (Firefox + resist fingerprinting), but Chromium-based browser with the same timezone as the server also presents this issue.

[lukevella]

Can you confirm whether the base URL in your browser matches the base URL in the magic link?

[ltguillaume]

It does, 100%. The magic link does work (which is what I meant with "Just like the login URL, the verification code should work", should have been clearer there, sorry).

[lukevella]

Yes I understood you. Thing is the verification code does work as well as can be seen on app.rallly.co which is the same version you are running. Usually what causes the behavior you are describing is trying to enter the verification code whilst accessing the app through a different URL from the one configured with NEXT_PUBLIC_BASE_URL.

I'm not able to reproduce the behavior you are describing locally. There's also e2e tests in place to make sure this works. So it seems likely it's an issue with your configuration. Are you able to demonstrate the issue with a screen recording showing that the magic link URL and the page you're entering the verification code have the same base URL because it would be a waste of time to chase this otherwise.

[ltguillaume]

Yeah I checked that variable, it's 100% the same.

I'm not going to show my server's URL here, sorry, but I've copied 1) the NEXT_PUBLIC_BASE_URL, 2) the address from the address bar in the browser, 3) the magic link from a mail and 4) a review response link for a test participant from a mail and pasted them into the same text file to check: all 4 start exactly with https://plan.mydomain.tld/

[lukevella]

If you have a trailing / at the end of you NEXT_PUBLIC_BASE_URL you might want to remove that.

The only way I can reproduce the behavior you describe here and in #882 is by accessing the app with a different URL then what is configured in NEXT_PUBLIC_BASE_URL.

[ltguillaume]

Nope nope nope, I don't have a trailing slash in the variable, shoot, shouldn't have added that here.

[ltguillaume]

1. Are you running via docker-compose as well?
2. Maybe using nginx-proxy is contributing to this problem?
3. Would there be any error logging if this occurs? I can check and post it here.

It used to work fine in this configuration, though.

[lukevella]

1. Are you running via docker-compose as well?

Yes.

2. Maybe using nginx-proxy is contributing to this problem?

Most likely - if there is something wrong with your configuration.

3. Would there be any error logging if this occurs? I can check and post it here.

Check the network requests in your browser. I'd expect you to see a CORS error when submitting the verification code.

It used to work fine in this configuration, though.

Under the hood, the authentication has been completely replaced from a bespoke implementation to next-auth. This is to allow us to support more auth methods down the line. Next-auth has some extra security features that prevent CORS attacks that weren't there before.

[ltguillaume]

I just reverted to v3.1.0 (last known working) and then v3.1.1: the verification code works again.

Then back to v3.2.0 and the verification code fails again.

[ltguillaume]

You're right, only for v3.2.0 there's this:

Failed to load resource: net::ERR_CONNECTION_REFUSED
http://localhost:3000/api/auth/callback/[email protected]&token=512862

So it's more likely that v3.2.0 introduced a routing problem.

[lukevella]

Right, that makes sense. That's likely related to #849 then. i.e. the base url value for the link is being taken at build time rather than runtime. Explains why it works locally as well since I am running on localhost. I'll deploy a patch to fix this shortly.

[ltguillaume]

Thanks! 😃

[lukevella]

Can you let me know if 3.2.1 fixes this for you?

[ltguillaume]

Yesss, v3.2.1 is working! Thanks for the quick fix!