APP_PROXIES works for Audit Log but does not work for NGinx error.log #2938

New Issue

OVERLORD · 2026-02-05T05:48:15+03:00

OVERLORD commented

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

Originally created by @jducaud on GitHub (Aug 4, 2022).

Describe the Bug

Setting the APP_PROXIES to * allows the Audit Log of BookStack to display the real IP address of the user.

In the security-topic documentation we can see:

An option is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as Fail2Ban.

This option is LOG_FAILED_LOGIN_MESSAGE (set, as advised, to "Failed login for %u").

So one could logically think - as Fail2Ban is only effective if it has access to the IP address of the attacker - that APP_PROXIES and LOG_FAILED_LOGIN_MESSAGE are the perfect combo to track repeated failed login attempts.

That is not the case. The APP_PROXIES option works for Audit Log (as advertized in the BookStack 21.10 release notes), and the LOG_FAILED_LOGIN_MESSAGE option yields a message in the NGinx error.log as expected:

2022/08/03 22:55:12 [error] 226#226: *6 FastCGI sent in stderr: "PHP message: Failed login for john.doe@gmail.com" while reading response header from upstream, client: 172.23.0.1, server: _, request: "POST /login HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "book.myserver.org", referrer: "https://book.myserver.org/login"

But they do not yield an NGinx error message which can be used by Fail2Ban, as 172.23.0.1 is a Docker bridge interface IP address, not the user real address.

Steps to Reproduce

In the docker-compose.yml file, set APP_PROXIES to *
In the docker-compose.yml file, set LOG_FAILED_LOGIN_MESSAGE to "Failed login for %u"
Generate and start your containers (BookStack and MariaDB)
Try to log in with bad credentials into BookStack
Have a look at the NGinx error.log file

Expected Behaviour

Setting both APP_PROXIES and LOG_FAILED_LOGIN_MESSAGE should yield a message with the real IP address of the user in the NGinx error.log file.

We could also imagine that beside the %u variable in the failed login message, there could also be a %i variable for the IP address.

Screenshots or Additional Context

No response

Browser Details

Firefox 103.0 (64-bit) - Windows 11 Home (10.0.22000)

Exact BookStack Version

22.07.1 (LinuxServer.io 22.07.1-ls29)

PHP Version

7.4.26

Hosting Environment

