-
-
Notifications
You must be signed in to change notification settings - Fork 468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
web.context-root is needed if the URL can not be rewritten. #88
Comments
As mentioned in v2.0.0's release notes:
The main reason for removing it is due to my inability to make a dynamic context root work with Vue.js' router (without ugly hacks) despite several attempts. If you want to have a go at it, feel free, but unless a few more people request this, I won't personally try to re-implement it. That being said, for your specific issue, most people create a separate CNAME (e.g. |
What about this? https://stackoverflow.com/questions/43879418/deploy-vuejs-app-in-a-subdirectory
(bear in mind that I know nothing of what I write - I just googled the problem - hopefully not wasting your time here) In terms of the usefulness of being able to host content in a sub-directory - it's one of the first things I look for in a service I want to privately self-host (ie. purely for my own use). Being in a subdirectory means that its existence is not visible, whereas the existence of subdomains is publicly displayed in DNS. |
I hope that's not one of the "ugly" hacks you refer to :-) |
@KarlMW Hahaha no, if it was just that, it couldn't even be called a hack. In fact, this would work fine if we weren't using Vue's router for the service detail page. Long story short, one of
I tried several different methods, but none worked in a clean way. I didn't want to specify what I meant by "ugly" hacks, because they're really ugly, but the one way I found that works would be to read the generated static script ( By the way, it is not possible to do a reverse lookup to retrieve the CNAMEs of a domain (unless you have access to the zone files). For instance, if I create the CNAME This is known as denial of existence. Even if a malicious user had access to the zone files, you could still hide it from them by using a wildcard CNAME domain record, and by pointing that to a reverse proxy which would have the necessary configuration telling it to route requests with a given host to the appropriate application, you'd be the only person privy to the existence of that application. That being said, this is still security by obscurity, which is IMO not enough if you don't want prying eyes to have access to your application, which is why you can also configure basic authentication on top of that: https://github.com/TwinProduction/gatus#basic-authentication |
Thanks for the detailed reply. You've made gatus very easy for people to build in docker themselves - thanks for that, too :-) w.r.t. CNAME reverse lookups, I'm not sure how it's done, but my never-used-publicly CNAMEs are findable on the web, eg. via https://www.nmmapper.com/sys/tools/subdomainfinder/ Whether it's some sort of active probing, or whether they just monitor certificate transparency logs, I don't know. I generally use client certificates (handled by traefik) for my private domains (as well as passwords), so I'm reasonably confident that no-one can get in, but I like a bit of obscurity as well :-) |
@MiddleMan5 If you or anybody else can get it to work with the front-end, feel free to do so. I'm completely fine with using a different approach for routing -- if I do want to rewrite a good part of the UI at some point and make it a little less minimalist, but I don't know when that will happen. |
They get this data from SSL Transparency. Looking at it from a number of domains I control, it includes only those that exist in SSL Transparency records (even a typo that existed for 1 minute) that show up there. Unless you have an misconfigured (or old pre RFC8482 server that still answers ANY queries, this is the only place to get the values. I'm sure the big names (8.8.8.8 and 1.1.1.1 or major ISPs) could probably assemble it from DNS query logging though. It should be assumed that it's out there (and hence have basic auth or something like authelia in front of it). I agree that subdomains are a better place for a lot of services, but this same problem exists with many VUE apps. |
Got stuck in this issue when I configured Gatus behind a Google's LB backed by IAP authentication. Would be great if we can call this out in the README to avoid surprise at the end. |
@ansilh Could you make a PR for this? |
after some tries, here is what worked for me:
|
I'm homelab enthusiast with free domain from DDNS provider, subdomain option unavailable for me. Subpath would be very useful, otherwise I can use Gatus only through SSH tunnel :( (but its very uncomfortable from mobile device) |
I'm in the same situation as @rokiden here! Adding new domains to the infra in question is not possible. If the paths for the CSS and JS and badges had the preceding |
could you please help me with it |
I just opened a PR that tries to fix this: #908 |
I'm testing Gatus as a status page for our product CZERTAINLY. It operates in Kubernetes and comprises several services which we would like to monitor. We have already integrated KeyCloak for the SAML/OIDC proxy and RabbitMQ as a messaging bus. Keycloak resides on $URL/kc, RabbitMQ on $URL/mq, and we would like to integrate Gatus the same way - to reside on $URL/status. I like @simonhammes solution, which made this possible. |
I am not following this. Here is what I did: # set env vars
export VUE_PUBLIC_PATH=/healthcheck
export FULL_IMAGE_NAME=gatus:v5.13.1-custom-path
# set publicPath in vue.config.js
sed -i -e "s|publicPath: .*|publicPath: '${VUE_PUBLIC_PATH}'|" web/app/vue.config.js
# use relative path '.' for SERVER_URL in main.js
sed -i -e "s|export const SERVER_URL = .*|export const SERVER_URL = '.'|" web/app/src/main.js
# use relative path '.' for resources in index.html
sed -i -e 's|="/|="./|g' web/app/public/index.html
# Install tooling
npm install -g @vue/cli
npm i @vue/cli-service
npm i '@vue/cli-plugin-babel'
npm i '@vue/cli-plugin-eslint'
npm i 'vue-template-compiler'
# install npm dependencies
npm --prefix web/app install
npm --prefix web/app run build
# build docker image
docker build . -t ${FULL_IMAGE_NAME} # run image in docker
docker run -p 8080:8080 --name gatus gatus:v5.13.1-custom-path
2024/11/26 06:03:04 [watchdog.execute] Monitored group=core; endpoint=front-end; success=false; errors=0; duration=744ms
2024/11/26 06:03:05 [watchdog.execute] Monitored group=core; endpoint=back-end; success=true; errors=0; duration=427ms
2024/11/26 06:03:05 [watchdog.execute] Monitored group=internal; endpoint=monitoring; success=true; errors=0; duration=336ms
2024/11/26 06:03:06 [watchdog.execute] Monitored group=internal; endpoint=nas; success=true; errors=0; duration=454ms
2024/11/26 06:03:07 [watchdog.execute] Monitored group=; endpoint=example-dns-query; success=true; errors=0; duration=95ms
2024/11/26 06:03:07 [watchdog.execute] Monitored group=; endpoint=icmp-ping; success=false; errors=0; duration=0s
2024/11/26 06:03:09 [watchdog.execute] Monitored group=; endpoint=check-domain-expiration; success=true; errors=0; duration=365ms
2024/11/26 06:03:14 [api.ErrorHandler] Cannot GET /healthcheck/js/chunk-vendors.js
2024/11/26 06:03:14 [api.ErrorHandler] Cannot GET /healthcheck/js/app.js
2024/11/26 06:03:14 [api.ErrorHandler] Cannot GET /healthcheck/css/app.css
2024/11/26 06:03:21 [api.ErrorHandler] Cannot GET /healthcheck
2024/11/26 06:03:37 [api.ErrorHandler] Cannot GET /healthcheck
2024/11/26 06:03:45 [api.ErrorHandler] Cannot GET /healthcheck # curl request
❯ curl -i localhost:8080/healthcheck
HTTP/1.1 404 Not Found
Date: Tue, 26 Nov 2024 06:03:45 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 23
Cannot GET /healthcheck Still getting 404 on /healthcheck. I am using the dockerfile that comes with the repo. I think this is where the issue is. After you build the front-end, how do you ensure that build ends up in the image? |
note that app is still served on the for image i just use custom Dockerfile (e.g. https://github.com/akozlins/server/blob/master/gatus/Dockerfile) |
@akozlins thanks a lot. Works like a charm after adding |
At a1679dd,
web.context-root
is deleted.But this option is needed in the environment which the URL can not be rewritten, for example Amazon ALB ingress controller.
Would you please revive it?
The text was updated successfully, but these errors were encountered: