Questions should be posted on https://spectrum.chat/next-js
I use next@7. And after build, I run a custom server follow the document, then I see my .js file was requested by route like http://localhost:3000/_next/static/runtime/webpack-89179faa512dd01fbb62.js, any chance to change _next into something customized path ?
Thanks
There is no need for doing this. So it's not possible to change the path.
There is a need :
Android build does not get folder starting with an undescore.
@timneutkens I am wondering about this too, I am looking at running 2 nextjs apps on the same domain as subroutes. Here is an example of my routing configuration:
/api/* https://api.domain.com/:splat 200
/nextApp1/* https://nextApp1.domain.com/:splat 200
/_next/* https://nextApp1.padpiper.com/_next/:splat 200
/nextApp2/* https://nextApp2.domain.com/:splat 200
/_next/* https://nextApp2.domain.com/_next/:splat 200
/* /index.html 200
Without being about to change the _next
directory I can't run both apps on correctly on the domain.
I have a situation similar to @zlwaterfield .
There is a need as hackers / attackers will be able to guess a website is using next.js just from seeing the _next. Please revisit this issue @timneutkens
Again this is not an issue, it's super easy to detect any framework in existence. You could detect next based on __next
, __NEXT_DATA__
_next
, but even then, you could detect next on static/<buildid>/pages/something.js
static/webpack/runtime.js
etc.
There is no way for us to cover these cases, and even if we did it's easy to detect based on file contents.
So this is not a security issue.
@timneutkens I'm not concerning about security issue. I just encountering the same requirement like @zlwaterfield . We will have multiple nextjs app in different server at the same time, and we will use a reverse proxy server to forward our request to different server according to our url.
Our application like:
App1 static source /app1urlpattern/static/STATICFILE
App2 static source /app2urlpattern/static/STATICFILE
...
we need these app1urlpattern and app2urlpattern to be different.
So, any chance to implement this?
assetPrefix
already exists for handling that.
hi @timneutkens,
Does assetPrefix
also update the calls to the __next/static/...
?
@ferrybrouwer assetPrefix
changes the requests from _next/...
to prefix/_next/...
which results in 404 because the files are still actually served from _next
.
I found the solution here
adding:
app.setAssetPrefix(ASSET_PREFIX);
in my custom server, and
req.url = req.url.replace(
/${ASSET_PREFIX}, '');
in the serving.
@timneutkens WDYT?
I handled this issue via Nginx Routing.
What i assumed while making this Nginx Routing is that every file will have unique hash and file name combination.
This is the snippet of code of Nginx Routing which i used.
location /static/ {
try_files $uri @server1;
}
location @server1{
proxy_pass http://192.168.1.1$uri;
proxy_intercept_errors on;
recursive_error_pages on;
error_page 404 = @server2;
}
location @server2{
proxy_pass http://192.168.1.2$uri;
proxy_intercept_errors on;
recursive_error_pages on;
error_page 404 = @server3;
}
location @server3{
proxy_pass http://192.168.1.3$uri;
}
What the above code does is, whenever Nginx encounters /_next/ it will first try that URL with @server1, if that Server responds with 404, the Nginx then transfers the request to @server2 as mentioned in error_page param.
This example works like:
try_files $uri @server1 @server2 @server3
This worked for me as i had 2 apps which were developed on Next and both has _next route.
Let me know if this solves your problem.
We have the same situation of wanting to run multiple Next apps on the same domain.
In our production and production-like envs we use a CDN, and so the assetPrefix
configuration allows us to specify our CDN domain and have different paths for different apps, which ensures requests for assets are sent to the CDN. We control the server side (the CDN), so we can ensure that the assets are served at those paths.
However in other envs we don't use a CDN (e.g. local development env), but still want to sometimes run multiple Next apps on the same domain. The assetPrefix
handles making sure requests are sent to the correct domain/path, but since the Next server only mounts at /_next
and isn't customizable or prefixable, the server side of the equation isn't handled by Next. We have to do URL rewriting in order to get the requests to the Next server.
We don't want to use the Next basePath
configuration to provide Next server separation in the URL path space, because that limits our ability in some circumstances to intermix which Next apps are serving which URL paths (an edge case, but we'd like to maintain this flexibility) without also doing rewriting.
Having a configuration option that allows the /_next
path on the server to be prefixed (or to be prefixed with assetPrefix
path, without any domain) would simplify the process of adding more Next apps by not requiring us to configure rewrite rules in non-CDN, Next-served environments with multiple Next apps on the same domain.
Using Next.js 9.5 something like this should cover your case just fine:
module.exports = {
assetPrefix: '/docs',
rewrites() {
return [
{ source: '/docs/_next/:path*', destination: '/_next/:path*' }
]
}
}
Thanks @timneutkens!!
There is a need as hackers / attackers will be able to guess a website is using next.js just from seeing the _next. Please revisit this issue @timneutkens
I am facing the same issue, have you got any solution for this?
Using Next.js 9.5 something like this should cover your case just fine:
@timneutkens This works for everything except for webpack-hmr
calls. Changing the assetPrefix
will cause those requests to be prefixed too, but they result in a 404, because the endpoint will still be on /_next
without prefix. Should I create a bug ticket?
Most helpful comment
@timneutkens I am wondering about this too, I am looking at running 2 nextjs apps on the same domain as subroutes. Here is an example of my routing configuration:
Without being about to change the
_next
directory I can't run both apps on correctly on the domain.