fix: fill the user context before the router can throw - #1068
Open
guillaume-sainthillier wants to merge 1 commit into
Open
guillaume-sainthillier wants to merge 1 commit into
guillaume-sainthillier wants to merge 1 commit into
Conversation
RequestListener::handleKernelRequestEvent sets the Sentry user IP from Request::getClientIp(), which resolves the real client through trusted proxies. It ran at kernel.request priority 5, but RouterListener throws NotFoundHttpException at priority 32, so on any unknown URL the listener never ran. RequestIntegration then fell back to $_SERVER['REMOTE_ADDR'], which behind a reverse proxy is the proxy itself. The result was inconsistent within one application: a 404 raised by the router was attributed to the proxy, while a 404 raised by a controller on the same site carried the real client IP. On a site fronted by a CDN that collapsed millions of events onto a single "user". Move the listener to priority 64: above RouterListener (32) and the security firewall (8), but below ValidateRequestListener (256), so that conflicting forwarded headers are still rejected before getClientIp() is called on them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
RequestListener::handleKernelRequestEventsets the Sentry user IP fromRequest::getClientIp(), which resolves the real client through the configured trusted proxies. It is registered onkernel.requestat priority 5, butRouterListenerthrowsNotFoundHttpExceptionat priority 32.So on any unknown URL the listener never runs, the scope carries no user, and
RequestIntegrationfalls back to$_SERVER['REMOTE_ADDR']— which behind a reverse proxy is the proxy itself, not the client.The result is inconsistent within the same application: a 404 raised by the router is attributed to the proxy, while a 404 raised by a controller on the same site carries the real client IP. I hit this on a site fronted by a CDN, where it collapsed several million events onto a single "user" and made the issue list unusable for triage.
This moves the listener to priority 64:
RouterListener(32) and the security firewall (8), which are the early listeners that throw;ValidateRequestListener(256), so conflicting forwarded headers are still rejected beforegetClientIp()is ever called on them.The listener only reads the request, so it has no dependency on routing or security having run — it used to sit at 5 simply because it once also read the security token, which it no longer does.
This mirrors #1043, which moved
RuntimeContextListenerabove the router for the same class of reason.Tests
ClientIpEnd2EndTestcovers both paths end to end behind a trusted proxy: a routing 404 (/missing-page) and a controller exception (/exception). Both must report the forwarded client IP. The first one fails onmasterand passes with the change; the second passes either way and guards the path that already worked.SentryExtensionTest::testRequestListenerFillsUserContextBeforeTheRouterCanThrowpins the priority window (> 32, < 256) rather than the literal value, so the intent survives a future renumbering.vendor/bin/phpunit— 619 tests, 1782 assertions, green.php-cs-fixerclean.phpstanreports the same 3 pre-existing errors asmaster, none new. (psalm4.30 crashes on PHP 8.5 in my environment, unrelated to this change.)Issues
Reminders