Synology DS218+ DSM 6.2.4-25556 Update 6
DSM NGinx 1.16.1 (https://book.myserver.org -> http://localhost:9580)
DSM Docker 20.10.3: docker-compose.yml:
- services: image: lscr.io/linuxserver/bookstack, ports: 9580:80, networks: bookstack_mariadb
- services: image: lscr.io/linuxserver/mariadb, ports: 3306:3306, networks: bookstack_mariadb
- networks: bookstack_mariadb, driver: bridge

Originally created by @jducaud on GitHub (Aug 4, 2022). ### Describe the Bug Setting the `APP_PROXIES` to `*` allows the `Audit Log` of `BookStack` to display the real IP address of the user. In the [security-topic documentation](https://www.bookstackapp.com/docs/admin/security/) we can see: > An option is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as **Fail2Ban**. This option is `LOG_FAILED_LOGIN_MESSAGE` (set, as advised, to `"Failed login for %u"`). So one could logically think - as `Fail2Ban` is only effective if it has access to the IP address of the attacker - that `APP_PROXIES` and `LOG_FAILED_LOGIN_MESSAGE` are the perfect combo to track repeated failed login attempts. That is not the case. The `APP_PROXIES` option works for `Audit Log` (as advertized in the [BookStack 21.10 release notes](https://www.bookstackapp.com/blog/bookstack-release-v21-10/#ip-address-in-audit-log)), and the `LOG_FAILED_LOGIN_MESSAGE` option yields a message in the `NGinx error.log` as expected: ``` 2022/08/03 22:55:12 [error] 226#226: *6 FastCGI sent in stderr: "PHP message: Failed login for john.doe@gmail.com" while reading response header from upstream, client: 172.23.0.1, server: _, request: "POST /login HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "book.myserver.org", referrer: "https://book.myserver.org/login" ``` But they do not yield an `NGinx` error message which can be used by `Fail2Ban`, as `172.23.0.1` is a `Docker bridge` interface IP address, not the user real address. ### Steps to Reproduce 1. In the `docker-compose.yml` file, set `APP_PROXIES` to `*` 2. In the `docker-compose.yml` file, set `LOG_FAILED_LOGIN_MESSAGE` to `"Failed login for %u"` 3. Generate and start your containers (`BookStack` and `MariaDB`) 4. Try to log in with bad credentials into `BookStack` 5. Have a look at the `NGinx error.log` file ### Expected Behaviour Setting both `APP_PROXIES` and `LOG_FAILED_LOGIN_MESSAGE` should yield a message with the real IP address of the user in the `NGinx error.log` file. We could also imagine that beside the `%u` variable in the failed login message, there could also be a `%i` variable for the IP address. ### Screenshots or Additional Context _No response_ ### Browser Details Firefox 103.0 (64-bit) - Windows 11 Home (10.0.22000) ### Exact BookStack Version 22.07.1 (LinuxServer.io 22.07.1-ls29) ### PHP Version 7.4.26 ### Hosting Environment - Synology DS218+ DSM 6.2.4-25556 Update 6 - DSM NGinx 1.16.1 (https://book.myserver.org -> http://localhost:9580) - DSM Docker 20.10.3: docker-compose.yml: - services: image: lscr.io/linuxserver/bookstack, ports: 9580:80, networks: bookstack_mariadb - services: image: lscr.io/linuxserver/mariadb, ports: 3306:3306, networks: bookstack_mariadb - networks: bookstack_mariadb, driver: bridge

OVERLORD added the 🐛 Bug label 2026-02-05 05:48:15 +03:00

OVERLORD closed this issue

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

OVERLORD commented

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

@ssddanbrown commented on GitHub (Aug 4, 2022):

Hi @jducaud,
I don't want to complicate the LOG_FAILED_LOGIN_MESSAGE system if possible, since it's really a rarely used feature.
I think the fundamental request can be achieved on the nginx side like described here:

https://serverfault.com/questions/896130/possible-to-log-x-forwarded-for-to-nginx-error-log

@ssddanbrown commented on GitHub (Aug 4, 2022): Hi @jducaud, I don't want to complicate the `LOG_FAILED_LOGIN_MESSAGE` system if possible, since it's really a rarely used feature. I think the fundamental request can be achieved on the nginx side like described here: https://serverfault.com/questions/896130/possible-to-log-x-forwarded-for-to-nginx-error-log

OVERLORD commented

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

@jducaud commented on GitHub (Aug 4, 2022):

Hi @ssddanbrown,

Thank you for this link. Luckily, the Nginx version of the LinuxServer.io BookStack container has been built with the ngx_http_realip_module! So I added to the server context of Nginx the following lines:

	set_real_ip_from  10.0.0.0/8;
	set_real_ip_from  172.16.0.0/12;
	set_real_ip_from  192.168.0.0/16;
	real_ip_header    X-Forwarded-For;
	real_ip_recursive on;

And it worked. The Nginx error.log now displays the real user IP address. Thank you very much for your advice.

If I may, I would say that the BookStack documentation I quoted should be fixed. Indeed, in any case, the LOG_FAILED_LOGIN_MESSAGE option is not useful for Fail2Ban. Thanks to the APP_PROXIES option, it could have been useful for Fail2Ban but it is actually not. My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad.

Anyway, you brilliantly saved me. Thank you again!

@jducaud commented on GitHub (Aug 4, 2022): Hi @ssddanbrown, Thank you for this link. Luckily, the `Nginx` version of the `LinuxServer.io BookStack` container has been built with the `ngx_http_realip_module`! So I added to the server context of `Nginx` the following lines: ``` set_real_ip_from 10.0.0.0/8; set_real_ip_from 172.16.0.0/12; set_real_ip_from 192.168.0.0/16; real_ip_header X-Forwarded-For; real_ip_recursive on; ``` And it worked. The `Nginx` error.log now displays the real user IP address. Thank you very much for your advice. If I may, I would say that the `BookStack` documentation I quoted should be fixed. Indeed, in any case, the `LOG_FAILED_LOGIN_MESSAGE` option is not useful for `Fail2Ban`. Thanks to the `APP_PROXIES` option, it could have been useful for `Fail2Ban` but it is actually not. My feeling about this `LOG_FAILED_LOGIN_MESSAGE` option is that it has no real-life use and has missed its original intended purpose. Too bad. Anyway, you brilliantly saved me. Thank you again!

OVERLORD commented

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

@ssddanbrown commented on GitHub (Aug 4, 2022):

Good to know things are working

Thanks to the APP_PROXIES option, it could have been useful for Fail2Ban but it is actually not. My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad.

I don't really understand. What makes you say this? How does it miss the intended purpose?

@ssddanbrown commented on GitHub (Aug 4, 2022): Good to know things are working > Thanks to the APP_PROXIES option, it could have been useful for Fail2Ban but it is actually not. My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad. I don't really understand. What makes you say this? How does it miss the intended purpose?

OVERLORD commented

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

@jducaud commented on GitHub (Aug 4, 2022):

When I say "the LOG_FAILED_LOGIN_MESSAGE option (...) has no real-life use and has missed its original intended purpose", I refer to the BookStack documentation (security topic):

Failed Access Logging: An option (LOG_FAILED_LOGIN_MESSAGE) is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as Fail2Ban.

The original intent - if I read correctly - was to allow the use of tools such as Fail2Ban. Well, the LOG_FAILED_LOGIN_MESSAGE option is useless for tools such as Fail2Ban, as it does not provide a way to get the real IP address of the user/attacker in the logs.

That makes me think this option has only made half of the trip. It yields a message (calling the php error_log function) in the Nginx error.log file but only provides a %u variable, useless to effectively ban an IP address. The other half of the trip has to be done by the elegant workaround you gave me (Nginx real-IP module).

@jducaud commented on GitHub (Aug 4, 2022): When I say "the `LOG_FAILED_LOGIN_MESSAGE` option (...) has no real-life use and has missed its original intended purpose", I refer to the [BookStack documentation](https://www.bookstackapp.com/docs/admin/security/) (security topic): > Failed Access Logging: An option (`LOG_FAILED_LOGIN_MESSAGE`) is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or **to use with tools such as Fail2Ban**. The original intent - if I read correctly - was to allow the use of tools such as `Fail2Ban`. Well, the `LOG_FAILED_LOGIN_MESSAGE` option is useless for tools such as Fail2Ban, as it does not provide a way to get the real IP address of the user/attacker in the logs. That makes me think this option has only made half of the trip. It yields a message (calling the `php error_log` function) in the `Nginx error.log` file but only provides a `%u` variable, useless to effectively ban an IP address. The other half of the trip has to be done by the elegant workaround you gave me (`Nginx real-IP` module).

OVERLORD commented

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

@ssddanbrown commented on GitHub (Aug 4, 2022):

The LOG_FAILED_LOGIN_MESSAGE option does not log an IP address itself, since it almost always logs to locations that themselves will contain the IP address. The nginx addition here was only needed because you're in a proxy-based setup. This is not a required step in a non-proxy setup.

Stating My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad misses the fact that option has indeed provided a way to use Fail2Ban to track failed login attempts, something which would be more difficult without this feature.

@ssddanbrown commented on GitHub (Aug 4, 2022): The `LOG_FAILED_LOGIN_MESSAGE` option does not log an IP address itself, since it almost always logs to locations that themselves will contain the IP address. The nginx addition here was only needed because you're in a proxy-based setup. This is not a required step in a non-proxy setup. Stating `My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad` misses the fact that option has indeed provided a way to use Fail2Ban to track failed login attempts, something which would be more difficult without this feature.

OVERLORD commented

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

@jducaud commented on GitHub (Aug 4, 2022):

I do agree with you that there is no problem when using BookStack upfront (not in a container and not behind a reverse proxy). But am I the only person who wants to use BookStack in a Docker container, behind a reverse proxy? Is this setup so uncommon and twisted that it is completely out of topic regarding the BookStack documentation? I do not think so. Two containerized versions of BookStack are proposed as links (LinuxServ.io and solidnerd) and there is even an option (APP_PROXIES) which deals with proxy-based setups (at least for the Audit Log feature).

Nonetheless I admit that saying this option has "no real-life use" was wrong (as it has - as you pointed - at least one use case).

@jducaud commented on GitHub (Aug 4, 2022): I do agree with you that there is no problem when using `BookStack` upfront (not in a container and not behind a reverse proxy). But am I the only person who wants to use `BookStack` in a `Docker` container, behind a reverse proxy? Is this setup so uncommon and twisted that it is completely out of topic regarding the `BookStack` documentation? I do not think so. Two containerized versions of `BookStack` are proposed as links (`LinuxServ.io` and `solidnerd`) and there is even an option (`APP_PROXIES`) which deals with proxy-based setups (at least for the `Audit Log` feature). Nonetheless I admit that saying this option has "no real-life use" was wrong (as it has - as you pointed - at least one use case).

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#2938