• Proposals

  • About using flarum behind reverse proxy

Tonight a netizen asked a question in flarum cn discussion. He deploy a flarum and used Tencent CDN as reverse proxy. But ip_address in dbms are all wrong.

I tested, and it can reproduce in my developing enviroment by Host Chrome -> Host Caddy -> Dockered Nginx and Dockered php-fpm Flarum. Real ip_adress may 10.240.***.*** as I am using 10.240.***.*** to connect to caddy, but I got docker ip 172.0.***.***.

https://github.com/flarum/framework/blob/379c06332a0789b892b0426b3eb8be24bd557db4/framework/core/src/Http/Middleware/ProcessIp.php#L22

We noticed that flarum got remote ip by $SERVER['REMOTE_ADDR'], but if we use a flarum instance behind proxy like Ingress or Cloudflare, it may not work as well as we thought.

Refer to Laravel document and Symfony document
https://github.com/laravel/framework/blob/9.x/src/Illuminate/Http/Middleware/TrustProxies.php
https://github.com/symfony/http-foundation/blob/6.1/Request.php#L565

Symfony provides a simple way to get the whole proxy chain, but Flarum doesn't dut to laminas/laminas-diactoros did not contains a function like this.

Does flarum is planning to support X-Forward- seris header?

Relevant topic

flarum/framework2778

    a month later

    Eric_Lian Part of the reason that we added the ProcessIp Middleware was actually so that handling proxy IPs via the X-Fowards headers in the future would be easier without breaking extensions.

    However in actually attempting to design/implement that logic no one could come to a consensus on exactly the best way to implement it, or which of the many various Proxy headers to follow. Notably there is both the X-Fowarded-For header, and the Via header. Both of which do basically the same thing, but one is older than the other. And there were also library issues in which we couldn't find any good libraries to do this for us.

    You can see the original attempt at handling proxy IPs at flarum/framework2778

    One of the things you'll note is that it lacks proxy validation. And also doesn't have Via header support.

    I think what we need to move further on it would be an actual set of expectations, an idea of how to properly implement it, and known best practices.

        7 days later

        Thanks for your reply.

        There do is a long way to go to get this solution.

        I will keep my eyes on this topic. If there is any progress, I will post my thought as soon as possible.

        Is it a good plan add this ProcessIp into IOC container? User can register a custom processing procedure into flarum.

        a year later

        Hello, I am also displaying the Docker IP, so how should I do it? I don't quite understand, can you explain it to me in detail?

        8 months later

        tankerkiller125 I think what we need to move further on it would be an actual set of expectations

        A reasonable, sensible reverse proxy scenario to aim at, IMHO, would look like this.

        Someone owns a cheap Raspberry Pi-like device, and wants to host Flarum (within their LAN) on it. Note: Discourse is too heavyweight for a Raspberry Pi, and PHPBB is too mobile-unfriendly, for 2024.

        They furthermore want to make their Flarum install publicly accessible by renting a cheap $5ish per month VPS, which will be the public frontend to Flarum. So they create a wireguard tunnel from the Raspberry Pi to the VPS. It's this Wireguard tunnel that the reverse proxy will travel down, to get to the Raspberry Pi's Wireguard IP address within the LAN.

        Web servers like nginx, both on the VPS, and the Raspberry Pi, are safe defaults to assume, as a starting point for what web server to support first.

        Debian 12 is a safe OS to assume, because Raspberry Pi OS is based on it. Raspberry Pi OS has several desirable niceties - tightly integrated to the Raspberry Pi hardware - that make system administration easier. As to other cheap SBCs (usually ARM-based), it's virtually always a Debian-based OS which is the very first OS to be offered for that board, by the SBC maker.

        I can't think of a more common, straightforward scenario for using a reverse proxy than this.

        BTW: it would be nice if Flarum furthermore supported CORS, so that a hostname within the lan would work to access Flarum, in addition to a public hostname as seen from the wider internet, coming down the reverse proxy. There would be SSL on both of these, however the SSL within the LAN might just be a self-signed certificate (say, for a hostname like "flarum.lan")

        Also Note: A free SSL cert for the VPS can be had, for example, by creating a duckdns.org hostname, then use acme.sh to obtain ssl certs. Certbot is not so ideal here, since we've got a reverse proxy interfering with certbot's desire to control the web server (nginx).