Logo image tries to load from localhost even on remote machine #1401

New Issue

OVERLORD · 2026-02-05T00:47:50+03:00

OVERLORD commented

2026-02-05 00:47:50 +03:00

Originally created by @AaronBeaudoin on GitHub (Oct 10, 2019).

Describe the bug
If I set the logo to a custom image and save the changes, I can only see the custom logo when viewing BookStack from the local machine (navigating to localhost). On a remote machine on the local network the GET request for the image fails because the URL in the <img> tag is still using http://localhost.

Steps To Reproduce
Steps to reproduce the behavior:

Change the BookStack logo on a fresh install to some custom image
Go to BookStack on a another machine using the BookStack machine's IP address and port number
The logo doesn't load because the <img> tag src attribute starts with http://localhost and of course since we are on a remote machine this doesn't work
Try copying the URL into the browser and changing localhost to the correct IP address and port and verify that the image can still be accessed as expected... it should work fine

Expected behavior
The logo shows up no matter where the page is loaded from. The src attribute of the <img> tag containing the logo should start with something like http://<ip-address> like every other URL on the page. Even the parent <a> element with the logo class just outside the logo <img> tag has its src attribute correctly set to the IP address of the BookStack machine.

Screenshots

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): v0.27.4
PHP Version: 7.2.22
Hosting Method (Nginx/Apache/Docker): Docker on Windows, Linux Containers

Additional context
Of course when viewing the page from the same machine as the server is running on there is no issue because http://localhost will have no issue resolving.

Originally created by @AaronBeaudoin on GitHub (Oct 10, 2019). **Describe the bug** If I set the logo to a custom image and save the changes, I can only see the custom logo when viewing BookStack from the local machine (navigating to `localhost`). On a remote machine on the local network the GET request for the image fails because the URL in the `<img>` tag is still using `http://localhost`. **Steps To Reproduce** Steps to reproduce the behavior: 1. Change the BookStack logo on a fresh install to some custom image 2. Go to BookStack on a another machine using the BookStack machine's IP address and port number 3. The logo doesn't load because the `<img>` tag `src` attribute starts with `http://localhost` and of course since we are on a remote machine this doesn't work 4. Try copying the URL into the browser and changing `localhost` to the correct IP address and port and verify that the image can still be accessed as expected... it should work fine **Expected behavior** The logo shows up no matter where the page is loaded from. The `src` attribute of the `<img>` tag containing the logo should start with something like `http://<ip-address>` like every other URL on the page. Even the parent `<a>` element with the `logo` class just outside the logo `<img>` tag has its `src` attribute correctly set to the IP address of the BookStack machine. **Screenshots** ![logo](https://user-images.githubusercontent.com/26592486/66605463-c593a780-eb75-11e9-823c-366b09a4aace.png) ![logo-dev](https://user-images.githubusercontent.com/26592486/66605467-c7f60180-eb75-11e9-938d-9358afe36164.png) **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): v0.27.4 - PHP Version: 7.2.22 - Hosting Method (Nginx/Apache/Docker): Docker on Windows, Linux Containers **Additional context** Of course when viewing the page from the same machine as the server is running on there is no issue because `http://localhost` will have no issue resolving.

OVERLORD closed this issue

2026-02-05 00:47:54 +03:00

OVERLORD commented

2026-02-05 00:47:58 +03:00

@AaronBeaudoin commented on GitHub (Oct 11, 2019):

Ok so I've just discovered that if I set the logo image from the other machine then everything works fine because the src attribute URL then correctly has the IP address in it. Interestingly, the IP address also shows up in the src attribute URL when the page is viewed from localhost on the local BookStack machine too.

So it seems the first part of the URL is not dynamically changing based on where the page is viewed from like all the other links on the page. I dug through the source code a little bit and although I'm not familiar with PHP it seems that the problem is likely in SettingController.php on line 70 where the image URL is saved to the app-logo setting with setting()->put('app-logo', $image->url);.

I'm not sure how to confirm this, but I suspect that the value saved to the app-logo setting is something like http://<ip-address>/uploads/images/system/2019-10/logo.png rather than simply /uploads/images/system/2019-10/logo.png.

