louislam
Subfolder support (publicPath)
Problem: I'm using nginx to proxy localhost:3001 to domain.com/kuma, but at the moment vue app expects that everything is served from root (domain.com/assets/vendor.a54d5402.js) and all assets get 404, because all files are in kuma subfolder (domain.com/kuma/assets/vendor.a54d5402.js) not in root directory.
Solution: I'm not familiar with vue, but I guess it needs this public path setting for relative paths: https://cli.vuejs.org/config/#publicpath https://vitejs.dev/config/#base
If there are no other obvious limitations then please consider using relative paths.
It is great app & thanks for your work!
Just trying to implement this and realized that it is much harder than I thought, because express.js itself is not so friendly with subdirectory.
For example, in express.js you defined a route "/", it still points to "domain.com" rather than "domain.com/kuma", no matter what you have done in reverse proxy.
I cannot find any solution from the Internet that without hardcoded the subdirectory in the source code. I marked it as "help wanted" see if anyone know how to do it in a smart way.
I guess a really dumb way would be to define a route in the server
.get('/basepath', function (req, res, next) {
if (req.accepts("html")) {
res.send(process.env.basepath);
...
and then in the front-end, check this route on load, and use this path to construct all links.
Loading js/css assets works fine with this vite.config.js:
export default defineConfig({
base: "./",
plugins: [
vue(),
legacy({
targets: ['ie > 11'],
additionalLegacyPolyfills: ['regenerator-runtime/runtime']
})
]
})
Both root & subfolder are fine and resources are found.
But in subfolder websocket socket.io url is still fixed to root path. wss://example.com/socket.io/?EIO=4&transport=websocket
should be (kuma subfolder) wss://example.com/kuma/socket.io/?EIO=4&transport=websocket
Websocket.io has several path options, but I'm not sure what is best way to make it work in both root&subfolder setup at the moment.
Edit: After some testing I haven't found good & reasonable solution. Subdomain is better choice at the moment :)
Do you know which open source web apps are supported to map to a subdirectory? Maybe I can look into their source code.
Linuxserver.io (https://github.com/linuxserver/reverse-proxy-confs) have several config samples for applications supporting being on subfolder and subdomain, maybe this can help. Vaultwarden (https://github.com/dani-garcia/vaultwarden) is another tool that have websockets, if I'm not mistaken, and can be deployed to subdomain or subfolder.
Just commenting to follow the issue, as I'm really interested in this too.
@louislam @siimots Try using this:
location ^~ /kuma {
rewrite ^/kuma(.*)$ $1 last;
}
It should rewrite (internally) any request to /subfolder to /
Wouldn't the problems be solved if all the links on frontend were relative? Additionally HTML Base element could be used
@louislam @siimots Try using this:
location ^~ /kuma { rewrite ^/kuma(.*)$ $1 last; }It should rewrite (internally) any request to /subfolder to /
Confirming that I haven't managed to find any combination of rewrite rules that will allow Uptime-Kuma to be proxied from a subfolder (including the one above).
@es9o @gaby
this still leaves a few issues on the frontend, which has "hard-coded" absolute paths e.g. to /assets/ and /socket.io/
My temporary solution is to host kuma on another port of the same (sub)domain. Apache listens on port 443 (https) and proxies it to kuma on 3001
After 12 hours of testing and trying and researching on the internet, I'm at the end. Nothing really works. (I am crazy in my head.)
Please solve the problem. Thank you.
My personal workaround is to exclude the "other" folders.
ProxyPass /test.html !
ProxyPass /index.html !
ProxyPass /html !
ProxyPass /shop !
After 12 hours of testing and trying and researching on the internet, I'm at the end. Nothing really works. (I am crazy in my head.)
Please solve the problem. Thank you.
My personal workaround is to exclude the "other" folders.
ProxyPass /test.html ! ProxyPass /index.html ! ProxyPass /html ! ProxyPass /shop !
That why I said before:
Just trying to implement this and realized that it is much harder than I thought
It is almost impossible, because express.js do not support it. Also need to deal with Vue.js / WebSocket path issues.
I close it now, as it is technically impossible.
Hello and thanks for your answer. You should keep it open to give the chance to add some more information or an other workaround.
I am convinced that there is a solution if there is someone who knows the apache rewrite rules well.
Hello and thanks for your answer. You should keep it open to give the chance to add some more information or an other workaround.
I am convinced that there is a solution if there is someone who knows the apache rewrite rules well.
Yeah exactly, closing the issue doesn't make it a non-issue. The issue is still there, just not tracked. Someone will probably open another identical one in a few months/weeks as this wasn't solved. Maybe just add a "later" label instead?
I am convinced that there is a solution if there is someone who knows the apache rewrite rules well. This isn't a matter of rewrite. It is properly rewriting to the appropriate spot on the web server. Reverse proxies add the X-Forwarded-Prefix in whatever they remove so the application, when building a URL, will know to add that to anything it generates. It gets to the right place ( you can view source to see ) but then the /assets/ and so on are hardcoded. These appear to be done at build time by the underlying tools like Vue.
You should keep it open to give the chance to add some more information or an other workaround. I agree. In an era of reverse proxies behind SSL for everything, having a custom X-Forwarded-Proto, X-Forwarded-Prefix and X-Forwarded-Host should be obeyed. Or at the very least, the app could be manually configured with an environment variable BASE_URL which is then brought in with import.meta.env.BASE_URL which is determined by by the base config option. Not sure if that's at runtime of buildtime though.
I'd just like this issue to stay open. Maybe one day the underlying tools will come around.
If there's an interest, I'm happy to explore this issue more.
There is some suggestion here that sys "if the value (publicPath) is set to an empty string ('') or a relative path (./) so that all assets are linked using relative paths. This allows the built bundle to be deployed under any public path". Wouldn't that solve our issue entirely just by setting the public path to a relative URL?
I had spent some time on this previously, as I said before I am quite sure that it is impossible. Just don't want to give a false hope to anyone, that's why I closed it.
Because Uptime Kuma bundled everything in a single application, we have to deal with:
- Vue
- express.js
- socket.io
Three things all come together that make it impossible to support a reverse proxy on a sub-directory.
Look Ma! Kuma in subdirectory!
I have pushed the changes to my fork I have tested it only manually in the browser, there might b something broken and the implementation is not very clean. Treat it as a proof of concept and feel free to improve it
Edit: the BASE_PATH must start and end with slash, e.g. /kuma/
I have pushed the changes to my fork I have tested it only manually in the browser, there might b something broken and the implementation is not very clean. Treat it as a proof of concept and feel free to improve it
Edit: the BASE_PATH must start and end with slash, e.g.
/kuma/
OMG, you are genius! Thank you for proofing me wrong!
I am very happy when this is implemented. Is there already a rough idea when this could be ready? :-)
@pm-pm no idea. I am not working on it right now. I need to run existing tests and probably create new ones. I think it is not much of work, probably for less than a day. @louislam Have you looked at current implementation? Do you approve it?
@pm-pm no idea. I am not working on it right now. I need to run existing tests and probably create new ones. I think it is not much of work, probably for less than a day. @louislam Have you looked at current implementation? Do you approve it?
Feel free to create a pull request first. I am not quite free recently and there are many pull requests that I still have not reviewed, so it may get longer time to be approved.
I am late to this game so I might be opening a can of worms or missed an update. But I see the Primary Base URL in the settings and set it to https://kuma.domain.com and it doesn't work. I also realize that I think it is specifically asking for something like https://domain.com/kuma but that isn't how I do this in my environment so before I made a large change, I wanted to make sure I understand how you had it setup as well as if the fix for this had been pushed alreay.
Thank you for your reply.
I think primary base URL in settings is only used to generate URLs for push-type monitor. My subfolder deployment uses ENV variable to set the path. The path can be anything, it doesn't need to be exactly "/kuma"
See my comment https://github.com/louislam/uptime-kuma/issues/147#issuecomment-996979446 Or the PR https://github.com/louislam/uptime-kuma/pull/1092
@pm-pm what do you mean?
trogper could you please start a pull request or work with louislam so that this will be possible in the future? Unfortunately, I am not in a position to do this as I lack the knowledge. But I would be very happy if this feature would be implemented. :-) Thanks a lot
@pm-pm oh, alright. The PR is already open, #1092 I am willing to work on it, but I have a few questions about technical concerns, already stated in the PR. Louislam has not yet answered them
I apologise for not seeing the PR you had already created. Thank you for your work.
I am using Version: 1.16.1 of uptime kuma just wondering on the progress? I am having the same issue of a blank page when trying to view example.com/kuma. I am using traefik. When I go to the site all is blank. When I strip the prefix 'kuma' and goto example.com/kuma it is instantly redirected to example.com/dashboard.
It is still not merged, I need to do some work on it before it's ready. Did not have much time for it until this week, so it might probably be ready in the coming weeks.
Hi, im using version 1.17.1. And im facing a similar situation, where im tryhing to "park" kuma under a path using Nginx Has there been any development on this ?
@Ruskyy Yes, it is done in my fork of kuma and it's ready to be merged into official one. Merging is not my job, so can't give you any ETA
I am also stuck with same issue. @louislam Any possibility of getting this feature ?
@louislam Are we ready to merge this yet? I have a strange setup that this may fix. I have nginx in front of the app, proxied root to uptime.internal.lan/ and public status page at /status/mypage/ proxied uptime.mydomain.com/ which is blank with the same errors as stated above.
