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)?