-
Notifications
You must be signed in to change notification settings - Fork 41
Include meta fields (__typename, __type, __schema) against total field complexity [2] #92
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
Conversation
Thanks for the PR and adding a test @Squarix . I'll merge this and then cut a 1.0 major release, so the optional parameter is unnecessary IMO. Users can always write a custom estimator that excludes those fields as the first estimator in the chain and they would have a backwards compatible implementation.
smcgivern
commented
Jun 10, 2024
@ivome nice! Any idea when we can expect that release? (No rush, I'm just checking in.)
@ivome nice! Any idea when we can expect that release? (No rush, I'm just checking in.)
+1
Just published v1.0.0
Uh oh!
There was an error while loading. Please reload this page.
sequel for #90 covered with test
original PR is been inactive for half a year, I decided to open a new one
Original description:
What
Update
QueryComplexity.ts
to count meta fields against total complexity. The current implementation only considers fields included in the schema, which omits:__typename
,__type
and__schema
.Why
Denial of service attacks are possible by creating many aliases of meta fields:
edit:
simple 300kb with 35k
__typename
fields query is able to load server for almost half-a-minute. It can be used for DoS attacks.Considerations
If counting each field as
1
cost, common introspection queries will have a cost around180
. Consumers of the library may need to increase the maximum.edit: Probably, to keep compatibility, we can make some optional parameter to include these fields in total complexity, but I think it's unnecessary