Base URL about homarr HOT 25 OPEN

@ajnart Not sure which part you are looking for more explanation, but below is my docker-compose for ddnsupdater. You can see there is an environment variable for ROOT_URL that tells the application where the root/base of the webserver is going to be hosted. When the container starts, you go to that URL for the app's homepage. So in this instance, I go to http://localhost:8103/ddns-updater. If I remove that variable, the app's homepage will be hosted at http://localhost:8103.

 ddns-updater:
    <<: *logging
    hostname: ddns-updater
    image: qmcgaw/ddns-updater:latest
    container_name: ddns-updater
    restart: always
    environment:
     - TZ=${TZ}
     - PERIOD=60m
     - UPDATE_COOLDOWN_PERIOD=60m
     - ROOT_URL=/ddns-updater/
     - LOG_LEVEL=debug
     - LOG_CALLER=short
     ports:
    - "8103:8000"
    volumes:
     - "${docker}/ddns-updater:/updater/data/"
    labels:
     - caddy= "${FQDN}"
     - caddy.handle= "@auth"
     - caddy.handle.route= "/ddns-updater*"
     - caddy.handle.route.authorize= with mypolicy
     - caddy.handle.route.reverse_proxy= 192.168.1.104:8103
     - plugsy.name=Ddns-updater
     - plugsy.category=Sys Utils
     - plugsy.link=http://osu.ddns-updater:8103/ddns-updater/
     - plugsy.icon=https://raw.githubusercontent.com/qdm12/ddns-updater/master/readme/ddnsgopher.svg
    user: 1000:1000

from homarr.

Another reason I use subfolders/base_url over subdomain is managing a significant less amount of SSL Certs. I don't use wildcards so managing DNS entries (as discussed) and all the overhead associated with subdomains. Definitely a big +1 from me

from homarr.

Seems like the current implementation is for a subdomain instead of a subdirectory, I think most people throw services like this up behind a subdirectory since it doesn't require an extra dns entry or anything.

from homarr.

Wildcard SSLs are a thing.

from homarr.

I'm not sure if you actually read my last post to completion. I'm just advocating a case for it. I'm not entitled to demand this from an open-source project (Especially one I've yet to donate to) but since this is a feature request I wanted to post the benefits and how this feature can benefit other labs that are set up

from homarr.

Finally got a chance to try this out. I'm not a dev (especially JS stuff) but I am excited to give it a try. I think I was able to address everywhere else except axios calls so I am looking into that. Hopefully I can pick this up again on Sunday and get a PR out 😄

from homarr.

Maybe I'm missing something, but the attack surfaces are the exposed ports on your server/Docker daemon. I fail to see how multiple published DNS records that point to the same IP address would raise any risks over a single record. In my experience, bots/hackers looking for exploits rarely bother with domain names anyhow. That would just waste resources sending multiple redundant requests to the same servers. It's far more likely they pick off an IP address and run a port scan before moving on to another IP address. Who cares if there are multiple published subdomains pointing to it?

Even still, if you just want to limit the number of DNS records you're dealing with, you can just use a single wildcard for the A/AAAA, ie--"*.domain.tld", and then use as many subdomains as you want. This is how many PaaS such as Caprover are configured.

from homarr.

Is this function still not implemented? I have configured BASE_URL in the Docker, but it seems to have no effect

from homarr.

I've moved the Priority over to Medium (Would be very useful), as this is not an App Breaking feature.

from homarr.

@samcro1967 Could you elaborate on how this would be implemented in a docker container? A docker container can't just connect with your domain, right?

from homarr.

From a container (and internal perspective) it would be http://ip:port/base_url. All of the arr's (and most of the apps I run) support this today. Some apps it is defined inside the application itself. After it spun up, you configure it in the settings and then restart the app. Many others it is an environment variable on the container so it starts at that base_url on first start. Makes reverse proxy so much easier with subdirectories.

from homarr.

What benefit does a subdirectory give if you have to use IP:port anyways?

from homarr.

You can access like website.com/sonarr or sonarr.website.com to access sonarr ? That's pretty cool. I don't know this much about reverse proxys and how the web works in general tbh, just wanted to make a solution that worked for me x)

