BaseURL + Uncommon Configuration With Reverse Proxy
We have a Nuxt3 app which we have created which is intended to be deployed to various locations as a Docker container.
The container gets mounted sometimes at the root of a url (https://www.somedomain.com/) and sometimes it gets mounted as a subdirectory, with an NGINX reverse-proxy sitting in front of it. (https://internal-domain.somedomain.com/nuxtApp/)
Ideally, we would configure this at runtime by passing a NUXT_APP_BASE_URL paramater of /nuxtApp/ when hosting on the sub path, but from the Nitro server's perspective, this outputs the rendered HTML looking for the following path: https://internal=domain.somedomain.com/nuxtApp/nuxtApp/_nuxt/entry.js
We have tried manually configuring the NUXT_APP_CDN_URL as well as the NITRO_APP_BASE_URL. The closest we have been able to get it functioning was to configure the CDN to point at /nuxtApp/ with a baseURL configured of /, but then the front end vue router seems to get lost and tries to forward us to /nuxtApp/nuxtApp/
It appears the NITRO_APP_BASE_URL seems to override/replace the NUXT_APP_CDN_URL, so we cannot independently control the NITRO server from the NUXT app (and the expected pathing of the vue router itself)
Really at a loss of how to set this up.
Any ideas would be GREATLY appreciated in trying to solve this.
somedomain.com
This domain may be for sale!
9 Replies
Unknown Userβ’5mo ago
Message Not Public
Sign In & Join Server To View
@creathir did you ever find a solution for this?
So we ended up writing a custom server plugin (last one which runs) which modifies the outbound payload of a request:
export default defineNitroPlugin((nitroApp) => {
nitroApp.hooks.hook('render:response', (response) => {
const pathPrefix = getPathPrefix();
const config = useRuntimeConfig();
const newPath =
${pathPrefix}${config.app.buildAssetsDir}.replace('//', '/');
const pathRegex = new RegExp(config.app.buildAssetsDir, 'g');
response.body = response.body.replace(pathRegex, newPath, 'g');
});
});
And we modified the Vue router with a app/router.options.ts which sets up the client router with our concept of a path prefix:
export default <RouterConfig>{
history: (base) => {
const pathPrefix = getPathPrefix();
return createWebHistory(pathPrefix base);
},
};
Then a nuxt plugin (very first nuxt plugin which runs) which sets things up on the client side:
export default defineNuxtPlugin({
order: -40,
setup: (nuxtApp) => {
const pathPrefix = getPathPrefix();
if (!pathPrefix) return;
const currentPath = window.location.pathname;
const modifiedPath = currentPath.replace(pathPrefix, '');
nuxtApp.payload.path = modifiedPath '/'; // We are running in a subdirectory, so we need to set the path to root
},
});
All make use of a util for getting the pathPrefix from our runtime config:
export const getPathPrefix = () => {
const {
public: { pathPrefix },
} = useRuntimeConfig();
return pathPrefix.endsWith('/') ? pathPrefix.substring(0, pathPrefix.length - 1) : pathPrefix;
};
Not ideal, but it works. @binarymelon@creathir Not sure if I missed something but the router options are throwing the following error.
(window only works on the client-side and not when using SSR)
Isn't router.options.ts the client side router?
@manniL / TheAlexLichter
needed on both sides
otherwise how would the server determine the routes? π
Anyway, disabling ssr got around that issue, but @creathir I'm guessing this is only intended to work for prod builds? All my vendor modules still don't have the prefix. I guess a little bit of background. I'm trying to run this in dev mode on a self hosted code-server which is behind a reverse proxy. code-server than proxies the server to subdomain.mydomain.com/proxy/3000.
Yeah, we have ssr disabled, sorry, forgot to mention that.
You could hook into the dev server too and still modify the outbound reply