GraphQL public schema changes

[samatcd]

Description

I'm having a problem using project.yaml and setting up GraphQL Public Schema. I have allowAdminChanges false in staging and production environments.

We needed to make some changes to our public schema — somehow we ended up with multiple public schema entries in our project.yaml. We manually deleted the extra ones. This probably would have worked fine if we'd managed to keep the same public schema ID that was originally created.

In development, the Public Schema works as it should (presumably because it was created in development environment) — when making GraphQL queries it doesn't require the Authorization header. In staging and production, after synching with the project.yaml, Craft won't allow me to make queries to CraftQL, they all get rejected with Status 400 {"error":"Missing Authorization header"}.

I've verified that in the staging and production databases the gqlschemas and gqltokens are created.

What I noticed was that the gqltokens record for the __PUBLIC__ accessToken has an empty schemaId field after the project.yaml sync. It appears this field isn't getting populated. Manually setting it to the created gqlschemas record ID is a workaround but sorts the problem.

Steps to reproduce

1. Create a development site + database and enable GraphQL public schema.
2. Set allowAdminChanges false and ensure project.yaml is enabled.
3. Launch the site in staging environment with a separate database, sync with project.yaml
4. Delete and recreate the public schema in development, save new project.yaml with updated public schema. Manually delete old public schema entry from project.yaml.
5. Try make a request to GraphQL public schema on staging site

Additional info

• Craft version: Craft Pro 3.4.19.1
• PHP version: 7.4.5
• Database driver & version: MySQL 5.7.19
• Plugins & versions: none required for this issue

[andris-sevcenko]

I'm not sure how you ended up with multiple schemas in the project.yaml file, but that's where things went sideways, I would assume. When you deleted the wrong schema and then pushed the project.yaml file, Craft looked at it, figured it should create a new public schema, and discard the old public schema, which would create the empty schema id for the public token.

Have you tried re-saving the public token in the control panel? If that doesn't quite work, I think in this case it's perfectly acceptable to restore to link in the database by setting the record ID manually.

[michtio]

@andris-sevcenko I think somehow something is wrong tho.

Recently deleted the Search "scope" and switched to public, but do get on prod/staging the same error.

This is what left in project.yaml

graphql:
  schemas:
    352b0087-9406-480b-a03d-a8a9186dc975:
      isPublic: '1'
      name: 'Public Schema'
      scope:
        - 'sections.4971c348-7dcb-44fc-9196-9518ea23c181:read'
        - 'entrytypes.c44f8ad0-a276-485c-bc08-dc87e8a08162:read'
        - 'sections.ad17e7ea-e3b2-4288-bfc2-784778c73be7:read'
        - 'entrytypes.b5d69547-4b48-4b63-beaa-313ddcf0ad5a:read'
        - 'sections.95f82d05-c6e0-4a67-91a0-d99691a4430c:read'
        - 'entrytypes.f77552e9-a2e4-40c4-a6f2-828bb308324c:read'
        - 'volumes.9c01ae20-62f6-4e68-a7a4-c397b33022a5:read'
        - 'volumes.e0c3436e-2bc7-4648-95dd-26e23c16fbf5:read'
        - 'volumes.247a4cc8-defd-40d9-a5c6-a533c4ac2fa9:read'
        - 'volumes.f6837bee-0445-4fa8-8048-103ccb6ee1b1:read'
        - 'volumes.dfffddcf-7413-418a-96d0-24d813655b40:read'
        - 'volumes.62f31c6c-11b8-452e-af35-4ffd1184e034:read'
        - 'volumes.378ed3bb-1b9d-438f-88ba-c37fa8efe6e4:read'
        - 'categorygroups.257dda99-82b0-451e-b9ee-d87cb9e6fa82:read'
        - 'categorygroups.afe71ecf-202d-4bac-ac38-fa2dab1cb576:read'
        - 'categorygroups.7ad59f7a-3bda-4797-881b-6864c4163373:read'
        - 'taggroups.1355b7a5-0555-43f2-b843-266c7e6a0b2d:read'
  scopes:
    258543b6-fbb9-44a7-9b50-4cc982018b1e:
      name: 'Public Schema'
    476e8ad1-9e12-41f1-a536-5cac24822927:
      name: Search
      scope:
        - 'sections.4971c348-7dcb-44fc-9196-9518ea23c181:read'
        - 'entrytypes.c44f8ad0-a276-485c-bc08-dc87e8a08162:read'
        - 'sections.ad17e7ea-e3b2-4288-bfc2-784778c73be7:read'
        - 'entrytypes.b5d69547-4b48-4b63-beaa-313ddcf0ad5a:read'
        - 'sections.95f82d05-c6e0-4a67-91a0-d99691a4430c:read'
        - 'entrytypes.f77552e9-a2e4-40c4-a6f2-828bb308324c:read'
        - 'categorygroups.257dda99-82b0-451e-b9ee-d87cb9e6fa82:read'
        - 'categorygroups.afe71ecf-202d-4bac-ac38-fa2dab1cb576:read'
        - 'taggroups.1355b7a5-0555-43f2-b843-266c7e6a0b2d:read'

While all that exists, is the public schema, search has been deleted.

Craft Edition: 3.4.25

[Kethatril]

I'm having what seems to be a related problem: When syncing project.yaml onto a clean install of Craft it doesn't create a gqltoken for the public schema at all (though it does sync the public schema itself correctly) and there is no way to create this public token in the new environment if allowAdminChanges is false.

The probable solution to this would be:
When updating / creating a public schema during the project.yaml sync a public gqltoken entry should be created for that schema if it does not already exist as this is not a token you can create manually in the admin unlike other tokens.

[brandonkelly]

@Kethatril Thanks for pointing that out! We are looking into how we can improve that.

[brandonkelly]

As of the next 3.5 release, the public schema’s access settings (Enabled, Expiry Date) will be stored in the project config. So you still won’t be able to directly edit it from environments with allowAdminChanges disabled, but you will be able to make your changes in dev and push them to production.