You'll have to explain it to me with explaining the terms because I've had to look up like 3 terms in your answers and still don't understand

from homarr.

@walkxcode You can also use a hostname or DNS alias or localhost if it is on the same machine. It does not have to be an IP address. In a reverse proxy, you are going to specify a host externally at https://mydomain.net/base_url or internally http://local.dashboard that points to http://IP:port/base_url.

Externally it improves your security posture (one less DNS name listed for folks to target with exploits) and internally gives users a friendly name to remember. They no longer have to remember the port.

from homarr.

That's interesting.

from homarr.

@Philipose @samcro1967 Thank you both for the explanations 👍🏼 I'll take a look at it and check how hard is it to implement in NextJS . Just not at the moment.
If you could do some research and tell me a way to do it / make a PR that includes it, that would be awesome ! Or just links talking about the subject would help me out a lot.

from homarr.

Unfortunately I am not a developer, but maybe these links will help:

Base Path
NextJS deploy to a specific URL path

Here is a NextJS app that has a base URl built in.
Peppermint

from homarr.

I just looked up Peppermint @samcro1967 thanks for the link. Looking at https://github.com/Peppermint-Lab/peppermint/search?q=BASE_URL
shows me that there is no code that (at least the code I understand) that specifically sets the base url, I believe nextjs handles it with environment variables. Can you test it with env variables with the Docker image/ Directly with a local install.

The problem might be that the docker image is compiled without the ENV variable

from homarr.

@samcro1967 @Philipose I just tested and it looks like all the base URL work somehow ?

anything.localhost:757 worked somehow, maybe you can try it like that For urls like localhost:7575/homarr it needs more love. (see below)
Also I made it so the PORT env variable works now

Peppermint dev says BASE_URL doesn't work on his end either

Implementing BASE_URL would require more time than I want to.
You need to :

• set the BASE_URL as a constant in the App.getInitialProps in src/pages/_app.tsx
• use that value everywhere where the BASE_URL is used (API requests like /api/configs/ and every where local assets are used (imgs/logo.png)
• also add this:

module.exports = {
  basePath: '/docs',
}

To the next.config.js

Example change :

<link rel="shortcut icon" href={"\favicon.svg"} />

To:

<link rel="shortcut icon" href={`${BASE_URL}/favicon.svg`} />

If you have time to do it, I shouldn't be too hard to do it in every file and then send me a PR to integrate it, i'll review and merge asap 👍🏼

from homarr.

This has been partially added in https://github.com/ajnart/homarr/releases/tag/v0.5.0!

from homarr.

Subpath support would be wonderful
I'm not able to run it under my subdomain/subpath, sub URL (example.com/homarr), because other apps run in subpaths

from homarr.

If anyone has info on how to use a subpath in NextJS I would be interested to read on it to implement this issue.

from homarr.

I saw other applications doing it with a "basePath" variable

from homarr.

I saw other applications doing it with a "basePath" variable

It's not because they use this name as a convention that I can just install some basePath npm package and make it work sadly 🤣
as far as I've researched there is no painless way to integrate this feature in nextjs at the moment. If anyone finds resources to tell me otherwise I'd be happy to read it and change what needs to be changed

from homarr.

What benefit does a subdirectory give if you have to use IP:port anyways?

in my use case i'm using traefik to expose services on both local network (through mdns) and on internet.
primary use would be organization of services (i have something like admin.*.[com|local] for administration services, media.* for all the *arr applications and so on.

while still setting some stuff up from zero, on mdns i have some issues with subdomains (as in: can't make them work), and if i set homarr on the root dns of the server (so, say, server.local) as it is implemented that blocks me on going on any other service that use a subdirectory, say server.local/radarr as traefik naturally routes to the homarr service and that tries to read radarr as a configuration file, returning me a 404.

The ideal configuration would be server.local/dashboard or /home or whatever - with an optional redirect from the root, but that's on the proxy configuration side, not homarr's - pointing to the dashboard where you can actually reach all the other services.

from homarr.