Look forward to adding the new "homarr_" variable.

[JoJenH]

Description

Look forward to adding the new "homarr_" variable.

First of all, I'm sorry for my poor English. If the description is not clear, I can always add it, although it depends on the translation software.

Homarr uses a set of "homarr_" variables like homarr_base to provide external access urls. But I'm looking forward to adding the new "homarr_" variable. In particular homarr_domain[index] and homarr_port.

About homarr_domain[index]

I noticed that the latest PR Use Public Suffix for homarr_domain #2147 tried to change the ability to get domain names.But then it would seem like an infinite number of new variables would need to be defined for multiple domains.
It is recommended to use a list-like approach to get the elements. Using index for different level domain name, like homarr_domain[4] for homarr.myMachine.domain.tld, homarr_domain[2] to get the domain.tld. Or some other way.

About homarr_port

Also, we want to add a homarr_port variable to get the port, which is important in cases where different hostnames or URIs are used to differentiate services on the same port(different ports for internal and external networks).

The desired effect

For

Service	Private	Public
homarr	http://homarr.private.home.excample.com	http://homarr.public.home.excample.com:65080
webapp	http://webapp.private.home.excample.com	http://webapp.public.home.excample.com:65080
homarr	https://homarr.private.home.excample.com	https://homarr.public.home.excample.com:65443
webapp	https://webapp.private.home.excample.com	https://webapp.public.home.excample.com:65443

Can use [homarr_protocol]://webapp.[homarr_domain[4]]:[homarr_port] for all entrypoints. But now I couldn't configure ports 80 and 443 at a public address, so I have to set up multiple dashboards for both internal and external networks, and homarr_domain variables are completely unusable.

Priority

Medium (Would be very useful)

[SeDemal]

Hi, this is a nice idea.
We didn't include the port at first because they usually are personal to a service, but we're not in people's head's so we can't assume. I actually thought multiple time about adding it, then thinking no one would use it.

The only problem I can see with your suggestion, is that there's no easy way of doing it when IP's have to be taken into consideration. (Which is why we're using the tldts dependency in the first place.

[JoJenH]

The only problem I can see with your suggestion, is that there's no easy way of doing it when IP's have to be taken into consideration.

Sorry. I haven't understood it.I don't understand why IP addresses cause difficulties. If you have time to explain it to me, I will try my best to make some suggestions. How about set homarr_ip as another variable?
But in my opinion, developers just need to provide enough datas and interfaces in a secure way, and users will filter out what works best for them.

My English level can only express the basic meaning, can not use honorifics. But thank you very much for your efforts in the development process.

[SeDemal]

It's about how you handle the address. The very basis is that you may use different addresses to access homarr, be it "homarr.domain.tld" or "192.168.0.2:7575". When you need to parse this address, both use dots, so you can't simply parse elements by splitting between the dots.
You need a more advanced and intelligent way of differentiating from the 2, and we use a dependency to handle that, meaning we also get limited by this dependency.
The primary use for this function is for users with multiple ways to access their services, usually depending on being at home or on the go.
If your primary use for it is simply to have a fast way to write your constant unique address, this is actually not the intended purpose of it.

[JoJenH]

It's about how you handle the address. The very basis is that you may use different addresses to access homarr, be it "homarr.domain.tld" or "192.168.0.2:7575". When you need to parse this address, both use dots, so you can't simply parse elements by splitting between the dots.

You need a more advanced and intelligent way of differentiating from the 2, and we use a dependency to handle that, meaning we also get limited by this dependency.

The primary use for this function is for users with multiple ways to access their services, usually depending on being at home or on the go.

If your primary use for it is simply to have a fast way to write your constant unique address, this is actually not the intended purpose of it.

In the example I provided, I use a private address at home and a public address while traveling, but with different ports, which prevents me from using Homarr properly with the existing variable configuration.

[SeDemal]

Yes, that is why I already mentioned that adding the port is a good idea of itself.

The part that I think is harder to implement is the "homarr_domain[x]", because of IPs.

[JoJenH]

Yes, that is why I already mentioned that adding the port is a good idea of itself.

The part that I think is harder to implement is the "homarr_domain[x]", because of IPs.

But this still doesn’t solve the issue of Homarr using different subdomains for other services. Whether it’s an IP or a domain name, returning the data to the user and allowing them to use slicing to get the necessary information might be a good option. Of course, I’m not entirely familiar with JavaScript, so I might be missing something in my considerations.

[manuel-rw]

For future reference, please voice your concern, that are related to PRs, in the PR. Thanks 👍