Requests failing with public schema disabled

[GMConsultant]

Hi James,
After the last update I noticed that the htaccess configuration present in my htaccess file:

RewriteCond% {HTTP: Authorization} ^ (. *)
RewriteRule. * - [e = HTTP_AUTHORIZATION:% 1]

seems no longer necessary ...
Indeed, this creates a Header Authorization problem.

Can you confirm me if the latest changes impact this configuration?

Craft Pro 3.6.12.1
GraphQL Authentication | 1.8.0

[jamesedmonston]

@GMConsultant I'm not overly familiar with htaccess rules – can you explain exactly what that's doing, and why you needed to add it in the first place?

[GMConsultant]

@GMConsultant I'm not overly familiar with htaccess rules – can you explain exactly what that's doing, and why you needed to add it in the first place?

in Craft CMS documentation ( https://craftcms.com/docs/3.x/graphql.html#sending-api-requests ) Querying a Private Schema it's explained:

If you’re unable to query a private schema because of a “missing authorization header”, make sure Craft received it from the web server with a quick post to a test template:

{{ craft.app.getRequest().getHeaders().has('authorization') ?
    'auth token present ✓' : 
    'auth token missing!' }}

Apache strips Authorization headers by default, which can be fixed by enabling CGIPassAuth (opens new window)or adding the following to your .htaccess file:

RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

in version 1.7.0 was necessary...

[jamesedmonston]

@GMConsultant interesting, thanks for the reference. I use nginx for testing locally – so unfortunately didn't run into this issue. Does everything work as expected once removed?

[GMConsultant]

@GMConsultant interesting, thanks for the reference. I use nginx for testing locally – so unfortunately didn't run into this issue. Does everything work as expected once removed?

yes...
I also inform you that at the same time I also updated Craft Cms to version 3.6.12.1

So could it be something in the NEW version of Craft Cms?

[jamesedmonston]

@GMConsultant It's certainly possible that #48 slightly changed the behaviour. If it works fine without the rule I'd go ahead with that 👍

I'll pin this issue so it's visible to other users who may have a similar setup to you.

[GMConsultant]

Hi James,
After a test on production enviroment, if I remove the htaccess directive, the login run OK BUT all others GraphQL has problem:

{
    "errors": [
        {
            "message": "Tried to load an unregistered type \"xxxxx_GlobalSet\". This can indicate both a typo in the query or an issue with the schema used."
        }
    ]
}

If I enable the htaccess directive ( after login ) all are ok.

There is a Authorization header problem into the plugin....

[andrewfairlie]

@jamesedmonston we've noticed this happening since upgrading (I think it happened at 1.9.0) using Nginx via Forge.

We now get

{"name":"Bad Request","message":"Missing Authorization header","code":0,"status":400,"type":"yii\\web\\BadRequestHttpException"}

But looking at the headers sent, we're definitely sending a JWT authorization header

And the authorization header is in the access-control-allow-headers response header

[jamesedmonston]

@andrewfairlie Huh, sorry about that. I'll take another look – strange as we haven't had this issue on any Nginx projects. Are you on the latest version (1.10.3)?

[andrewfairlie]

Yep, 1.10.3. Let me know if I can help at all.

[jamesedmonston]

@andrewfairlie I've narrowed down the issue – will have a fix up shortly!

[jamesedmonston]

@andrewfairlie just to confirm, do you have your public schema enabled or disabled?

[andrewfairlie]

The public schema is disabled.

[jamesedmonston]

Cool, thanks. As an interim fix you can enable the public schema.

[andrewfairlie]

Cool that worked 👍

[jornwildenbeest]

Any updates related to this isue?

[jamesedmonston]

@jornwildenbeest Are you experiencing the issue even with the public schema enabled? I can see where the issue is, but haven't yet found a way of fixing it. In the meantime you can enable your public schema and disable introspection by setting https://craftcms.com/docs/3.x/config/config-settings.html#enablegraphqlintrospection to false in production.

[jornwildenbeest]

@jamesedmonston Sorry for the late response. I found out that my issue was caused by some time difference between the server and the database.

Goodluck with this issue!

[jamesedmonston]

To anyone following this issue, I don't think there's going to be a way to get it functioning with the public schema disabled. There seems to be a race condition where Craft's internal methods are checking for it before I am injecting the schema from the JWT.

I'll add a note to the docs so that it's clear for everyone.

It's worth looking into https://craftcms.com/docs/3.x/config/config-settings.html#enablegraphqlintrospection to disable introspection queries on your production endpoint.

[jacobgraf]

@jamesedmonston I just purchased your plugin and was coming across this issue. I was pulling my hair out and finally found this. I scoured the docs and didn't see ANYTHING about needing to have public schema enabled for things to work. I am guessing you forgot to add it to the docs? If so, can you please do so? Would have saved me about an hour. 😬

Thanks! Everything else has been great so far!