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 :
forwardedclient-ipx-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 ?