Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged
ivome merged 1 commit into slicknode:master from Squarix:complexity-for-meta-fields
May 28, 2024

Conversation

Copy link
Contributor

@Squarix Squarix commented May 26, 2024
edited
Loading

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:

query LargeQuery {
 __typename
 alias1: __typename
 alias2: __typename
 ...
 alias1000: __typename
}

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 around 180. 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

Copy link
Collaborator

ivome commented May 28, 2024

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.

Squarix and smcgivern reacted with heart emoji

Copy link

@ivome nice! Any idea when we can expect that release? (No rush, I'm just checking in.)

Squarix reacted with thumbs up emoji

Copy link
Contributor Author

Squarix commented Jun 10, 2024

@ivome nice! Any idea when we can expect that release? (No rush, I'm just checking in.)

+1

Copy link
Collaborator

ivome commented Jun 10, 2024

Just published v1.0.0

smcgivern reacted with hooray emoji Squarix and ThibaultJacquemet reacted with rocket emoji

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /