Bookstack: Use relative paths rather than absolute

[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.