Handling the "chain of trust" of the end user's real IP

Documentation Self-Hosting
,
5

This is fair, we could just delete it and arrive at the same result (except… see below)

The application boundary really is nginx itself, not Discourse or rails. Thus, the decision on exactly which remote proxies to trust is made at the application entry point, which is nginx. It can then pass that decision on to Discourse.

By default, Rails only trusts local addresses when processing x-f-f, so we do that at a different spot where we can easily control it.

Actually, turns out Rails doesn’t even look at the x-real-ip header… the headers it looks at are

  • forwarded
  • client-ip
  • x-forwarded-for

Somehow that’s made it all the way from…

commit 21b562852885f883be43032e03c709241e8e6d4f (tag: v0.8.0)
Author: Robin Ward
Date:   Tue Feb 5 14:16:51 2013 -0500

    Initial release of Discourse

diff --git a/config/nginx.sample.conf b/config/nginx.sample.conf
new file mode 100644
index 00000000..62fabf4a
--- /dev/null
+++ b/config/nginx.sample.conf
…
+    proxy_set_header  X-Real-IP  $remote_addr;

We’ll have to do some digging, but for now the answer is “it works”. Which I suppose is how we first ended up like this.

Looks like maybe a gem uses it?

1 Like