trigger.dev icon indicating copy to clipboard operation
trigger.dev copied to clipboard

Localhost magic link redirect on Safari (MacOS)

Open shaaridev opened this issue 1 year ago • 12 comments

Provide environment information

System: OS: macOS 14.4.1 CPU: (8) arm64 Apple M2 Memory: 77.13 MB / 16.00 GB Shell: 5.9 - /bin/zsh Binaries: Node: 22.2.0 - /opt/homebrew/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 10.7.0 - /opt/homebrew/bin/npm

Describe the bug

In safari Browser on mac after you click on the magic link from the email the browser redirect you to the login page ] http://localhost:3040/login?redirectTo=%2F which show you the login page again. This works without issues in chrome. I get redirected to http://localhost:3040/confirm-basic-details

Reproduction repo

https://github.com/triggerdotdev/docker

To reproduce

git clone https://github.com/triggerdotdev/docker cd docker cp .env.example .env follow the self hosting tutorial in the doc to set .env .. ./start.sh go to http://localhost:3040/ in Safari (MacOs) create account and check your email. click on the magic link

Additional information

No response

shaaridev avatar Oct 05 '24 19:10 shaaridev

same here, Safari 18.1 (20619.2.8.11.10) / macOS 15.1 / trigger.dev docker 3.1.1

smoothdvd avatar Nov 03 '24 02:11 smoothdvd

Are you both testing this on localhost? Webapp and worker on the same machine or split setup? Likely an env var issue as it worked fine when I just tried it with:

git clone https://github.com/triggerdotdev/docker trigger-docker
cd trigger-docker
./start.sh
# then login at http://localhost:3040/

I'd start fresh an see after which step it fails, my guess is it's one of these env vars:

# Only uncomment these once you've set up a domain and are trying to access the webapp through it
# On localhost, these should be commented out as below
# TRIGGER_PROTOCOL=https
# TRIGGER_DOMAIN=<your_subdomain>.ngrok-free.app

For a completely fresh start, you can nuke your DB, reset your .env and pull in any changes like so:

./stop.sh -v
rm .env
git pull
./start.sh

nicktrn avatar Nov 03 '24 09:11 nicktrn

This doesn’t explain why it works on Chrome but not on Safari.

smoothdvd avatar Nov 04 '24 05:11 smoothdvd

Ah right, I didn't see that part! This sounds familiar - I think we had an issue with magic links on Safari before. #186

nicktrn avatar Nov 05 '24 12:11 nicktrn

I found TRIGGER_PROTOCOL env not working when I set WEBAPP_PUBLISH_IP=192.168.1.x. It still runs on local , but magic link always generate https link even set TRIGGER_PROTOCOL=http.

smoothdvd avatar Nov 05 '24 13:11 smoothdvd

I don't think that WEBAPP_PUBLISH_IP should change anything, but it's possible that TRIGGER_PROTOCOL is being ignored. Is this the full or split setup? Also, when changing any env vars, make sure to restart all services. ./stop.sh && ./start.sh should do it.

nicktrn avatar Nov 05 '24 15:11 nicktrn

@nicktrn I use the full setup to self-host Trigger.dev on a home server. I set WEBAPP_PUBLISH_IP=192.168.1.x to allow another client PC to access it via http://192.168.1.x:3040.

smoothdvd avatar Nov 07 '24 01:11 smoothdvd

I found TRIGGER_PROTOCOL env not working when I set WEBAPP_PUBLISH_IP=192.168.1.x. It still runs on local , but magic link always generate https link even set TRIGGER_PROTOCOL=http.

Okay, I tracked this down to the external package we're using for magic link auth. It sets the protocol to "https" unless you're accessing the webapp via "localhost" or "127.0.0.1".

image

I don't see us changing this because it's very niche.

You could solve both problems quite easily if you're only accessing the webapp locally and have no need to secure logins. Setting NODE_ENV=development in your .env will disable magic link auth and log you in automatically.

An alternative would be to access the webapp only via the external domain, even when accessing on your local network.

nicktrn avatar Nov 07 '24 09:11 nicktrn

@nicktrn Thank you for help!

smoothdvd avatar Nov 07 '24 11:11 smoothdvd

Thanks for the quick response and explanation. I understand the reasoning behind the current behavior and the suggested workarounds. However, neither of those solutions are suitable for our specific development environment.

As a company that provides government software, we develop within a Virtual Private Cloud (VPC). This is a crucial security measure that allows our developers to access sensitive resources and simulate production environments securely from their local machines. Accessing the webapp via the external domain from within the VPC isn't feasible due to network configurations and security policies designed to isolate the VPC. Similarly, disabling magic link authentication entirely in our development environment isn't an option due to the need to thoroughly test the entire login flow.

The limitation of only supporting localhost and 127.0.0.1 for non-HTTPS protocols creates a significant hurdle for us. While we understand this might be considered a niche case from a general perspective, it's a common practice in secure development environments, particularly those dealing with sensitive data like government software.

Could we reconsider the possibility of allowing configuration for trusted local network ranges or perhaps a more flexible way to determine the appropriate protocol? This would greatly benefit developers working in secure environments without compromising the security for other users.

[DUPLICATE]: https://github.com/triggerdotdev/trigger.dev/issues/1605

AndryHTC avatar Jan 14 '25 10:01 AndryHTC

@AndryHTC ok this other use case makes sense too 👍

I think the best way to add support for this:

  1. Add an additional environment variable
MAGIC_LINK_FORCE_HTTP: z.string().default("false"),

To here: https://github.com/triggerdotdev/trigger.dev/blob/b3aa87ee266038e2197f902426bf47af141dc746/apps/webapp/app/env.server.ts#L24

  1. Modify the URL before sending the email, if the variable === "true"

https://github.com/triggerdotdev/trigger.dev/blob/b3aa87ee266038e2197f902426bf47af141dc746/apps/webapp/app/services/email.server.ts#L72

It should probably build a URL using the string, modify the protocol, then convert back into a string.

I'll happy review and merge a PR with these changes.

matt-aitken avatar Jan 14 '25 11:01 matt-aitken

Hi @matt-aitken,

Thanks for understanding our situation and proposing a solution for the magic link authentication issue.

AndryHTC avatar Jan 14 '25 12:01 AndryHTC