feat(nuxt): navigateTo supports external redirects

[TheAlexLichter]

🔗 Linked issue

https://github.com/nuxt/framework/discussions/4997, resolvesnuxt/nuxt#14067

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Right now, navigateTo supports only internal redirects (either via vue-router or by using the baseURL).
This PR adds rudimentary support for external redirects and protocol checking:

1. It checks if the link passed in is external (if it has a protocol based on ufo)
2. If the protocol is script:, Nuxt will immediately throw an error on client- and server-side
3. If allowExternal is not set to true, then a confirmation dialog will pop up on client-side and an error will be thrown on server-side
4. If it is set to true it'll use h3 on the server-side or location.replace/location.href = X on the client-side

Also feel free to tell me if that's the right approach or if we want another function for this behavior 🤔
Doc update will follow when the PR is more mature.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[netlify]

✅ Deploy Preview for nuxt3-docs canceled.

Name	Link
🔨 Latest commit	d97e68a
🔍 Latest deploy log	https://app.netlify.com/sites/nuxt3-docs/deploys/630647e659153b0007be89a0

[UnderKoen]

Should it only allow http/https based urls? Or would mailto and tel also need to work?

A check that does include mailto and tel.

try{url=newURL(string);//url route}catch(_){//normal route}

Maybe it would be even better to have no check and have a additional entry in the to object so that the following would work:

navigateTo({url: "https://github.com"});

[TheAlexLichter]

Should it only allow http/https based urls? Or would mailto and tel also need to work?

A check that does include mailto and tel.

try{url=newURL(string);//url route}catch(_){//normal route}

Great idea! Will incorporate that in the code ☺️

Maybe it would be even better to have no check and have a additional entry in the to object so that the following would work:

navigateTo({url: "https://github.com"});

That would be one option but would leave the "check" up to the user. IMO the DX is better when Nuxt is doing the check for the user instead of leaving it up to them.

[pi0]

Thanks for this PR @manniL 💚 In general this is a really nice improvement that we support redirection to external URLs but I'm also little bit concerned about potential security risks implied by combination of this new feature and developer's mistake with a programmatic call. I suggest some options:

• Explicit protocol validation to avoid things like script:
• A new option externalURL: '' / external: true and abort when url is external with an error to use explicit option for external URL. (We might also use a simple alert/prompt fallback to concenst users about redireting when url is implicitly external)

[TheAlexLichter]

Thanks for this PR @manniL 💚 In general this is a really nice improvement that we support redirection to external URLs but I'm also little bit concerned about potential security risks implied by combination of this new feature and developer's mistake with a programmatic call. I suggest some options:

* Explicit protocol validation to avoid things like `script:`
* A new option `externalURL: ''` / `external: true` and abort when `url` is external with an error to use explicit option for external URL. (We might also use a simple alert/prompt fallback to concenst users about redireting when `url` is implicitly external)

Thanks for the feedback! 🙏
I agree regarding some security implications here. DX-wise, the protocol validation part would be more appealing IMO but from a security POV, a new option would make more sense.

What would be your favorite solution here?

[pi0]

I would probably do both:

• Protocol restriction in all cases
• Abort SSR / Prompt Client side with url: 'https://...'
• Introduce external: true or externalURL: string (Which one you think is better?)

[TheAlexLichter]

* Protocol restriction in all cases

That means not executing any links that start with script:. Any other protocols we should consider?

* Abort SSR / Prompt Client side with `url: 'https://...'`

By throwing an error with the approriate message, right?

* Introduce `external: true` or `externalURL: string` (Which one you think is better?)

I'd probably go with external: true. This param won't have any influence when the URL is local and will only matter in case the path is actually an external one, right?

[pi0]

That means not executing any links that start with script:. Any other protocols we should consider?

Considering the possibility of native app linking with custom protocols, yes the best we can exclude unsafe script: protocol.

By throwing an error with the appropriate message, right?

Would be an overkill to use good-old window.confirm as the default fallback? For server yes error is the best!

I'd probably go with external: true. This param won't have any influence when the URL is local and will only matter in case the path is actually an external one, right?

external: true seems good to me too! We can document to use external only if you are sure external URLs are safe. Or what about allowExternal?

[cawa-93]

I will add a little feedback as developer who faced with this problem. In general, reading the documentation, one gets the impression that the <nuxt-link>and navigateTo work identically. We can easily pass the external url in to without any additional: <nuxt-link to="https://github.com">. And I would expect the navigateTo to take exactly the same parameters and process them identically: navigateTo('https://github.com')

[TheAlexLichter]

Updated the PR with the recommended changes 😋

[justin-schroeder]

Until this is merged — I've worked up a small composable function to allow explicit external redirects from route middleware: https://gist.github.com/justin-schroeder/f583797c702155f32c9078d1add2a594

[serhez]

Hello! Are there any updates on this? It is quite critical for important workflows like OAuth 2.0 (being able to follow a server redirection to the login form, etc.), unless there is some other way to do it I missed.

[OhB00]

Found an interesting workaround for this one, prepending your URL with // enables you to perform an external redirect. For example, to redirect to http://google.com use navigateTo("//google.com"). This works provided your baseUrl is / as ufo will strip a slash from the start of your path.

Works because of parser differentials between the browser and vue-router/ufo.

Couldn't find a way to do this for other protocols.

[TheAlexLichter]

@pi0 Please let me know what is left to do here besides the docs PR ☺️

[pi0]

Thanks again for PR @manniL and sorry it took long. Finally, I've made few refactors to inline and simplify logic, avoid extra parse calls, improve messages and make the option simpler { external: true }. I hope this changes are fine to you.

[pi0]

One last thing to ensure: In nuxt 2, we had this problem with external navigations that during navigation, rest of logic goes on. And solution was a custom made error because it was sync. I think we could do something like a never resolving promise that avoids this. (will make a reproduction and implement in later PR btw need more testing) => https://github.com/nuxt/framework/issues/6906

[pi0]

(We also need to document new external key 🙈 ) => nuxt/nuxt#14704

[bars83]

why you check protocol for external? may be I want to redirect within current domain, i.e. respond with headers

HTTP/1.1 302 Found
Location: /my-legacy-page

[pi0]

Would you please open an issue with a sandbox to track? 🙏🏼