Broken GraphQL endpoint on last Strapi versions

[daniele-orlando]

Bug report

Required System information

• Strapi version: 4.15.5

Describe the bug

In last Strapi 4 versions, GraphQL queries sent over HTTP GET requests receive a Forbidden access error.
Everything works as expected running the same queries over POST requests.

The GraphQL endpoint is /graphql and serves successfully POST queries/mutations and the Playground Web Interface.

This is NOT a feature request, but a regression on the GET endpoint after commit 4436f59. It was working as expected until version 4.3. Upgrading to last Strapi version broke my GraphQL ecommerce and I had to rollback to previous version.

Steps to reproduce the behavior

1. Open a browser console
2. Run

fetch("https://<HOST>/graphql?query=query%7Bpages%7Bdata%7Bid%20attributes%7Bslug%7D%7D%7D%7D", {
  "method": "GET",
}).then(it => it.json()).then(console.log)

Expected behavior

I should receive the GraphQL data as response.

Actual behavior

I receive the error:

{
    "errors": [
        {
            "message": "Forbidden access",
            "extensions": {
                "error": {
                    "name": "ForbiddenError",
                    "message": "Forbidden access",
                    "details": {}
                },
                "code": "FORBIDDEN"
            }
        }
    ],
    "data": {
        "pages": null
    }
}

Additional context

The issue is related to this portion of code that skips the authentication logic.

strapi/packages/plugins/graphql/server/bootstrap.js

Line 110 in dc96169

if (ctx.request.method === 'GET') return next();

Removing this block of code, the GET requests work as expected and the Playground is still reachable on the same endpoint.

-          // allow graphql playground to load without authentication
-          if (ctx.request.method === 'GET') return next();

[derrickmehaffy]

This needs to be determined by product if it's intended as generally it's anti-pattern and considered a bad practice to use GraphQL over GET requests.

As far as I'm aware the GET route was only ever intended for use with the playground and actual queries/mutations -should always- be done over POST.

[derrickmehaffy]

Related discussion: graphql/graphql-over-http#123

[derrickmehaffy]

Likewise specific graphql specification does not require supporting GET: https://graphql.github.io/graphql-over-http/draft/#sec-Request

[daniele-orlando]

Using GraphQL over GET requests is not an anti-pattern at all. I think you confused mutations which must use POST method. GraphQL queries instead should use an idempotent verb like GET and, in order to be cached by the browser, they must use an idempotent verb like GET. POST requests can not be cached by browsers.

A GraphQL server should accept GET and POST requests and should not enforce one method over the other, because it's up to the client to decide the best strategy for its use cases.

Your GraphQL HTTP server should handle the HTTP GET and POST methods.
— Serving GraphQL over HTTP

My queries are served over GET method using Cache-Control, ETag and Last-Modified headers, which make them cachable by the browser. Switching to POST request would break completely the browser caching on any browser, which is not acceptable.

[Hadrien-DELAITRE]

Facing the exactly same issue.

I was trying to implement the APQ documented by Apollo: https://www.apollographql.com/docs/apollo-server/v3/performance/apq
These kind of queries only work with GET HTTP request method:

Persisted queries are especially effective when clients send queries as GET requests.

It seems weird that:

queries/mutations -should always- be done over POST.

Maybe expected features of graphQL is not correctly understood by Apollo & Strapi ?

[daniele-orlando]

Anyone from the Strapi team can give an update about the planned timeline for the resolution of this bug, please?

cc: @Eventyret

[daniele-orlando]

@Eventyret can you increase the severity from severity:low to severity:high, because:
a) there is no workaround except downgrading Strapi (requisite to be low not met)
b) "it breaks the basic use of the product" (requisite to be high met)

[derrickmehaffy]

We can raise it to medium but we still need clarification from our product team if GET requests were ever intended to work as from what I understood they were not.

We specially advise users and especially EE customers to use REST where possible if caching is important.

[daniele-orlando]

Hi dear Strapi team, do we have any update about the resolution of this issue?

[derrickmehaffy]

GET requests are not supported in Strapi 4 and have been added in Strapi 5

[derrickmehaffy]

#19916

[derrickmehaffy]

Actually it looks like a community pr was accepted in 4.22.0 to allow this in v4, so marking as closed.

[derrickmehaffy]

#19168