Adapt config file to conform to Wt trusted proxy changes

[FibreTTP]

I was wondering why despite setting behind-reverse-proxy to true, I had never seen a real Client IP in LMS's logs. I thought I had configured it wrong, but after checking the very top of the LMS logs, I saw that the behind-reverse-proxy config is actually deprecated:

[warning] "config: The behind-reverse-proxy configuration option is deprecated, use a <trusted-proxy-config> block instead"

Turns out, even though the deprecation warning has been showing in issues here for at least two years now, nobody noticed the four year old upstream commit changing client IP detection behaviour.

The new configuration uses a trusted-proxy-config defined in the wt_config.xml file. The default looks like this:

<trusted-proxy-config>
  <original-ip-header>X-Forwarded-For</original-ip-header>
  <trusted-proxies>
  </trusted-proxies>
</trusted-proxy-config>

There are no proxies trusted by default, and seemingly only one original header can be defined.

Inside the <trusted-proxies> element, is a <proxy> element that contains the network in CIDR notation to be considered trustworthy, e.g:

  <trusted-proxies>
    <proxy>10.64.0.0/12</proxy>
  </trusted-proxies>

Because the wt_config.xml file is generated programmatically, users cannot add this new configuration to the file themselves; it is overwritten on startup (nor can they pass --config= to LMS like the logs suggest).

The LMS config should have the deprecated behind-reverse-proxy key removed, and should be adapted to write the new trusted-proxy-config values.

[epoupon]

Hello,
Well I changed this for my other project using wt (see https://github.com/epoupon/fileshelter/blob/710488d4baa23c2dd414ec6892f10b61d51004d0/conf/fileshelter.conf#L37)
If "behind-reverse-proxy" is set, both new config options "original-ip-header" and "trusted-proxies" are used to construct the wt_config.xml file.
Now it looks like it is time to do the same for this project!

[epoupon]

I just tested, it looks like it works fine even with the current deprecated option? Do you correctly forward the relevant headers in your reverse proxy config?
In the doc about the behind-reverse-proxy option in wt_config.xml:

Deprecated: use trusted-proxy-config instead. If this option is
           set to true, Wt will take the first non-local IP address from the
           Client-IP and X-Forwarded-For headers to determine the clientAddress()

Note this is used for example for the message: [info] - 139906810635968 [UI] User 'test' logged in from 'X.X.X.X', user agent = ...

[FibreTTP]

I typed out a big message showing my reverse proxy setup and what the logs look like before realising that the docs in wt_config.xml state this:

...Wt will take the first non-local IP address ...

So yeah. I'm accessing from a local address, of course it's not logging it.

I still believe the config should be replaced, and I see you've added a commit that does that. Thanks :)

old message

Do you correctly forward the relevant headers in your reverse proxy config?

I have set up Caddy manually to include Client-IP in upstream requests to LMS. It also automatically adds the X-Forwarded-For header. My (manually expanded) Caddyfile looks like this:

Caddyfile

lms.fib.red {
    tls /.tls/fib.red/certificates/_.fib.red.crt /.tls/fib.red/certificates/_.fib.red.key {
    }
    handle /robots.txt {
        file_server /robots.txt {
            root /errors
        }
    }
    header >X-Robots-Tag "noindex, noarchive, nosnippet, nofollow"
    encode gzip zstd
    header +Permissions-Policy "interest-cohort=()"
    header ?Strict-Transport-Security "max-age=31536000; includeSubDomains"
    header ?X-Frame-Options "SAMEORIGIN"
    header ?X-Content-Type-Options nosniff
    header -X-XSS-Protection
    header >Referrer-Policy same-origin
    header Cross-Origin-Opener-Policy same-origin
    header Cross-Origin-Resource-Policy same-site
    header -Server
    header -X-Powered-By
    header -X-AspNet-Version
    header -X-AspNetMvc-Version
    header X-DNS-Prefetch-Control off
    header Origin-Agent-Cluster "?1"
    log lms.fib.red {
        output file /logs/lms.fib.red.log {
            roll_size 100MiB
            roll_local_time
            roll_keep 7
            roll_keep_for 7d
        }
        format json
    }
    reverse_proxy http://lms:5082 {
        header_up Client-IP {client_ip}
    }
}

The upstream request from includes the X-Forwarded-For header, but it seems like the Client-IP header is either only visually, or actually transformed to Client-Ip:

Caddy upstream request log

{
    "level": "debug",
    "ts": 1728196768.1296039,
    "logger": "http.handlers.reverse_proxy",
    "msg": "upstream roundtrip",
    "upstream": "lms:5082",
    "duration": 0.001520401,
    "request": {
        "client_ip": "192.168.1.10",
        "headers": {
            "Accept": [
                "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
            ],
            "Accept-Encoding": [
                "gzip, deflate, br, zstd"
            ],
            "Accept-Language": [
                "en-GB,en;q=0.5"
            ],
            "Alt-Used": [
                "lms.fib.red"
            ],
            "Client-Ip": [
                "192.168.1.10"
            ],
            "Cookie": [
                "REDACTED"
            ],
            "Dnt": [
                "1"
            ],
            "Priority": [
                "u=0, i"
            ],
            "Sec-Fetch-Dest": [
                "document"
            ],
            "Sec-Fetch-Mode": [
                "navigate"
            ],
            "Sec-Fetch-Site": [
                "cross-site"
            ],
            "Sec-Gpc": [
                "1"
            ],
            "Upgrade-Insecure-Requests": [
                "1"
            ],
            "User-Agent": [
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0"
            ],
            "X-Forwarded-For": [
                "192.168.1.10"
            ],
            "X-Forwarded-Host": [
                "lms.fib.red"
            ],
            "X-Forwarded-Proto": [
                "https"
            ]
        },
        "host": "lms.fib.red",
        "method": "GET",
        "proto": "HTTP/3.0",
        "remote_ip": "192.168.1.10",
        "remote_port": "51738",
        "tls": {
            "cipher_suite": 4865,
            "proto": "h3",
            "resumed": true,
            "server_name": "lms.fib.red",
            "version": 772
        },
        "uri": "/"
    },
    "headers": {
        "Cache-Control": [
            "no-cache, no-store, must-revalidate"
        ],
        "Content-Encoding": [
            "gzip"
        ],
        "Content-Type": [
            "text/html; charset=UTF-8"
        ],
        "Date": [
            "Sun, 06 Oct 2024 06:39:28 GMT"
        ],
        "Expires": [
            "0"
        ],
        "Pragma": [
            "no-cache"
        ],
        "X-Frame-Options": [
            "SAMEORIGIN"
        ]
    },
    "status": 200
}

So assuming that the header is truly incorrectly capitalised, and that Wt looks at BOTH the Client-IP and X-Forwarded-For headers for a matching address, I can see why it is failing to log my client IP. (but IMO it should really just look at either of them, and prioritse the Client-IP header if there are any differences)

And here's what LMS's log looks like:

[2024-Oct-06 06:30:29.850] 1 [/ GkOFvATuNHLekIee] [info] - 123445601725240 [UI] User 'x' logged in from '10.64.72.2', user agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0