Gestion de la "chaîne de confiance" de l'IP réelle de l'utilisateur final

C’est une bonne remarque, nous pourrions simplement le supprimer et arriver au même résultat (sauf… voir ci-dessous)

La limite de l’application est en réalité nginx lui-même, pas Discourse ou Rails. Ainsi, la décision sur les proxies distants exacts à faire confiance est prise au point d’entrée de l’application, qui est nginx. Il peut ensuite transmettre cette décision à Discourse.

Par défaut, Rails ne fait confiance qu’aux adresses locales lors du traitement de x-f-f, donc nous le faisons à un endroit différent où nous pouvons facilement le contrôler.

En fait, il s’avère que Rails ne regarde même pas l’en-tête x-real-ip… les en-têtes qu’il examine sont :

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

D’une manière ou d’une autre, cela est arrivé jusqu’à

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;

Nous devrons faire quelques recherches, mais pour l’instant, la réponse est « ça marche ». Ce qui, je suppose, est la raison pour laquelle nous nous retrouvons dans cette situation.

Il semble qu’un gem l’utilise peut-être ?

1 « J'aime »