Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[framework-bundle] Added support for the 0.0.0.0/0 trusted proxy #15706

Closed
wants to merge 1 commit into from

Conversation

zerkms
Copy link
Contributor

@zerkms zerkms commented Sep 7, 2015

Q A
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
License MIT

It is relevant to my other PR: #14690

The original intention was to start accepting 0.0.0.0/0 as a trusted proxy (which is a valid CIDR notation).

The prupose is to allow all requests to be treated as trusted and to eliminate using dirty ['0.0.0.0/1', '128.0.0.0/1'] workaround.

@zerkms zerkms changed the title Added support for the 0.0.0.0/0 trusted proxy [framework-bundle] Added support for the 0.0.0.0/0 trusted proxy Sep 7, 2015
@zerkms
Copy link
Contributor Author

zerkms commented Oct 8, 2015

Guys, anyone?

@zerkms
Copy link
Contributor Author

zerkms commented Nov 12, 2015

A traditional monthly reminder: guys, could someone please put some attention here?

@@ -139,6 +139,10 @@ public function getConfigTreeBuilder()
}

if (false !== strpos($v, '/')) {
if ('0.0.0.0/0' === $v) {
return false;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move this above the earlier if (no need to do the strpos() check first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xabbuh that's a fair point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xabbuh from the other hand, the '0.0.0.0/0' scenario is less likely to happen. So how about promoting the more-likely-to-happen scenario over the other?

If we move this check before the if (false !== strpos($v, '/')) { then we would have 2 checks for almost every symfony user, instead of just 1 as it is now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's probably true, but as the Configuration class won't be checked at runtime it doesn't really matter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xabbuh oh, right. Completely missed that point. It does not make much difference then. Let's see if there are more concerns here from someone else.

@xabbuh
Copy link
Member

xabbuh commented Nov 12, 2015

looks good to me

@fabpot
Copy link
Member

fabpot commented Nov 13, 2015

Out of curiosity, why would you want to do that? Is it only for development purpose?

@zerkms
Copy link
Contributor Author

zerkms commented Nov 13, 2015

@fabpot it's for production:

I have the following configuration:

  1. haproxy terminates https and accepts incoming connections. It puts the original IP address to the X-Forwarded-For and sets x-forwarded-proto to https. So at this point in the remote address - the ip of haproxy, and the client's ip is in the header.
  2. nginx configured with ngx_http_realip_module replaces the remote adress with what we have X-Forwarded-For. This simplifies configuration - we can use white/black-lists using the remote ip address and we can use the standard log formats, etc.

So far so good. But as you remember the application is served via HTTPS while symfony runs behind nginx http. Thankfully the x-forwarded-proto is there but for symfony to respect it the remote ip address must be trusted.

What we have: all the requests to nginx come from a trusted proxy (everything is passed through haproxy) but the remote ip address is replaced with ngx_http_realip_module.

Which means that for everything to work as we expected - we need to tell symfony to trust all ip's, hence to 0.0.0.0/0.

So in my implementation it's nginx that need to know who to trust to, and symfony just need to trust anyone, since everything was already constrained by haproxy and nginx.

@fabpot
Copy link
Member

fabpot commented Jan 25, 2016

Thank you @zerkms.

fabpot added a commit that referenced this pull request Jan 25, 2016
…ed proxy (zerkms)

This PR was submitted for the 2.8 branch but it was merged into the 2.3 branch instead (closes #15706).

Discussion
----------

[framework-bundle] Added support for the `0.0.0.0/0` trusted proxy

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| License       | MIT

It is relevant to my other PR: #14690

The original intention was to start accepting `0.0.0.0/0` as a trusted proxy (which is a valid CIDR notation).

The prupose is to allow all requests to be treated as trusted and to eliminate using dirty `['0.0.0.0/1', '128.0.0.0/1']` workaround.

Commits
-------

3188e1b Added support for the `0.0.0.0/0` trusted proxy
@fabpot fabpot closed this Jan 25, 2016
@fabpot fabpot mentioned this pull request Feb 3, 2016
@dzuelke
Copy link
Contributor

dzuelke commented Feb 4, 2016

Can this be backported to 2.8 please, @fabpot ?

@zerkms zerkms deleted the TRUSTED_PROXIES_ZERO_MASK branch February 4, 2016 20:18
@jakzal
Copy link
Contributor

jakzal commented Feb 5, 2016

@dzuelke this fix was merged into 2.3, and is already present in the 2.8 branch.

@dzuelke
Copy link
Contributor

dzuelke commented Feb 5, 2016

Thanks @jakzal

This was referenced Feb 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants