Feasible to pass application password in request body or query string?

[mnelson4]

Some servers ignore/block/remove the "Authorization" header from requests. See WP-API/Basic-Auth#1, which I know is a different plugin, but it also sends the important authentication data in the SAME header as this one: the authorization header.
So if we were to use application passwords in a production system, it wouldn't work for many users because the Authorization header is ignored/blocked/removed from requests for some servers. Ugh.

SO, is it feasible to also send the application password in the request body or querystring? (I specified "also" because I heard some servers ignore request bodies on DELETE requests, so in that case it might be nice to also have the header as a fallback)

[georgestephanis]

Maybe if we add in support for an X-Authorization header that populates the $_SERVER superglobal params if they're not set already. Unsure.

[mnelson4]

Yeah that's kinda what I suggested on WP-API/WP-API#2512 (comment), but didn't get a direct reply to that suggestion.

I think the issue is that some servers ignore the "Authorization" header in order to do more caching (because if the "Authorization" header is set, it indicates the webserver shouldn't cache the result; and so if they remove the "Authorization" header they can cache whatever the server generates just fine). So we can easily put the authorization data in a different header or somewhere else, but the trick is that we still need to make sure webservers realize these results shouldn't be cached.

I suppose the problem with putting authentication data in a custom header is that webservers won't realize the response shouldn't be cached. Yes requests can contain the "Cache-control" header to request the server not cache the response, but they can ignore that.

If requests contain a cookie most servers will know that means it shouldn't be cached (although, technically, they can ignore that too).

What about checking for the authorization string in the normal "Authorization" string AND in a custom cookie? If the server removes the "Authorization" string, they might leave cookies alone. This cookie would contain the data needed to authenticate the user AND indicate the request can't be stored.

[georgestephanis]

I'll need to ponder this a bit longer to give a full response, but the problem with this is that when php is running in fastcgi mode, apache handles the authentication stuff, so by default it doesn't pass through the authentication tokens to php unless otherwise required -- that's what I added 16af809 for last month, to test for this sort of server configuration and notify users if that's the case.

It can be corrected with a htaccess rule.

[mnelson4]

It can be corrected with a htaccess rule.

Yeah that's what our users are needing to do whenever they encounter this (we have mobile apps that interact with our custom endpoints in the WP API). But of course that's pretty complicated, especially when some other plugins might be playing with htaccess.

What's more, I think today we encountered an interesting situation: we suspect a web proxy is operating and removing whatever http headers it wants (eg the "Link" response header is getting removed, and the "Authorization" request header too; we suspect a proxy because there's a "Via" response header). In situations like this the .htacces fix won't work because it's not apache or nginx that's removing the authorization header, it's a separate proxy server (and so I suppose the fix would need to be done by whoever is maintaining the proxy server which might be on a different machine and maintained by a different person)

So that's why using a cookie or something might be nice

[Lobosque]

I have the same problem as @mnelson4
Although tweaking .htaccess is easy for most developers, it is a challenge for non-techies, which accounts for a good amount of wordpress users.
I reported the problem with dropping the Authentication header to the core team: https://core.trac.wordpress.org/ticket/39224 but it looks like this is not an issue for the next few versions.

[georgestephanis]

I just added some code to master that will enable pulling from an alternate location, in concert with the following code immediately following RewriteEngine On

RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]

I've tested it and it works, I just hesitate to add a totally new header, but would be very open to considering a PR if someone else wanted to write it for X_WP_AppPass header or something. Very undecided on the name at the moment.

But for now, closing this out.

[mnelson4]

Thanks! So client code shouldn't need any adjustments for this to work, just the ht access file will need tweaking right?

[mnelson4]

An update: we recently stumbled on how Woocommerce handles this problem for their REST API: they allow passing authorization data in the query string.

Occasionally some servers may not parse the Authorization header correctly (if you see a “Consumer key is missing” error when authenticating over SSL, you have a server issue). In this case, you may provide the consumer key/secret as query string parameters instead.

See https://woocommerce.github.io/woocommerce-rest-api-docs/#authentication-over-https