Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[HttpFoundation][FrameworkBundle] Revert "trusted proxies" BC break#23067
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
fabpot commentedJun 5, 2017
Thank you@nicolas-grekas. |
… BC break (nicolas-grekas)This PR was merged into the 3.3 branch.Discussion----------[HttpFoundation][FrameworkBundle] Revert "trusted proxies" BC break| Q | A| ------------- | ---| Branch? | 3.3| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets | -| License | MIT| Doc PR | -Basically reverts#22238 + cleanups some comments + adds missing syncing logic in setTrustedHeaderName.The reason for this proposal is that the BC break can go un-noticed until prod, *even if you have proper CI*. That's because your CI may not replicate exactly what your prod have (ie a reverse proxy), so that maybe only prod has a trusted-proxies configuration. I realized this while thinking about#23049: it made this situation even more likely, by removing an opportunity for you to notice the break before prod.The reasons for the BC break are still valid and all of this is security-related. But the core security issue is already fixed. The remaining issue still exists (an heisenbug related to some people having both Forwarded and X-Forwarded-* set for some reason), but deprecating might still be enough.WDYT? (I'm sure everyone is going to be happy with the BC break reversal, but I'm asking for feedback from people who actually could take the time to *understand* and *balance* the rationales here, thanks :) )Commits-------2132333 [HttpFoundation][FrameworkBundle] Revert "trusted proxies" BC break
syrm commentedJun 6, 2017 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Well, i was one of the most criticism guy about this BC break. |
andig commentedJun 6, 2017
I'm a little confused how an intentional bc break csn be ubdone by a patch release. I've just updated requirements to 3.3 and fixed my code. 3.3.1 would essentially break that again? |
syrm commentedJun 6, 2017
No break again in 3.3.1 if you already applied the change for 3.3 |
syrm commentedJun 9, 2017
@nicolas-grekas no answer about lack of information in trigger_error about security problem ? |
nicolas-grekas commentedJun 9, 2017
I don't have anything specific to say about your suggestion. Please open a PR if you want. |
…es (xabbuh)This PR was merged into the 3.3 branch.Discussion----------[HttpFoundation] add back support for legacy constant values| Q | A| ------------- | ---| Branch? | 3.3| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets || License | MIT| Doc PR |Due to the data type change of the `Request::HEADER_` constants in Symfony 3.3#23067 introduced a small BC break if someone used the old constant values statically instead of referring to the constants themselves.Commits-------fddd754 add back support for legacy constant values
Uh oh!
There was an error while loading.Please reload this page.
Basically reverts#22238 + cleanups some comments + adds missing syncing logic in setTrustedHeaderName.
The reason for this proposal is that the BC break can go un-noticed until prod,even if you have proper CI. That's because your CI may not replicate exactly what your prod have (ie a reverse proxy), so that maybe only prod has a trusted-proxies configuration. I realized this while thinking about#23049: it made this situation even more likely, by removing an opportunity for you to notice the break before prod.
The reasons for the BC break are still valid and all of this is security-related. But the core security issue is already fixed. The remaining issue still exists (an heisenbug related to some people having both Forwarded and X-Forwarded-* set for some reason), but deprecating might still be enough.
WDYT? (I'm sure everyone is going to be happy with the BC break reversal, but I'm asking for feedback from people who actually could take the time tounderstand andbalance the rationales here, thanks :) )