I did have some concerns that this may lead to make it easy to allow bad users to trigger schema rebuilds by sending graphql requests the deliberately contain things that aren't in the schema, though there appears to be validation done before it reaches that point. For instances this is the standard graphql request send when doing a request for elemental, :
I've tried adding "X"'s to various bits of this request, and tested using Firefox's "Edit and resend" in the network panel, though none of them trigger a debug break point I placed in the new code that rebuilds the schema AbstractTypeRegistry::get().
These are the responses I got from the server.
"operationName":"XReadBlocksForAreaX" -- standard response i.e. "ReadBlocksForArea" key isn't important
"query":"query XReadBlocksForAreaX( -- standard response i.e. "ReadBlocksForArea" after query isn't important
XreadOneElementalAreaX(filter -- { message: 'Cannot query field "XreadOneElementalAreaX" on type "Query". Did you mean "readOneElementalArea"?', code: 0, file: "/var/www/vendor/webonyx/graphql-php/src/Validator/Rules/FieldsOnCorrectType.php", … }
readOneXElementalAreaX( -- { message: 'Cannot query field "readOneXElementalAreaX" on type "Query". Did you mean "readOneElementalArea"?', code: 0, file: "/var/www/vendor/webonyx/graphql-php/src/Validator/Rules/FieldsOnCorrectType.php", … }
GuySartorelli
commented
1 year ago
Issue https://github.com/silverstripe/silverstripe-graphql/issues/500
Schema building code is copied from https://github.com/silverstripe/silverstripe-graphql/blob/4/src/Dev/Build.php#L81 though I've removed all the logging.
I did have some concerns that this may lead to make it easy to allow bad users to trigger schema rebuilds by sending graphql requests the deliberately contain things that aren't in the schema, though there appears to be validation done before it reaches that point. For instances this is the standard graphql request send when doing a request for elemental, :
{"operationName":"ReadBlocksForArea","variables":{"id":1},"query":"query ReadBlocksForArea($id: ID!) {\n readOneElementalArea(filter: {id: {eq: $id}}, versioning: {mode: DRAFT}) {\n elements {\n id\n title\n blockSchema\n obsoleteClassName\n isLiveVersion\n isPublished\n version\n canCreate\n canPublish\n canUnpublish\n canDelete\n __typename\n }\n __typename\n }\n}\n"}I've tried adding "X"'s to various bits of this request, and tested using Firefox's "Edit and resend" in the network panel, though none of them trigger a debug break point I placed in the new code that rebuilds the schema
AbstractTypeRegistry::get().These are the responses I got from the server.
"operationName":"XReadBlocksForAreaX"-- standard response i.e. "ReadBlocksForArea" key isn't important"XqueryX":"query ReadBlocksForArea(--{ message: 'This endpoint requires a "query" parameter', code: 400, file: "/var/www/vendor/silverstripe/framework/src/Control/RequestHandler.php", … }"query":"XqueryX ReadBlocksForArea(--{ message: 'Syntax Error: Unexpected Name "XqueryX"', code: 0, file: "/var/www/vendor/webonyx/graphql-php/src/Language/Parser.php", … }"query":"query XReadBlocksForAreaX(-- standard response i.e. "ReadBlocksForArea" after query isn't importantXreadOneElementalAreaX(filter--{ message: 'Cannot query field "XreadOneElementalAreaX" on type "Query". Did you mean "readOneElementalArea"?', code: 0, file: "/var/www/vendor/webonyx/graphql-php/src/Validator/Rules/FieldsOnCorrectType.php", … }readOneXElementalAreaX(--{ message: 'Cannot query field "readOneXElementalAreaX" on type "Query". Did you mean "readOneElementalArea"?', code: 0, file: "/var/www/vendor/webonyx/graphql-php/src/Validator/Rules/FieldsOnCorrectType.php", … }