No, it isn’t an IP address, and that’s the problem. If you’ve got a proxy that’s including a port number in what’s supposed to be an IP address, then the proxy is broken, and you’ll want to get that fixed.
I haven’t find the root cause yet. But I find a defected solution. By adding the following configuration in app.yml. I make the input of ip_address valid.
filename: /etc/nginx/conf.d/discourse.conf
from: $proxy_add_x_forwarded_for
to: $http_your_original_ip_header
global: true
The defected part is that the user ip_addresses are all 127.0.0.1 now. It’s not perfect, but the 500 errors won’t throw finally.
The “for” parameter is used to disclose information about the client
that initiated the request and subsequent proxies in a chain of
proxies. When proxies choose to use the “for” parameter, its default
configuration SHOULD contain an obfuscated identifier as described in
Section 6.3. If the server receiving proxied requests requires some
address-based functionality, this parameter MAY instead contain an IP
address (and, potentially, a port number). A third option is the
“unknown” identifier described in Section 6.2.
If your nginx setting is using $proxy_add_x_forwarded_for as the indicate of user ip. I think ip with port will be a valid input here. You may need to strip the port info out.
Q. Does Application Gateway support x-forwarded-for headers?
Yes, Application Gateway inserts x-forwarded-for, x-forwarded-proto, and x-forwarded-port headers into the request forwarded to the backend. The format for x-forwarded-for header is a comma-separated list of IP:Port. The valid values for x-forwarded-proto are http or https. X-forwarded-port specifies the port at which the request reached at the Application Gateway.
I will seek solution in rack or Azure Gateway.
Thanks @sam also.
Just to add to the conversation - this is standard practice in Azure Application Gateways, and it’s infuriating. They add the port to the forwarded-for header even though they also send it in the forwarded port header.
Two feedback/change requests on Microsoft which you can vote for;
Our “fix” is also the same as the above step, we’re manually setting the forwarded-for header to a generic ip as this caused lots of issues with users being logged out or the site not working properly.
Just out of interest, we are using a httpd redirect within the network, does anyone know if it is possible to rewrite the header and remove the port? Failing that can it be done in nginx (I am unfamiliar with nginx)?
I would look at submitting a PR if we get this fixed but the comments above seem to suggest the devs would prefer this fixing upstream - is that the case?
Ja, für uns hat sich das Upgrade auf v2 sofort gelohnt, als es für Produktionsworkloads verfügbar wurde. Azure-Gateways machen viele seltsame Dinge – das Anhängen von Ports an Forward-For-IPs ist nur eine der subjektiven Entscheidungen, die uns den Verstand gekostet haben. Statische VIPs sind großartig.
Die automatische Skalierung der Gateway-Kapazität ist ebenfalls hervorragend und hat uns bereits ein- oder zweimal das Leben gerettet. Und die Zonenredundanz ist endlich eine sehr willkommene Neuerung.
Die Migration dauerte etwa zwanzig Minuten, obwohl wir Hunderte von Listeners und einige relativ komplexe Backend-Pools haben. Es gibt ein PowerShell-Skript, das Sie unterstützen, und es ist super einfach.
Ich bin mir nicht sicher, ob Sie Zertifikate auf dem Gateway verwenden, aber falls ja, ist v2 extrem schnell – kein Warten mehr von 40 Minuten, bis ein Zertifikat angewendet wird; es dauert jetzt nur noch Sekunden.
Die Preisgestaltung ist weitaus komplexer (Microsoft gibt mit der einen Hand, nimmt aber immer mit der anderen zurück), aber für uns waren die Rechnungen bisher gleich hoch oder sogar niedriger.
Haben Sie Glück. Aufgrund der höheren Kosten mussten wir zurück zu SKU V1 wechseln, sobald die V2-Vorschau beendet war.
Wie auch immer, es scheint, dass dieses Problem/Fall bereits upstream durch einen zusammengeführten PR behoben wurde und seit Rack 2.0 enthalten sein sollte. Laut diesem Issue fehlt es jedoch immer noch in den aktuellen Releases.
Vorübergehend wende ich während CI/CD einen Patch an, um dieses Problem zu lösen. Es ist nicht das Schönste, aber es erledigt den Job, bis wir die Korrektur in einem kommenden Rack-/Discourse-Release sehen.
Falls jemand interessiert ist, das ist der Teil, den Sie ändern müssen, um das zusätzliche Port in lib/auth/default_current_user_provider.rb loszuwerden:
if current_user && should_update_last_seen?
u = current_user
ip_port_split = request.ip.split(':')
ip_only = ip_port_split.first
Scheduler::Defer.later "Updating Last Seen" do
u.update_last_seen!
u.update_ip_address!(ip_only)
end
end
Ich weiß nicht, ob es eine gute Idee ist, jedes Vorkommen von request.ip mit diesem Quickfix auch an anderer Stelle in dieser Datei oder in anderen (email_controller.rb, 006-mini_profiler.rb, request_tracker.rb) zu ersetzen, aber es funktioniert bei uns.
Wie gesagt, das Anwenden als Patch während Ihrer Build-/CI-Prozesse hält die Codebasis sauber und aktualisierbar.
