@fabpot: I have now updated the PR to throw exceptions instead, and to not do so when both the Forwarded and X-Forwarded-For header agree with each other.

I am a bit worried about the fact that the very commonly usedgetClientIp method now throws exceptions when users previously did not expect it to, though. I mean, the request is inconsistent, so clearly we need to do something, but this can happen when the user least expects it to. Should I perhaps "validate" the request early on in the request lifecycle, to make sure that if we're going to throw, we throw early?

@magnusnordlander I agree with you that we should bail out as early as possible and consistently.

I'll give some consideration to where to put this validation, and have an updated PR ready tomorrow (also fixing the other two things, of course).

Status: needs work

@magnusnordlander Do you have time in the next few days to update this PR?

I'll have time this Friday.

So, the code is updated. The remaining build error is because the composer.json of HttpKernel and FrameworkBundle needs to be updated to require the version of HttpFoundation and HttpKernel respectively, that this is released in. I don't know how to handle that without actually making a release. Any help there?

Ping@fabpot

👍

Thank you@magnusnordlander.

Late to the party here, but I just experienced the exception after upgrading to 2.8.8 and landed on this page. The server is behind Akamai, and looks like it's sending both Forwarded and X-Forwarded-For headers. I checked the new documentation and tried disallowing one of the headers, but it didn't help and the error didn't go away. Any ideas why and how do I only allow one of those headers? Here is the snippet I used: Request::setTrustedHeaderName(Request::HEADER_FORWARDED, null);

Well some of our members use proxies (Forwarded) and we use reverse proxies (X-Forwarded-For), as a result, boom. Do I miss something?

@iSyndicate So, first of all, it seems odd that Akamai is sending you different information about the provenance of the request in the different headers. That's not been my experience with them, and I suspect might be a configuration issue. However, you should, as you have attempted, be able to fix that by distrusting one of the headers, and that snippet is indeed correct. In which file, and where, did you put that snippet?

@ninsuo: Well, yes. You can't trust the information coming from random strangers (or in this case rather, random clients) on the Internet. Ideally your reverse proxy would be filtering out the untrusted Forwarded header (because, since you have marked it as a trusted proxy, you are relying on it for accurate information on the provenance of the request, and the Forwarded header coming from your clients is not trustworthy), but if that is not possible, you should make sure Symfony distrusts the Forwarded header, as detailed here:http://symfony.com/doc/current/request/load_balancer_reverse_proxy.html#my-reverse-proxy-sends-x-forwarded-for-but-does-not-filter-the-forwarded-header

Thank you for clarification.

But as everybody can set any header I don't see any point of using them as a reliable information. We do trust and use only the headers our nginx is setting, no matter what our members are setting.

We can use Referer header (as well as lots of others) to flag client as "using a proxy" and giving him a lesser trust score (more chances to get 3DSecure, MFA, ...) and removing it is quite inconvenient.

@magnusnordlander

You can not trust X-Forwarded, Forwarded, both of them, your system engineer is in charge of reading remoteip_addr on the first front node of your infrastructure and provide you (to your framework) the value read in a secure way that you can trust (according together), I think about a dedicated header, your system engineer sets/overrides in all cases. You can keep Forwarded and X-Forwarded headers for information and to decorate... I do not see very well where the Symfony framework has to be intelligent on such security problem.

This particular piece of code only runs when you have configured Symfony to trust a proxy server. By default, Symfony doesn't trust any proxy server, and does not consider X-Forwarded-For nor Forwarded to contain reliable information on the Client IP.