Add ability to route relative to the current URL / browser location API

[daniel-simpson]

Is your feature request related to a problem? Please describe. I serve homer dashboard on my home server. I usually open it by IP address (e.g. 192.168.1.119), but if I'm outside my network I use tailscale and it's resolution to grab my dashboard (e.g. http://nuc/).

I host multiple other services on this machine on different ports, and would like a way to have homer resolve links relative to my current URL (either http://192.168.1.119 or http://nuc).

Describe the solution you'd like A concise template for generic services that allows some or all of the url property to be parameterised, e.g.:

- name: "Relative URL example"
  icon: fa-explosion
  subtitle: A link hosted on the same server as Homer, but with more than one possible hostname
  url: "//${hostname}:8080

Describe alternatives you've considered PR incoming, happy to make adjustments or discuss further.

Additional context N/A

[zsimple]

To be honest, I'm quite surprised that Homer has already developed to this level, yet still lacks this functionality.

I need this feature too, beside using home DNS, currently I use blow code to get it work.

- name: "Some App"
  url: "javascript:open(`//${location.hostname}:9090/`);"
  #target: "_blank" # target must not used here

This works, but it's rather inelegant, hope this feature can be used soon.

[dacagi]

To be honest, I'm quite surprised that Homer has already developed to this level, yet still lacks this functionality.

I need this feature too, beside using home DNS, currently I use blow code to get it work.

- name: "Some App"
  url: "javascript:open(`//${location.hostname}:9090/`);"
  #target: "_blank" # target must not used here

This works, but it's rather inelegant, hope this feature can be used soon.

This solution didn't quite work for me when used inside the links list instead of the services. Or maybe it's Firefox idk. It loads the new url but on another page, and the current page shows an empty screen except the text "[object Window]".

I managed to find this though which does work, reloading the url on the current page.

links:
  - name: "TS"
    icon: "fas fa-table-cells"
    url: "javascript:window.location.port=8081"

I'm also working in a solution to allow me to have separate addresses, tailscale, lan and domain name too. So far I'm using 3 separate instances with the same configs but replacing URLs. But this, together with additional pages, should allow to have like 3 equal tabs just pointing to different ports/urls.

Thanks for the great idea!!

[zsimple]

Oh sorry, I've been using Chrome without any issues, and I haven't tested it in all browsers. It seems to be some problems in Firefox.

Your approach is also really good, it replace the current url. But if someone still wants to open the service in a new tab, try the following method:

links:
  - name: "TS"
    icon: "fas fa-table-cells"
    url: "javascript:void(window.open(`//${location.hostname}:8081/`))"

It seem works well in both Chrome and Firefox, hope it can help someone.

[dacagi]

No prob. I guess nobody uses Firefox anymore. It's chromium everywhere. Yes I can confirm your proposal works fine on all of my browsers. Just wanted to note it makes indeed more sense to open in new tabs for the service links. In my case I was trying to simulate having tabs using the links menu, that's why I chose to keep on the same page, and switch the whole config instead (not all of my services are reachable from all networks).

Anyway, this would help resolve to the same server and port with different IP addresses (LAN and TS for example), but I couldn't find a solution to integrate DNS resolution with a reverse proxy in the middle.

My current approach is 3 Homer instances: 8080 has Tailscale IPs, 8081 LAN addresses, and 8082 domain names (no ports, but subdomains served by SWAG). I use docker-gen (amazing tool I can only recommend) to create the variable configs based on a template, and I pass the corresponding URLs via compose labels on each service. (Homer autodiscovery!)

Those 3 ports are then published with a reverse proxy under subdirs of my domain (homer.domain.com/lan for example), and I use the links to quickly switch the current page view (homer.domain.com/ts or homer.domain.com/dom). Since the configs are exactly the same it almost looks it's a single app.

I may publish my setup for reference if anyone's interested. It's basically a docker compose, a bash script and a couple of config files.

As a side note, I had to ditch the idea of using additional_pages.yml because the hash and the search param weren't playing nicely together with the proxy redirections.

[Tropfchen]

@dacagi maybe better solution for you would be to just use split horizon DNS - this way for example you can have domain pointing to local network ip address, but devices in 100.0.0.0/8 range will instead receive tailscale ip address of server.

Nonetheless I agree, would be nice to see relative links, or at least mention of this JS 'trick' somewhere in documentation or example file.

[dacagi]

@dacagi maybe better solution for you would be to just use split horizon DNS

I'm not sure I understand your solution, I have impostor syndrome

I'm using AdguardHome internally (so not publicly available) and already have DNS rewrites for my LAN clients to resolve LAN IPs for my domain. Public services I publish via Cloudflare tunnels so my public IP remains hidden and no ports open.

My understanding is that Tailscale uses its own DNS resolvers. I tried playing with custom DNS servers but I couldn't make it work for me (not remember why anymore). I even thought about routing everything through TS IPs since they seem to keep the traffic inside my LAN, but not all my client devices have Tailscale installed and running every time (I can't run Tailscale + Proton on my Android for example and its DNS resolution forces Google's 8.8.8.8 while on mobile).

That's why I sort of ended up in this strange situation having to keep track of 3 different access ways. It's quite a pain when I move services around hosts. So yeah I'm all ears for viable solutions to this mess. Thank you a lot for the suggestion. This means I have something new to study