localhost URL after booking confirmation

[jkoopmann]

Found a bug? Please fill out the sections below. 👍

Issue Summary

After accepting a booking via the link in the e-mail I am redirected to

https://localhost:3000/booking/IDredacted?error=Booking%20%alread20confirmed

Steps to Reproduce

1. Enable booking confirmation
2. Book a meeting
3. Wait for the booking confirmation mail to you
4. Click accept

NEXTAUTH_URL and NEXT_PUBLIC_WEBAPP_URL are set correctly.

The actual acceptance is processed correctly. The booking already confirmed error comes because our E-Mail Security system while analyzing the e-mail calls the booking link. But the error should not point to localhost

[C9Glax]

Same here, docker sha256:3accd30392045d7440bda55c4e2325a86476ef6109464b4d26cd2b26bfa79a64 latest

NEXTAUTH_URL not set (therefor # Configure NEXTAUTH_URL manually if needed, otherwise it will resolve to {NEXT_PUBLIC_WEBAPP_URL}/api/auth should take effect, but isn't)

[C9Glax]

Looking at the redirection URL it contains an Error-Message:

https://localhost:3000/booking/7t3aPpnVeaAukQALCrDRBC?error=Attempted to call BrokenIntegrationEmail() from the server but BrokenIntegrationEmail is on the client. It's not possible to invoke a client function from the server, it can only be rendered as a Component or passed to props of a Client Component.

[olivierlambert]

Confirm, same issue in here

[naitikraj1000]

Hey I am not getting the error,can u provide the video

[jkoopmann]

In my case the error comes because my e-mail system replaces all URLs and calls the URLs for virus analysis. This means however that when I click the link

1. the meeting is accepted (due to the virus checking) and
2. The meeting is accepted AGAIN with my browser.

And (2) leads to the error and THAT error url is localhost:3000.

Maybe try to reproduce it by clicking the accept link twice.

[username3024]

I am currently trying to get to the root cause, may any of you quickly tell me if you are using a subdomain? I tried some stuff and I only have the issue when using a subdomain so far. But maybe that is a totally unrelated issue adding to this.

[jkoopmann]

Not sure what exactly you are referring to as "subdomain". It is calcom.mydomain.eu (with my domain.eu obviously being different). I have it running behind a HA-Proxy. Which is why it is essential that the links are all rewritten and nothing remains at "localhost:3000".

[username3024]

I found an issue where the orgDomains.ts logic is causing trouble with domain verification, potentially triggering the localhost fallback

// Find which hostname is being currently used const currentHostname = ALLOWED_HOSTNAMES.find((ahn) => { const url = new URL(WEBAPP_URL); const testHostname = ${url.hostname}${url.port ? :${url.port} : ""}; return testHostname.endsWith(.${ahn}); });

Here's what's happening: The code creates a URL object from WEBAPP_URL (which is https://calcom.domain.eu/), then it extracts just the hostname part (calcom.domain.eu). Then it tries to check if this hostname ends with .${ahn} (so .calcom.domain.eu), and this will always fail because calcom.domain.eu doesn't end with .calcom.domain.eu

It might trigger the localhost fallback. Right now I am experimenting with a TLD instead of a subdomain and things seem oddly fine.

[nathanael-h]

Hi @username3024 I use it with a subdomain, like cal.something.com

[juliamrch]

Hi @username3024, observing the same behavior while using a subdomain calendar.domain.com.

Details

• Cal running behind a proxy
• Mail service: Tuta (no email scanning)

Flow

1. Click on Confirm from email
2. Redirects first to the correct domain, then falls back to localhost:3000.
3. When manually replacing the link, the confirmation page appears with the booking confirmed.

So the confirmation action goes through, but the issue arises when redirecting after booking confirmation.

[olivierlambert]

+1, exactly the same issue in here.

[rubymignot]

I have the same issue as well.

[paul-hph]

please fix.

[philipthomasme]

same here, also on a subdomain

[aeonoea]

Same here, this bug just persists release after release. At least at the moment, on the user side no browser errors are shown anymore. Just when confirming from host side, the good old localhost redirect.

[olivierlambert]

Could we have at least some pointers on where to look to try to fix it via a contribution?

[keithwillcode]

@volnei can you please take a look at this one? It seems like a possible misconfiguration but let’s verify and provide better documentation if needed.

[linear[bot]]

CAL-6897

[jkoopmann]

@volnei can you please take a look at this one? It seems like a possible misconfiguration but let’s verify and provide better documentation if needed.

Not sure what could be misconfigured but if that's the case I would be very happy. I am afraid however that there is a missing "replacement" in one specific part of your code and since other users are reporting the exact same issue that might be the real reason....

[volnei]

@volnei can you please take a look at this one? It seems like a possible misconfiguration but let’s verify and provide better documentation if needed.

Not sure what could be misconfigured but if that's the case I would be very happy. I am afraid however that there is a missing "replacement" in one specific part of your code and since other users are reporting the exact same issue that might be the real reason....

I will provide you feedback asap... checking.

[keithwillcode]

As a side note that is hopefully helpful to check in your configuration, if you want to run calcom.domain.eu ALLOWED_HOSTNAMES needs to have “domain.eu” included in it. It’s absolutely supposed to work with a subdomain as long as it’s configured as such.

Let me know if you need more clarification or have doubts.

[jkoopmann]

ALLOWED_HOSTNAMES is set to calcom.domain.eu not domain.eu (real domain names of course) and everything else is working fine. The problem is that the generating link in the HTML mail literally is http://localhost:3000 instead of https://calcom.domain.eu whereas it is ok in all other places and buttons and e-mail links. Just not in this case! See

https://github.com/calcom/cal.com/issues/20358#issuecomment-2806832040

as well please as it might be related.

[keithwillcode]

ALLOWED_HOSTNAMES is set to calcom.domain.eu not domain.eu (real domain names of course) and everything else is working fine. The problem is that the generating link in the HTML mail literally is http://localhost:3000 instead of https://calcom.domain.eu whereas it is ok in all other places and buttons and e-mail links. Just not in this case! See

#20358 (comment)

as well please as it might be related.

Don’t set ALLOWED_HOSTNAMES to include the subdomain. It needs to be the root domain as I mentioned above. This is how we have it configured in our own production.

[keithwillcode]

And of course as long as you have the proper full URLs (including subdomain) set in NEXTAUTH_URL and NEXT_PUBLIC_WEBAPP_URL

[eleith]

i can replicate this bug and it does seem to mostly affect self hosted users with subdomains.

when this bug appeared, there were no changes to my settings, so this does feel like a regression.

i can confirm my settings have the following structure

NEXT_PUBLIC_WEBAPP_URL=https://sub.example.com
NEXTAUTH_URL='https://sub.example.com'
ALLOWED_HOSTNAMES='"example.com"'
RESERVED_SUBDOMAINS='"sub"'

please note, the confirm button link in the email is correct (ex: https://sub.example.com/api/link/?token=abc123&action=accept) but then it forwards to https://localhost:3000). the action is properly recorded, limiting the impact of this bug.

perhaps there was an expectation change in how to set these values?

[keithwillcode]

Appreciate the details @eleith! @volnei is on it

[jkoopmann]

@eleith spot on. Thanks for the information. I changed my config of ALLOWED_HOSTNAMES and find no change in the "wrong" behavior.

[volnei]

@eleith @jkoopmann I'm working on this and actually I am testing this PR to see if everything reported here works as expected. I will keep you all posted here.

Edit: The intention here is to attache every URL based on request ensuring that all links will follow the same URL it was originated.

https://github.com/calcom/cal.com/pull/25794

[aeonoea]

Thanks for working on this! I updated to 6.0.2 and still have the localhost redirect...

[volnei]

@aeonoea can you please share specific details? are you using orgs? are you using custom domain?