I'll bet that in header.blade.php when url(setting('app-logo', '')) is run the url function does nothing because the value of app-logo is already a complete URL.

@AaronBeaudoin commented on GitHub (Oct 11, 2019): Ok so I've just discovered that if I set the logo image from the other machine then everything works fine because the `src` attribute URL then correctly has the IP address in it. Interestingly, the IP address also shows up in the `src` attribute URL when the page is viewed from `localhost` on the local BookStack machine too. So it seems the first part of the URL is not dynamically changing based on where the page is viewed from like all the other links on the page. I dug through the source code a little bit and although I'm not familiar with PHP it seems that the problem is likely in `SettingController.php` on line 70 where the image URL is saved to the `app-logo` setting with `setting()->put('app-logo', $image->url);`. I'm not sure how to confirm this, but I suspect that the value saved to the `app-logo` setting is something like `http://<ip-address>/uploads/images/system/2019-10/logo.png` rather than simply `/uploads/images/system/2019-10/logo.png`. I'll bet that in `header.blade.php` when `url(setting('app-logo', ''))` is run the `url` function does nothing because the value of `app-logo` is already a complete URL.

OVERLORD commented

2026-02-05 00:48:01 +03:00

@AaronBeaudoin commented on GitHub (Oct 11, 2019):

Ok so it seems that changing line 70 in SettingController.php from this...

setting()->put('app-logo', $image->url);

...to this fixes the problem.

setting()->put('app-logo', parse_url($image->url)['path']);

Any comment on whether or not I'm doing the correct thing here?

@AaronBeaudoin commented on GitHub (Oct 11, 2019): Ok so it seems that changing line 70 in `SettingController.php` from this... ```php setting()->put('app-logo', $image->url); ``` ...to this fixes the problem. ```php setting()->put('app-logo', parse_url($image->url)['path']); ``` Any comment on whether or not I'm doing the correct thing here?

OVERLORD commented

2026-02-05 00:48:05 +03:00

@cnfw commented on GitHub (Oct 11, 2019):

Hi there, you mentioned that you're hosting with Docker. Do you have a proxy in front of the container that is forwarding requests to it?

If so, you may need to tell BookStack which URL is actually used to access it (rather than what it sees in the request)

Check out this line in your configuration to see if it applies to you: https://github.com/BookStackApp/BookStack/blob/master/.env.example#L11

You may also be able to configure your proxy to forward the headers "as-is" in the original request from your browser. However, the APP_URL configuration would be the more straightforward fix of these two.

One gotcha to watch out for is that this will only apply to newly uploaded images. I keep stumbling across pages with references to images that were uploaded when my BookStack instance was accessed with a different URL, and just needs manually updated.

@cnfw commented on GitHub (Oct 11, 2019): Hi there, you mentioned that you're hosting with Docker. Do you have a proxy in front of the container that is forwarding requests to it? If so, you may need to tell BookStack which URL is actually used to access it (rather than what it sees in the request) Check out this line in your configuration to see if it applies to you: https://github.com/BookStackApp/BookStack/blob/master/.env.example#L11 You may also be able to configure your proxy to forward the headers "as-is" in the original request from your browser. However, the `APP_URL` configuration would be the more straightforward fix of these two. One gotcha to watch out for is that this will only apply to newly uploaded images. I keep stumbling across pages with references to images that were uploaded when my BookStack instance was accessed with a different URL, and just needs manually updated.

OVERLORD commented

2026-02-05 00:48:07 +03:00

@AaronBeaudoin commented on GitHub (Oct 11, 2019):

I am not using any proxies whatsoever. The Docker container is simply run with the -p 80:80 argument to bind to port 80 on the host and make the web server accessible anywhere the host is accessible.

As you can see in my previous comments, I believe the issue is that the logo image is incorrectly saved to the application settings as a full URL instead of just a path.

It seems anywhere that URLs need to appear in the application's views a url() function is run to resolve paths to full URLs. Since the logo image is currently saved as a full URL already, this function will do nothing when passed the logo image URL. If this URL is not accessible from whatever machine you're viewing BookStack from then the request will fail.

