fix(rules): match GraphQL operationName in query params on GET requests - #119
Open
Abhishek-B-R wants to merge 1 commit into
Open
fix(rules): match GraphQL operationName in query params on GET requests#119Abhishek-B-R wants to merge 1 commit into
Abhishek-B-R wants to merge 1 commit into
Conversation
Request payload filters (used for GraphQL operationName targeting) only read the parsed request body, so they never matched GET GraphQL requests where the operationName lives in the URL query string. For GET/HEAD requests with no body, derive the payload object from the query params, mirroring how getGraphQLDetails in harLogs/utils.ts reads GQL details from the query string. The same fix is applied in both the extension matcher (ruleMatcher.ts) and the shared rule-processor matcher (RuleHelper.js) so the extension and desktop app behave the same. Fixes requestly#35
|
|
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
2 participants
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.
What this fixes
GraphQL rules that target an operationName did not apply to GET GraphQL requests. Fixes #35.
Root cause
Request payload filters (the mechanism behind GraphQL operationName targeting) only read the parsed request body. GET GraphQL requests carry no body: the operationName lives in the URL query string. So the matcher's body lookup came back empty and the filter never matched. The traffic table already reads GQL details from query params for GET requests (
getGraphQLDetailsinharLogs/utils.ts), the rule matcher just did not.The fix
For GET and HEAD requests with no body, derive the payload object from the URL query params and match against that, mirroring
getGraphQLDetails. POST keeps reading the body, so existing behavior is unchanged. The same change is applied in both matchers, the extension (ruleMatcher.ts) and the shared rule-processor (RuleHelper.js), so the extension and desktop app behave the same.Tests
Added 3 cases to
RuleHelper.spec.js: a GET request whose operationName is in the query params matches, a different operationName does not match, and a POST request still matches via the body.Note on running the suite: the karma tests currently fail on a fresh clean checkout of master with
Cannot access '__WEBPACK_DEFAULT_EXPORT__' before initialization, a webpack 5 circular dependency that surfaces under node 22. This change does not touch that. To get a real before and after signal I validated theRuleHelperlogic with a small standalone harness: before the change the GET and HEAD cases fail, after it they pass, and the POST body path is unchanged. Happy to send that webpack test setup fix as a separate small PR if it helps, keeping this one scoped to #35.