Closed marcoacierno closed 6 months ago
I see you are using vite.base
. Have you tried base
?
https://docs.astro.build/en/reference/configuration-reference/#base
I see you are using
vite.base
. Have you triedbase
?
Yes, I tried it as well; the only thing it does is it force you to go to (in my example) /base-you-set/your-actual-path. I imagine to simulate how the address would be in production. (I updated the repro link https://stackblitz.com/edit/github-wrbpwn?file=astro.config.mjs to show if you open the inspector it always points to root)
base
/ vite.base
/ vite.server.base
they all do nothing to what Astro puts as paths in
Thanks for clarifying!
This is not a use-case we had considered. We don't support it currently.
You mention you are putting the dev server behind a proxy, as opposed to a production server. That is a very specific use-case. Is there something preventing development locally on your own machine?
Thanks for clarifying!
This is not a use-case we had considered. We don't support it currently.
You mention you are putting the dev server behind a proxy, as opposed to a production server. That is a very specific use-case. Is there something preventing development locally on your own machine?
Thanks for checking it! I suspected it wasn't supported but didn't want to give up easily. I will close the issue as I suspect it is not really a use case worth spending much time on.
About my use case:
I described my setup quite badly, this is all for local development, and the production setup would just use the HTML files served directly by Django.
While working on my project, I want everything to go through a Django server (running on my machine) because:
The problems I flagged here for my use case (especially authentication and iframes) would probably be solved quite easily with a good CORS setup and just letting Django know to allow localhost:3002 iframes when in local development but I naively assumed it was just a matter of setting a base path and it would be done and be on the same origin 😂
If anyone (for some reason?) wants to do something similar, this is what I did in my case:
At this point, I am not even sure I will keep this workaround as it might break easily with future Astro versions too! :)
Thanks for providing context and resources for others. Good luck!
I don't think this is an extreme use case.
I have been trying for about a month to run two astro applications behind an nginx reverse proxy:
Although the "base" option (be that vite.base or base) let's the app be served under the path specified at "base", @fs, @vite, node_modules etc. are still served under the root domain.
It is quite common for professionals and companies to use docker with nginx and vite even during development for streamlined development, where there can be more than two frontend services running under the same docker network (e. g. while migrating codebases, with micro frontends, trying out multiple services etc.)
In such use cases there are clashes. I've had this problem in multiple occasions in two different jobs (with nuxt and astro specifically, due to @vite stuff.) and I know others who had the same problem.
I was expecting the below requests were like ".../astro/@vite...", ".../astro/@fs..." having "/astro" base path prefixed before the request path.
Need this.
During the development phase, we have multiple ports split into different applications. After build release, it is one application, and pages with different prefixes come from different projects.
I need to get through the session information of multiple applications on different ports, such as cookies or tokens.
Can it be reopened?
Happy to reopen as it seems multiple people actually have the same need :) I will leave it to the Astro team to decide if they want to fix it or not.
So, there are two ways to go on about this, and that would depend on how much you can configure on the proxy you are adding in front of Astro.
Suppose you send a request to /project-a/foo
, and all paths under /project-a
come from an Astro project. What should happen next?
/project-a/foo
that loads assets from /project-a
and it should serve those assets under /project-a
/foo
, so the Astro project should serve a page on /foo
that loads assets from /project-a
, but it should serve those assets at the rootWhether the proxy in front is doing a rewrite changes things significantly because, in that case, the tree that is generated by Astro is not the tree that everything that gets generated refers to. This makes things much trickier on Astro's side.
The first case seems reasonably straightforward to implement (not small tho), and I would be happy to guide someone to do that. The second case... I'd really prefer to just figure out how to not do a rewrite on whichever proxy is in front of Astro
@Fryuni is this an Astro bug at all? I'm having trouble seeing one.
I wouldn't say it is a bug because I don't think Astro has ever worked in that scenario. It is a feature request.
Hi team. it's really a feature request.
Ah yes, this is not really possible with Astro dev server as it's not able to add prefixes for things like file URLs or @id
URLs or a bunch of other stuff Vite has.
This seems very easy to configure on your proxy server. Just make it remove the /astro/
prefix and everything should work. Here's an example of how to do this with Nginx: https://stackoverflow.com/questions/28130841/removing-start-of-path-from-nginx-proxy-pass
I know that this can be easily done under nginx. We are actually doing this now in a production. Actually, this feature is request for dev mode exactly.
The situation is like this:
base: /_
configuration on port 9099.webpack-dev-server
proxy ['/_', '/src', '/@', '/node_modules']
to 9099.[astro-island] Error hydrating /src/components/SrvInfoWrapper.vue SyntaxError: The requested module '/src/components/hooks/dom/useZindexStyle.js' does not provide an export named 'default'
, If you access 9099 directly, everything works fine.Please re-open this.
We have 3 applications (from which 2 are astro projects) that we run under the same proxy. The production setup is ok, but the development environment is a nightmare to manage for the moment.
Astro Info
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
Hello!
I have a setup where I need to run Astro behind a "proxy" server in local development. Developers go to a Django server and navigate to (for example)
localhost:8000/admin/schedule-builder/
. This URL will render an iframe pointing tolocalhost:8000/astro/schedule-builder
.The URL
/astro/{path}
forwards all the requests to theastro dev
local server.To make this flow work, I need all URLs that Astro generates to be prefixed with the base /astro. I tried setting the
base
param in all places: at the root of the config, insidevite
, insidevite.server
but all URLs that Astro creates in the page always point to the root.E.g. a config I tried:
What's the expected result?
Astro should prefix all the URLs with the base when specified in the config
As an example, if you go to the repro link, you can see that the
<script>
tag src is:Ideally this should be
Link to Minimal Reproducible Example
https://stackblitz.com/edit/github-wrbpwn?file=astro.config.mjs
Participation