x-forwarded-host header does not match origin
#58295
Comments
|
Fantastic, adding their recommendation of the following sorted the issue for me; next.config.js So for those needing a hand with this, the above should work as fix. Thanks for digging that out @JavierMartinz |
|
can't get it working from VSCode desktop connected to a CodeSpace, tried with the following next.config.js {
experimental: {
serverActions: {
allowedForwardedHosts: ['localhost'],
allowedOrigins: ['http://localhost']
},
}
} |
|
I found this thread following the same issue, and have tried @lewisnewson I noticed your commend mentions that you had this working in I had a look at type definition for serverActions?: {
/**
* Allows adjusting body parser size limit for server actions.
*/
bodySizeLimit?: SizeLimit;
/**
* Allowed origins that can bypass Server Action's CSRF check. This is helpful
* when you have reverse proxy in front of your app.
* @example
* ["my-app.com"]
*/
allowedOrigins?: string[];
};my /** @type {import('next').NextConfig} */
const nextConfig = {
async rewrites() {
return process.env.NODE_ENV !== 'production' ? [
{
source: '/api/:path*',
destination: 'http://localhost:8000/:path*',
},
{
source: '/media/:path*',
destination: 'http://localhost:9000/:path*',
},
] : []
},
images: {
remotePatterns: process.env.NODE_ENV !== 'production' ? [
{
protocol: 'http',
hostname: 'localhost',
port: '',
pathname: '/media/**',
},
] : [
{
protocol: 'https',
hostname: 'qa.myappdomain.au',
port: '',
pathname: '/media/**',
},
],
},
experimental: {
serverActions: {
allowedOrigins: [
'http://localhost',
'https://qa.myappdomain.au/api',
]
}
}
} |
|
Issue also happens for me when running |
|
I've had the same issue with nginx. I tried using serverActions.allowedOrigins and also experimental.serverActions.allowedOrigins / allowedHosts but didn't help. Downgrading to 14.0.1 fixed the problem. Hope the next update fix this. |
|
Downgrading to v14.0.0 makes it work. |
|
This also doesn't work for me w/ version > 14.0.1. Using Nx as well. |
My two cents worth on another thread on the same issue. |
|
The same here after update to 14.0.2 |
|
This will be fixed by #58500 |
|
This is fixed in 14.0.3, upgrade to next 14.0.3 and the error will be gone. |
|
Confirmed this is now solved in version 14.0.3. Thanks all! |
|
I came across this issue ; upgrading to 14.0.3 did not solve it for me, but downgrading to 14.0.0 did. |
same here. not fixed in 14.0.3. |
|
confirmed, it fixed in 14.0.3 |
|
This doesn't work if using a custom port. I'm still getting the following in 14.0.3:
|
|
14.0.3 Not fixed for us too. We deploy on k8s and nextjs is behind nginx, and we get this. Is there a way to disable this behaviour for now? |
|
I fixed this on my end by just returning from nginx whatever next.js expected instead of the standard |
like this? |
|
Yes, on my end it looks like this: |
confirmed working but I think it's hacky |
|
I'm working on 14.0.3 in Codespaces and still getting error: nextjs.config.ts |
|
14.0.3 Not fixed for us too. |
|
Same for me - not fixed. |
This fixed it for me |
this also resolves #58914 |
|
Shortest possible answer: So this is a bug, because the actual action should be pointing to localhost:3001 which is where the app is running. In my case I ALSO have a nextjs app running on localhost:3000. So some of my comments below may be unjustified except the part about clarifying the code and error messages perhaps. I think the offending code is here: https://github.com/nextauthjs/next-auth/blob/main/packages/next-auth/src/react.tsx#L57 baseUrl and basePath do not honor the NEXTAUTH_URL_INTERNAL as they should so when the login form generates it gets a default unless NEXTAUTH_URL is configured, after configuring NEXTAUTH_URL stopping and starting the app and doing a full browser refresh, the form has the right url now. Short answer: I am pretty sure the offending code is here: It seems like this code is trying to mitigate a CSRF attack, but it relies strictly on host for comparison and not on host:port, which breaks things when you are running two different services in the same domain but on different ports. So perhaps the intent was to ensure that either we set allowed origins as is called out in these lines of code: Long answer: forwarded Server Actions request. Aborting the action. So I dug a little more the actual error message was I scanned node-modules/next/dist/server/base-server.js and found the following lines of code in starting at line 505 This would explain a lot if the receiving app is running on host localhost:3000 and a request is made to it from another next app on localhost:3001, then the request header would have a host of localhost:3000. But then line 505 would set the x-forwarded-host to localhost:3000, which would later trigger the issue where the x-forwarded-host does not match the value of the origin host which is localhost:3001. Looking at the next version 14.0.3 code line 505 now looks like this: But that change does not address the issue when you are testing two next apps running on localhost. So I don't think the issue has been resolved in 14.0.3. In many places in the compiled JS under app-page-experimental.runtime.dev.js for example there is this snippet from a forwarded Server Actions request. Aborting the action. I think that whoever is responsible for that code was confused about the difference between what the x-forwarded-host header and the x-forwarded-for header are all about. The X-Forwarded-For (XFF) request header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a proxy server. And so is the origin header in which case such a check would make sense but not the check that is currently happening in nextjs. |
Based on the fact that you have multiple For those that run nginx with |
Thanks!! It solve my problem. |
|
I had the same problem on AWS ECS Fargate where I using nginx in side container as reverse proxy for Next.js. Here is my template for nginx.config that is working great: and script to replace these variables in template: #!/bin/sh
# this script is used to replace the environment variables in the nginx.conf file
# env variables are set by infrastructure, ECS Task Definition
# shellcheck disable=SC2016
envsubst '$DOMAIN_NAME $NEXT_JS_URL $WEB_FLOW_HOST $WEB_FLOW_URL' < /etc/nginx/template.nginx.conf > /etc/nginx/nginx.conf
exec nginx -g 'daemon off;'dockerfile FROM nginx:alpine
# needed to use envsubst in start-nginx.sh
RUN apk add busybox-extras
# Copy the Nginx config
COPY template.nginx.conf /etc/nginx/template.nginx.conf
COPY start-nginx.sh /start-nginx.sh
RUN chmod +x /start-nginx.sh
# Forward request logs to Docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 80
CMD ["/start-nginx.sh"]env variables in task definition: environment = [
{
name = "DOMAIN_NAME",
value = "www.domain.tld"
},
{
name = "NEXT_JS_URL",
value = "http://localhost:3000"
},
{
name = "WEB_FLOW_HOST",
value = "webflow.domain.tld"
},
{
name = "WEB_FLOW_URL",
value = "https://webflow.domain.tld"
}
], |
|
i'm on v14.0.3 and using this works for me. ps. do not add HTTP or https on origins |
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
and others
Link to the code that reproduces this issue
https://github.com/lewisnewson/nextjs-14.0.2-bug-report
To Reproduce
mainbranch onto a basic Heroku dynoCurrent vs. Expected behavior
Currently:
x-forwarded-hostheader with valuelocalhost:23380does not matchoriginheader with valuenextjs-14-0-2-bug-report-4ea064a57303.herokuapp.comfrom a forwarded Server Actions request. Aborting the action. -- Error: Invalid Server Actions request."What should happen:
Verify canary release
Provide environment information
Operating System: Platform: linux Arch: x64 Version: #54~20.04.1-Ubuntu SMP Fri Oct 6 22:04:33 UTC 2023 Binaries: Node: 20.9.0 npm: 10.1.0 Yarn: N/A pnpm: N/A Relevant Packages: next: 14.0.3-canary.0 eslint-config-next: N/A react: 18.2.0 react-dom: 18.2.0 typescript: N/A Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
App Router
Additional context
Since upgrading from 14.0.1 to 14.0.2, deployments into a Heroku environment have now seen issues arise with the use of server actions. This can be shown in the example provided, when deployed to Heroku, loading the application prints the error message into the console of the dyno.
This issue does not happen when running
next devon a local machine, instead it only seems to appear when the application is deployed into production.The text was updated successfully, but these errors were encountered: