Use relative paths rather than absolute / Support mulitple base URLs or domains

[Amolith]

Describe the bug It would be better to use relative paths than absolute. This issue is different from #1137 because I'm saying that everything should be relative rather than hardcoded. I'm trying to serve my BookStack instance over Tor and, even though it's served fine over the initial onion URL, every single link on the first page is to the clearnet site. I can manually enter the path to the onion URL and it works fine so it's simply an issue of hardcoded URLs vs relative.

Steps To Reproduce

1. Open Tor
2. Paste wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion
3. Mouse over some of the links and see the target URL
4. Paste wiki.l4qlywnpwqsluw65ts7md3khrivpirse744un3x7mlskqauz5pyuzgqd.onion/books/masto-tweaks/
5. See that it works fine but all the links on that page are hardcoded as well

Expected behavior

• Links from the onion URL go to an onion URL
• Links from a clearnet URL go to a clearnet URL

Screenshots

Your Configuration (please complete the following information):

• Exact BookStack Version (Found in settings): v0.25.1
• PHP Version: 7.3.3
• NGINX

[ssddanbrown]

Thanks for the request.

This is related to #1310 and #1275 and #1137

[recklessnl]

@ssddanbrown Has there been any progress on this issue yet? Still really annoying not being able to access local data on a local server if your internet goes out, without restarting the whole bookstack instance and messing with the local config files.

[AlphaJack]

So far BookStack is the only app in my selfhosted server that I can't access from my LAN IP. To access I'm forced to:

• use the public IP with Tor Browser, because APP_URL=https://example.com/wiki
• modify the .env file setting APP_URL=http:/192.168.1.13/wiki, making the app inaccessible from the outside It would be great to set APP_URL=/wiki/ to get it working on both the external and the internal IPs, but if I set so it redirects me to http:/192.168.1.13/wiki/wiki/wiki or https://example.com/wiki/wiki/wiki

[recklessnl]

Same here - Bookstack is only app that is not modern enough to be able to handle this. Ideally you could just reverse proxy it without messing with APP_URL settings and just let it live locally in order to work with a reverse proxy. Every other app I have tested work fine with a reverse proxy, except this one.

[AlphaJack]

I thought I got it working by setting

APP_URL=.

in the .env file. URL would look like

href="./dist/styles.css?version=v0.27.4"
src="./logo.png"
action="./search"

and will resolve for every host, being it a LAN IP or a registered domain. The point is, it only works for /wiki/ (my location) /wiki/shelves /wiki/books /wiki/register /wiki/login (it works)

Going to /wiki/books/bookname or /wiki/user/n° will result in errors regarding the javascript files

---

I decided to try this after seeing that all the URLs in the "relative-urls" branch of IrosTheBeggar/mStream were starting with a dot (only this branch makes mStream also work in /locations/ and not only subdomains. )

[recklessnl]

So is the above workaround by @AlphaJack suffice or is an actual fix coming for this @ssddanbrown? It's odd that bookstack still doesn't support both local IPs and domain names, I can't think of another selfhosted app that doesn't support it other than bookstack.

[recklessnl]

pinging @ssddanbrown - major feature request that hopefully is already in the works.

[ssddanbrown]

The way I see it: The actual goal/feature being request here is "Have the ability to host a single BookStack instance at multiple base URLs". Relative paths is just an implementation idea for that feature/goal.

I've found myself grow further against the idea of having relative or dynamic URLs due to the edge-cases or complexities they'd introduce. I'd be happy to explore other potential avenues depending on their level of interruption relative to the rest of the codebase & their maintenance cost.

I've just spent a few hours seeing if this can be done via nginx. You can achieve almost fully-functional support by setting up a proxy for the secondary base URL, leading to the primary, which uses sub_filter and proxy_redirect to rewrite the urls for the most part. Unfortunately there are content issues when updating page content, since the POST body won't be re-written. Probably possible but quickly gets complicated due to body encoding and regex, tried but gave up on that route. Here's an example config I used, might be useful if your secondary base domain can be a read-only setup:

