-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
security.allowedDomains is not working #14891
Description
Astro Info
Astro v5.16.0
Vite v6.4.1
Node v20.11.0
System macOS (x64)
Package Manager npm
Output server
Adapter @astrojs/node (v9.1.3)
Integrations @astrojs/react (v4.2.3)
astro-auth
astro-compress (v2.3.8)
If this issue only occurs in one browser, which browser is a problem?
Firefox, Chrome (mac tahoe)
Describe the Bug
I'm considering building a web page using Astro that supports server-side rendering.
In Astro 5.16.0, I set a value for security.allowedDomains in astro.config.mjs, but it has no effect.
(I referred to: https://docs.astro.build/ja/reference/configuration-reference/#securityalloweddomains)
// astro.config.mjs
export default defineConfig({
output: 'server',
// ...
security: {
allowedDomains: [{ hostname: '**.example.com' }],
},
});(I also attempted specifying port and protocol, but did not obtain the expected results 😢)
// in pages/index.astro file
Astro.request.headers.get("Host"); // "dev.proxy.example.com"
Astro.request.headers.get("X-Forwarded-Host"); // "dev.example.com"
Astro.request.headers.get("X-Forwarded-Proto"); // "https"
Astro.request.headers.get("X-Forwarded-Port"); // "443"
Astro.url.href; // "https://dev.proxy.example.com"
// but expected "https://dev.example.com" (without ".proxy")What's the expected result?
Astro.url returns "https://dev.example.com/"
Link to Minimal Reproducible Example
Although it differs from the actual environment, performing a request with a simulated header yields similar results.
https://stackblitz.com/edit/github-jrmtwg2t-cpgnqubk?file=src%2Fpages%2Findex.astro,astro.config.mjs
- run
npm run dev - open new terminal (
+button) - run curl command
curl "http://localhost:4321/" \ -H "host:dev.proxy.example.com" \ -H "x-forwarded-host:dev.example.com" \ -H "x-forwarded-proto:https" \ -H "x-forwarded-port:443" \ -i
- check the responded JSON (especially
astroUrl){ "astroUrl": "http://dev.proxy.example.com/", "host": "dev.proxy.example.com", "xForwardedHost": "dev.example.com", "xForwardedProto": "https", "xForwardedPort": "443" }
(NOTE: In this local environment example, the same behavior might occur even in versions prior to v5.14.2, but in actual (deployed) reverse proxy environments, it only occurs in the latest version.)
Participation
- I am willing to submit a pull request for this issue.