8000
siosphere
changed the title
SubRequestHandler doesn't handle nested fragments
SubRequestHandler doesn't handle nested fragments correctly
Aug 19, 2018
SubRequestHandler doesn't handle nested fragments correctly #28226
Comments
|
Same as your other issue: can you please check if this still happens with branch 2.8? It might contain a yet unreleased fix. |
|
Please confirm #28241 fixes your issue. |
|
This appears to fix the issue. Thank you. |
nicolas-grekas
added a commit
that referenced
this issue
Aug 24, 2018
…meters (nicolas-grekas) This PR was merged into the 2.8 branch. Discussion ---------- [HttpKernel] fix forwarding trusted headers as server parameters | Q | A | ------------- | --- | Branch? | 2.8 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #28233, #28226, #28225, #28240 | License | MIT | Doc PR | - Commits ------- 9295348 [HttpKernel] fix forwarding trusted headers as server parameters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symfony version(s) affected: 2.8.44
Description
In SubRequestHandler if the $remoteAddr is not a trusted proxy, you loop through all trustedHeaders and remove them. However, at the end of this function, you add 127.0.0.1 as a trustedProxy, if that fragment renders a sub fragment, the Request that gets sent to SubRequestHandler contains the headers that were previously stripped. This time, the IP is set as a trusted proxy, so they are not stripped again. This issue caused our internal render(controller()) fragments to fail because the x-forwarded-port header and the forwarded headers were both set.
The main request, and any fragments that did not have nested render(controller()) rendered fine as the headers were properly stripped.
How to reproduce
Create a fragment using {{render(controller('MyController:someAction'))}} that includes a twig that also has a {{render(controller('MyController::otherAction'))}} and supply a x-forwarded-port and forwarded header, the fragment will throw an exception (in production mode, the fragment will just render blank). Through debugging you can also see how the first fragment request, the headers are stripped, and the second request that comes through, has all the headers added back, and are not stripped since 127.0.0.1 is listed as a trusted proxy.
Possible Solution
When doing a render(controller()) the Fragment request object should be sent to it's sub fragments, right now it looks like the main request is what is being forwarded, so the headers that were previously stripped come back.
The text was updated successfully, but these errors were encountered: