Skip to content
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

Enable use of subpath rather than domains for sites #707

Open
lpil opened this issue Nov 15, 2023 · 2 comments
Open

Enable use of subpath rather than domains for sites #707

lpil opened this issue Nov 15, 2023 · 2 comments

Comments

@lpil
Copy link

lpil commented Nov 15, 2023

Hello! Thank you again for goatcounter.

We wish to track multiple sites, but due to infrastructure limitations it is impractical for us to point a new domain name at the goatcounter instance per tracked site.

It would be fantastic if it were possible to use a subpath rather than a domain per site.

site name in database domain (current) sub path (proposed alternative)
one.example.com https://one.example.com/ 0.0.0.0/sites/one.example.com/
two.example.com https://two.example.com/ 0.0.0.0/sites/two.example.com/

One issue with this design is that goatcounter would need to know what the actual domain is in order to provision TLS certs, as it can't just make one per site now. Perhaps this could be mandatory configuration to enable this new routing behaviour. This is not an issue for us specifically as we use a reverse proxy which terminates TLS before it reaches goatcounter.

Thanks,
Louis

@arp242
Copy link
Owner

arp242 commented Dec 8, 2023

One issue with this design is that goatcounter would need to know what the actual domain is in order to provision TLS certs, as it can't just make one per site now.

Another problem are cookies; if you login on sites/one it will override the login cookie for sites/two. It's not a deal-breaker (you just need to re-login), but not great either.

Also redirects: will need to do "$root/path" instead of just "/path".

To be honest I'm a bit hesitant to change it, because it's quite a lot of work, not really complex work but lots of little things, and also fairly finicky and something I can foresee breaking (not something that's super-easy to test either), and you're the second person to ask for this (the first was just for "aesthetic reasons" rather than any practical issue).

I'm not entirely sure what the best solution would be for your use-case – maybe rewriting the paths with a proxy (Varnish, nginx, whatever) might be the best path forward? You can create sites as site1.localhost, site2.localhost, etc. and then proxy to that (that's also how I do local development, via e.g. http://arp242.goatcounter.localhost:8081).

Would that work?

@lpil
Copy link
Author

lpil commented Dec 8, 2023

Unfortunately it's not practical with our infrastructure limitations. Thank you nevertheless!

Do not consider this urgent. We can tolerate prefixing all the paths with the hostname. It's ugly but workable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants