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?
Oui, pour nous, passer à la version 2 a immédiatement valu le coup dès qu’elle est devenue disponible pour les charges de travail de production. Les passerelles Azure font beaucoup de choses étranges ; l’ajout de ports aux adresses IP dans l’en-tête Forwarded-For n’est que l’une de ces décisions arbitraires qui nous ont rendu fous. Les adresses VIP statiques sont formidables.
La mise à l’échelle automatique de la capacité des passerelles est également excellente ; elle nous a déjà sauvé la mise à plusieurs reprises. Et la redondance des zones est enfin la bienvenue.
La migration a pris environ vingt minutes, et nous avons des centaines de listeners ainsi que des pools d’arrière-plan relativement complexes. Il existe un script PowerShell pour vous aider, et c’est super simple.
Je ne sais pas si vous utilisez des certificats sur la passerelle, mais si c’est le cas, la version 2 est extrêmement rapide : plus besoin d’attendre 40 minutes pour appliquer un certificat, cela ne prend plus que quelques secondes.
La tarification est beaucoup plus complexe (Microsoft donne d’une main, ils reprennent toujours de l’autre), mais pour nous, jusqu’à présent, les factures sont identiques ou inférieures.
Heureux vous. En raison du coût plus élevé, nous avons dû revenir à la SKU V1 dès la fin de l’aperçu de la V2.
Quoi qu’il en soit, il semble que ce problème/ce cas ait déjà été résolu en amont par une PR fusionnée et devrait être inclus depuis rack 2.0. Mais selon ce problème, il manque toujours dans les versions actuelles.
Temporairement, j’applique un correctif pendant le CI/CD pour gérer ce problème. Ce n’est pas idéal, mais cela fera l’affaire jusqu’à ce que nous voyions la correction dans une prochaine version de rack ou de Discourse.
Si quelqu’un est intéressé, voici la partie que vous devez modifier pour vous débarrasser du port supplémentaire dans lib/auth/default_current_user_provider.rb :
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
Je ne sais pas si c’est une bonne idée de remplacer n’importe quelle occurrence de request.ip par ce correctif rapide ailleurs dans ce fichier ou dans d’autres (email_controller.rb, 006-mini_profiler.rb, request_tracker.rb), mais cela fonctionne pour nous.
Comme dit, l’appliquer en tant que correctif pendant vos processus de build/CI maintient la base de code propre et mise à jour.
Toute solution « plus élégante » est la bienvenue.
