Hiding Astro behind a proxy with a base path in development

[marcoacierno]

Astro Info

Astro                    v4.2.7
Node                     v18.17.1
System                   Linux (x64)
Package Manager          unknown
Output                   static
Adapter                  none
Integrations             @astrojs/react
                         @astrojs/tailwind

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 to localhost:8000/astro/schedule-builder.

The URL /astro/{path} forwards all the requests to the astro 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, inside vite, inside vite.server but all URLs that Astro creates in the page always point to the root.

E.g. a config I tried:

export default defineConfig({
  vite: {
    base: 'astro'
  },
  integrations: [react(), tailwind()],
  build: {
    format: "file",
    assetsPrefix: "//django-static/",
  },
});

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:

/@fs/home/projects/github-wrbpwn/node_modules/astro/dist/runtime/client/dev-toolbar/entrypoint.js?v=0a375a3a

Ideally this should be

/astro/@fs/home/projects/github-wrbpwn/node_modules/astro/dist/runtime/client/dev-toolbar/entrypoint.js?v=0a375a3a

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-wrbpwn?file=astro.config.mjs

Participation

• I am willing to submit a pull request for this issue.

[lilnasy]

I see you are using vite.base. Have you tried base?

https://docs.astro.build/en/reference/configuration-reference/#base

[marcoacierno]

I see you are using vite.base. Have you tried base?

docs.astro.build/en/reference/configuration-reference/#base

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 <script>

[lilnasy]

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?

[marcoacierno]

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:

1. I wanted to simulate how this would work in production as much as possible. And in production, there wouldn't be an iframe pointing to another origin. (Astro's dev server)
2. I wanted an easy way to share cookies, sessions, and communicate between the Astro app and iframes opened in it that might open back a different page of the Django admin app. Use cases that different origins might make more complex to do.

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:

1. When proxying from Django to Astro, I updated the JS files to fix the paths: https://github.com/pythonitalia/pycon/blob/429600e4198655dc187b0f277cb0290d641111f5/backend/custom_admin/views.py
2. I also have to proxy the Hot reload module WebSocket: https://github.com/pythonitalia/pycon/blob/429600e4198655dc187b0f277cb0290d641111f5/backend/custom_admin/ws-proxy/ws.py as the paths need to be fixed there as well to make the hot reload work like before.

At this point, I am not even sure I will keep this workaround as it might break easily with future Astro versions too! :)

[lilnasy]

Thanks for providing context and resources for others. Good luck!

[unbeauvoyage]

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.

[yoyo837]

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.

[yoyo837]

Can it be reopened?

[marcoacierno]

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.

[Fryuni]

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?

• The proxy would forward the request unchanged to the Astro project server, so the Astro project should serve a page on /project-a/foo that loads assets from /project-a and it should serve those assets under /project-a
• The proxy would send a request to the Astro project server asking for /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 root

Whether 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

[matthewp]

@Fryuni is this an Astro bug at all? I'm having trouble seeing one.

[Fryuni]

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.

[yoyo837]

Hi team. it's really a feature request.

[matthewp]

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

[yoyo837]

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:

1. Start astro containing base: /_ configuration on port 9099.
2. Start another application at 9087 through webpack-dev-server proxy ['/_', '/src', '/@', '/node_modules'] to 9099.
3. Access 9087 in browser, it report an error when encountering the proxy content of 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.

[klodoma]

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.

[florian-lefebvre]

This issue has been closed a while ago and this is not considered a bug AFAIK so any request made here will unfortunately go unnoticed. Please check if there's already a proposal for it at https://github.com/withastro/roadmap/discussions, and create one if not (feel free to share the link here)!

[dreamstar-enterprises]

I sort of need this.

My reverse proxy routes all requests that are localhost:7080/astro/ to localhost:4321/astro

The index page loads, but all the node modules are being requested as localhost:7080/node_modules, etc. hence, the page does not load properly.

This is not a problem at all with angular by the way.

My astro app already has the base: astro applied in the astroconfig file.

Could I request the Astro team re-consider this feature?

[florian-lefebvre]

Hi @dreamstar-enterprises see #9989 (comment)