So the issue is like this (I think):

Suppose I upload an logo and save my changes while logged in from a web browser on localhost.
Now the app-logo setting is something like http://localhost/uploads/images/system/2019-10/logo.png.
Suppose the IP address of the BookStack server is 10.0.0.5 and I login to it from another machine by going to http://10.0.0.5 in the other machine's web browser. The logo request fails because on this other machine the URL http://localhost/uploads/images/system/2019-10/logo.png is meaningless. From this other machine the URL should be http://10.0.0.5/uploads/images/system/2019-10/logo.png.

Hopefully that makes sense.

@AaronBeaudoin commented on GitHub (Oct 11, 2019): I am not using any proxies whatsoever. The Docker container is simply run with the `-p 80:80` argument to bind to port 80 on the host and make the web server accessible anywhere the host is accessible. As you can see in my previous comments, I believe the issue is that the logo image is incorrectly saved to the application settings as a full URL instead of just a path. It seems anywhere that URLs need to appear in the application's views a `url()` function is run to resolve paths to full URLs. Since the logo image is currently saved as a full URL already, this function will do nothing when passed the logo image URL. If this URL is not accessible from whatever machine you're viewing BookStack from then the request will fail. So the issue is like this (I think): 1. Suppose I upload an logo and save my changes while logged in from a web browser on `localhost`. 2. Now the `app-logo` setting is something like `http://localhost/uploads/images/system/2019-10/logo.png`. 2. Suppose the IP address of the BookStack server is `10.0.0.5` and I login to it from another machine by going to `http://10.0.0.5` in the other machine's web browser. The logo request fails because on this other machine the URL `http://localhost/uploads/images/system/2019-10/logo.png` is meaningless. From this other machine the URL should be `http://10.0.0.5/uploads/images/system/2019-10/logo.png`. Hopefully that makes sense.

OVERLORD commented

2026-02-05 00:48:16 +03:00

@cnfw commented on GitHub (Oct 11, 2019):

Thanks for clarifying. I have seen this behaviour before with regular images, but not the logo which is why I suggested the config check. I've done a couple of tests with my own instance, and here are my findings:

Uploading a logo with APP_URL set uses that URL, even when accessing the site with another URL.
Uploading a logo with one URL, then changing APP_URL does not affect the logo URL.
The default logo uses APP_URL no matter what URL you actually access the site from. This is correct behaviour.

So I can reproduce the issue you're facing with custom logos. One for @ssddanbrown to triage as a potential bug?

@cnfw commented on GitHub (Oct 11, 2019): Thanks for clarifying. I have seen this behaviour before with regular images, but not the logo which is why I suggested the config check. I've done a couple of tests with my own instance, and here are my findings: 1. Uploading a logo with `APP_URL` set uses that URL, even when accessing the site with another URL. 2. Uploading a logo with one URL, then changing `APP_URL` does not affect the logo URL. 3. The default logo uses `APP_URL` no matter what URL you actually access the site from. This is correct behaviour. So I can reproduce the issue you're facing with custom logos. One for @ssddanbrown to triage as a potential bug?

OVERLORD commented

2026-02-05 00:48:20 +03:00

@ssddanbrown commented on GitHub (Oct 11, 2019):

Thanks for trying to assist here @cw1998.

The fundamental thing is that BookStack does not support being access via multiple base URLs. The app logo won't be the only thing that you'll have issues with if you're not using a fixed base URL via setting APP_URL. Issue #1342 exists as a request to allow a relative base.

@ssddanbrown commented on GitHub (Oct 11, 2019): Thanks for trying to assist here @cw1998. The fundamental thing is that BookStack does not support being access via multiple base URLs. The app logo won't be the only thing that you'll have issues with if you're not using a fixed base URL via setting `APP_URL`. Issue #1342 exists as a request to allow a relative base.

OVERLORD commented

2026-02-05 00:48:22 +03:00

@ssddanbrown commented on GitHub (Apr 8, 2020):

Since the last comment on this issue is relatively old I'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one.

@ssddanbrown commented on GitHub (Apr 8, 2020): Since the last comment on this issue is relatively old I'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1401