(My primary domain was http://bookstack.local and the secondary was http://bookstack.local:88 )

server {
	listen 88;
	server_name bookstack.local;

	location / {
     	  sub_filter_once off;
	  sub_filter_types *;
	  sub_filter "http://bookstack.local" "http://bookstack.local:88";
	  proxy_redirect http://bookstack.local http://bookstack.local:88;
	  proxy_pass http://bookstack.local;
	}

}

---

@recklessnl For your specific setup, if you're intending to access that local instance from a single computer, you could just fix the DNS record to point locally. Alternatively, if you self-host/manage the DNS for local network you could add a rule there.

[disconsented]

I've found myself grow further against the idea of having relative or dynamic URLs due to the edge-cases or complexities they'd introduce.

Would you be able to give some examples of this? I was under the impression that relative URLs are generally safe and are considered best practice.

[Deicid]

I have the exact same problem. I'm surprised the developer couldn't fix it in two years. It's the best product I've seen, but it's very hard to use without local access.

[gagnieremaxime]

Hi, i had the same problem but i fixed it by running the bookstack container 2 times while connecting to the same db and the same config directory. Here is my docker-compose.yml file:

---
version: "2"
services:
  bookstack:
    image: ghcr.io/linuxserver/bookstack
    container_name: bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=http://192.168.2.99:6876
      - DB_HOST=bookstack_db
      - DB_USER=bookstack
      - DB_PASS=<dbPassword>
      - DB_DATABASE=bookstackapp
    volumes:
      - /home/<username>/docker/apps/bookstack/config:/config
    ports:
      - 6876:80
    restart: unless-stopped
    depends_on:
      - bookstack_db
  bookstack_remote:
    image: ghcr.io/linuxserver/bookstack
    container_name: bookstack_remote
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=https://bookstack.mydomain.com
      - DB_HOST=bookstack_db
      - DB_USER=bookstack
      - DB_PASS=<dbPassword>
      - DB_DATABASE=bookstackapp
    volumes:
      - /home/<username>/docker/apps/bookstack/config:/config
    ports:
      - 6875:80
    restart: unless-stopped
    depends_on:
      - bookstack_db

  bookstack_db:
    image: ghcr.io/linuxserver/mariadb
    container_name: bookstack_db
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=<dbPassword>
      - TZ=America/Toronto
      - MYSQL_DATABASE=bookstackapp
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=<dbPassword>
    volumes:
      - /home/<username>/docker/apps/bookstack/db/config:/config
    restart: unless-stopped

[Deicid]

@gagnieremaxime Thank you for your message! I set up a connection of two instances to the same database and I had problems with the pictures, their paths are broken. And the images downloaded from the local copy of Bookstack were not displayed in the external access (public version). I don't know how this can be overcome

[gagnieremaxime]

@Deicid it seems to work for me, could you show me your docker-compose.yml file?

[ssddanbrown]

Just to confirm @gagnieremaxime, @Deicid is correct that there will be issues with content; At least where one URL cannot be accessed when using the other. It could work for some cases (Where one host is used read-only and has access to the other) but for most cases you'll end up with a mix of URLs used in content.

[gagnieremaxime]

@ssddanbrown I had that happen on my first try, but right now I can access bookstack both at my domain and the local IP. Both can connect and upload images.

[ssddanbrown]

@gagnieremaxime Sure, but it's not a matter of container configuration; It's a matter of networking. It's not a solution for everyone (An image upload & use via local only IP address will likely break upon page view from outside the local network).

[gagnieremaxime]

@ssddanbrown You are right, I was looking at the books background to verify if upload was working, but in the page itself uploading an image kind of break it... Thank you for explaining

[jorfigfl]

Hi! any update about this? We have the same issue, We have an internal domain for internal users (bookstack.domain1.com), and we are looking for an external url(bookname.domain2.net or domain2.net/doc/) to display the public documents only. Exist any solution or workaround?

[ssddanbrown]

@jorfigfl No update, BookStack still only supports a being hosted on a single domain. You could look to use the export functions and/or API to create an external site from your public content.

[disconsented]

For anyone who's handy with SQL, you can work around this by rewriting the URLs in the database to remove the domain.

[reytechsam]

anyone who's handy with SQL, you can work around this by rewriting the URLs in the database to remove the domain.

Would this work if we rewrite all the database url's? Has someone tried this before? We have the same issue unfortunately.

[reytechsam]

Okay, I think we got it working for our case: Just edited nano /var/www/wiki/app/Config/app.php

and replaced this line : 'url' => env('APP_URL', '') === 'http://bookstack.dev' ? '' : env('APP_URL', ''),

with this one: 'url' => "https://" . $_SERVER['SERVER_NAME'] . "/wiki",

Note, it will brake with the next update, so keep a wiki with all your changes you made

[ssddanbrown]

Just to confirm, the above methods are not supported and can cause issues during updates. My comment here applies to the above, in that this will falter in scenarios where the URLs have different availability/access conditions. In addition, the APP_URL is used in more locations than just one file.

[ani-6]

Any update on this issue?