Can't get auth working, 403 Forbidden Error

[ViktorPontinen]

Hi,

Basic Auth just doesn't work for me, been stuck for days and feels like I have turned over every stone there is to find a solution.

Some info about my hosting(phpinfo();):

PHP Version 5.6.8
Server API: CGI/FastCGI

I have added the below to .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
</IfModule>

And doing a var_dump on below shows correct values.

$_SERVER['PHP_AUTH_USER']
$_SERVER['PHP_AUTH_PW']
$_SERVER['HTTP_AUTHORIZATION']

Now to the issue. I get 403 Forbidden error using both postman and postman package sending the following information to the server:

POST /wp-json/posts HTTP/1.1
Host: mysite.com
Authorization: Basic XXXXXXXXXXXXXXX
Cache-Control: no-cache
Postman-Token: 6bb61e83-0bec-afcd-9b5d-605340683730
Content-Type: application/x-www-form-urlencoded

title=Test+1&content_raw=Test+2222&status=publish

The response I get:

[
    {
        "code": "json_cannot_create",
        "message": "Sorry, you are not allowed to post on this site."
    }
]

Anyone who has any idea or can point me in the right direction?

[ViktorPontinen]

Finally made some progress.
The error for me was on line 368 in plugin.php of the main WP API plugin.

It seems like the cookie authentication is running after the basic authentication and then reseting the wp_current_user back to 0 if there is no nonce sent with the request. Or perhaps the basic auth plugin is not even getting hooked on during the authentication process, which seems unlikely to me.
Or maybe you are supposed to send a nonce even with Basic Auth requests, which seems strange to me.

[ViktorPontinen]

Did some more digging and narrowed it down to the HTTP_AUTHORIZATION variable.
Apparently the settings that I did to my .htaccess was not enough and one more line was needed:
SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

So try that if you use FastCGI and have trouble to get it to work.

[urre]

@ViktorPontinen Hi, i have problems with this aswell. Get 403 on POST request using Basic Auth. Do you know how to set this up in Nginx? I've added fastcgi_param HTTP_AUTHORIZATION $http_authorization; but no difference. Wonder if i'm doing something else wrong.

[ViktorPontinen]

@urre Hi, the basic rule did not work for me, had to use
SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0
which I sadly don't know how to convert to Nginx.

You could try
fastcgi_param PHP_AUTH_DIGEST $http_authorization;

[urre]

@ViktorPontinen thanks. How did you make the POST request? i'm not sure i¨'m doing it correctly.

i've tried:

$.ajax({ 
    dataType: "json",
    type : "POST",
    url: 'http://mywebsite.se/wp-json/posts/',
    headers: { 
        // 'Access-Control-Allow-Origin' : 'all',
        'Authorization': 'Basic '+btoa(wp_username+":"+wp_password),
        "Content-Type": "text/plain; charset=utf-8"
},
...

[ViktorPontinen]

Using Postman extension for Chrome.
Like the first post.

POST /wp-json/posts HTTP/1.1
Host: mysite.com
Authorization: Basic XXXXXXXXXXXXXXX
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

title=Test+1&content_raw=Test+2222&status=publish

What kind of error do you get?

[urre]

@ViktorPontinen I made a misstake. Working now. Thanks.

[dooch]

Hi Guys,

I still have issues getting this working. Think it might have something to do with my .htaccess file; here is an extract from my website.

There are two lines with are commented out, when they are activated the api calls responded with a 404 error. Any ideas?

# BEGIN W3TC Browser Cache
<IfModule mod_deflate.c>
    <IfModule mod_headers.c>
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
        AddOutputFilterByType DEFLATE text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/json
    <IfModule mod_mime.c>
        # DEFLATE by extension
        AddOutputFilter DEFLATE js css htm html xml
    </IfModule>
</IfModule>
# END W3TC Browser Cache
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
# RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
# SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

[lkraav]

http://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Worked for us.

[gmartinez]

Hi there, also run into this issue and found myself having to perform a small tweak to the plugin, I wonder if it is not something that is worth merge in, I will let you guys decide.

Basically I found myself having to parse $_SERVER['REDIRECT_HTTP_AUTHORIZATION'] to feed $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW']

I added the lines below just before line that reads "// Check that we're trying to authenticate"

/**
* The following allows Basic Auth support when PHP is running as any form of CGI
* In order for this to work one needs to add : "SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1" to the .htaccess
*/
if (isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])) {
    list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':' , base64_decode(substr($_SERVER['REDIRECT_HTTP_AUTHORIZATION'], 6)));
}

One more, in my case both

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

worked for the basic auth but my site started to throw lots of 404, on the other hand

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

did the trick.

[younes0]

does this plugin works with the V2?

[tdapper]

Havin a similar problem. Adding the aforementioned rules to .htaccess apparently helps in passing through the Basic Auth info. The API now returns stuff that makes me think it recognizes my login (meaning that e.g. the /wp/v2/users/me endpoint returns something sensible), but even though the user I'm logging in as has admin rights, I am getting 403 errors whenever I'm trying to access hidden posts.

The code change proposed by @gmartinez doesn't help. Would be great if @ViktorPontinen could share what the problem in the WP-API exactly was (and whether the fix was vor the v1 or v2 API).

Does anybody take care of this plugin? I'm working on connecting our software products with the website and Basic Auth is so much less painful in this regard (at least until a two legged OAuth 2.0 becomes available). Also since I'm controlling both sides, I can totally ensure that https is used. Wouldn't it even make sense to have a switch in the WP-API plugin that allows to only accept API calls via https and not http? OK, I'm getting off topic....

[younes0]

@tdapper I had success with WP-API1 only. V2 is still in beta anyway.
I encountered problems with Basic-Auth and Goodbye Captcha so I used OAuth

[ViktorPontinen]

@tdapper Im 90% sure it was on v2, which exact version I don't recall.
The problem was solved for me by adding
SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0
To .htaccess

Try to do to a var_dump on the $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] to check if the values you send get passed correctly.

Sadly I don't remember much more, was long time ago I last worked with this.

[rmccue]

Does anybody take care of this plugin? I'm working on connecting our software products with the website and Basic Auth is so much less painful in this regard (at least until a two legged OAuth 2.0 becomes available). Also since I'm controlling both sides, I can totally ensure that https is used. Wouldn't it even make sense to have a switch in the WP-API plugin that allows to only accept API calls via https and not http? OK, I'm getting off topic....

We want to discourage using this plugin heavily; even with HTTPS, it encourages the antipattern of giving your password to a different site.

99% of the the problems here are server configuration issues; the htaccess rules aren't needed with most sites, only sites that don't correctly pass the authorization header/variables to PHP. This is something we can't really handle in a generic way, so try the solutions suggested here. :)

[tdapper]

Hi @rmccue,

thanks for taking the time to chime in.

I understand the the use of Basic Auth is generally discouraged and I am totally with you, also in regard to discouraging the antipattern. However, since WP-API (gloriously) opens up a whole new world of applications, there are scenarios in which the other thing that talks to WP isn't a different site. We are planning to have a bunch of pure command line scripts and direct access to the site via our standalone C++ applications (e.g. for license activation) that don't work well, don't work at all or provide a horrible user experience (or any combination thereof) when being used with OAuth 1.1a. Again, I am totally with you when you are talking about other sites, but in standalone applications or command line scripts where browser interaction for the validation step is cumbersome or impossible will be future scenarios that people will like to tackle, even if it's just for internal purposes or testing.

I also see that 99% of the problems here are server configuration problems, I'm not sure whether my problem is one of those, though. The server configuration problem I did have was that the authorization doesn't get passed through to PHP when it's running as a CGI, which is the case for our hoster. This problem could be solved, however, with the workaround info found in this (and other) issue threads.

The real problem is that WP-API is apparently recognizing me as a user (since the /wp/v2/users/me endpoint produces sensible output), but still doesn't grant me the privileges to see e.g. invisible posts doesn't appear to be a configuration problem. Particularly since the problem has come up in a few places (here and there was another thread that I shall try to recover from my history) where code changes had to be applied to either the Basic Auth plugin or WP-API.

I'd dig into it myself, but unfortunately web development is not my strong side so it's going to take me a while.

Best
Timm

[rmccue]

We are planning to have a bunch of pure command line scripts and direct access to the site via our standalone C++ applications (e.g. for license activation) that don't work well, don't work at all or provide a horrible user experience (or any combination thereof) when being used with OAuth 1.1a.

There's a couple of ways around this; the primary one is out-of-band handling. It's not ideal, but it's not a terrible flow for command line applications in particular.

That said, the team working on Two Factor Auth in WP core has looked at user access tokens (similar to how GitHub does it) previously, and I wouldn't be adverse to supporting those.

still doesn't grant me the privileges to see e.g. invisible posts

I'm not sure exactly what you mean by "invisible", but I suspect you mean draft posts? Note that authenticating with the site doesn't change responses by itself, you also need to use the edit context (that is ?context=edit) in a lot of places, including draft posts.

[tdapper]

Hi @rmccue,

thanks again for the quick reply. Out-of-band handling is exactly the type of user experience I was referring to "horrible user experience" earlier. While this might be ok for our internal command line scripts, it is out of the question for the standalone applications we sell to end users.

While I really value your commitment to ensuring maximum safety, my feeling is that not to support Basic Auth (or something similar or even just a two legged OAuth 2) will impose a serious practical limit on what can be done with the API beyond different web services talking to each other. Again, I totally agree with you when connecting different web services, but in this case both endpoints are under our full control (since we do the website and the standalone application) and as soon as WP-API gains more traction, these cases will keep popping up.

Regarding "invisible": I was using wrong terminology. I didn't mean a Draft, but I meant a posting that was published as "private". Since it is, while being private, still published, I'd assume that the edit context isn't needed. And again, I am making the assumption that the WP-API does recognize me as a user, since the /wp/v2/users/me endpoint does show my user info, which I assume it wouldn't. And since I'm testing with my user that has admin rights, I should be able to see that private post (I can see it when using the regular WordPress web frontend.

Best
Timm

[rmccue]

Out-of-band is definitely not the greatest, but for your other standalone applications, could you use a custom protocol as per the guide?

I totally get the need for this, but Basic auth is not something that will ever be encouraged or fully supported outside of development. A simpler key-based authentication system (or OAuth 2, which is essentially a standardised spec of this) is much more likely. As you may have noticed from the OAuth 1 plugin though, we don't have a huge amount of spare time, so we need to prioritise and focus on OAuth 1 right now.

Keep in mind however that the entire authentication system in WP is flexible, which is how the Basic and OAuth plugins work. If you need something different, you can always make another plugin to do what you need. Although we're stretched for time, we're always happy to review code too, :)

For private posts, I think you need to specify that you actually want those back with filter[post_status]=publish,private - responses don't typically change just because you're authenticated (although unauthorized error responses will obviously change).

[tdapper]

I'm not locked down to any particular authentication scheme and won't shed a tear about dropping Basic Auth when there's a better alternative. However, we have a similar problem like you regarding development resources, so rolling our own appears impractical (at least currently), especially since we're not exactly security specialists so there's a good chance a custom implementation we do will have more security holes than a really large chunk of swiss cheese. I'd probably try waiting for two legged OAuth 2 to become available (or us suddenly having the time and capabilities to implement it) and try to get along with Basic Auth until then.

As for the actual problem: I tried the post status filter, but it didn't change anything. Also I'm wondering whether this would also apply when I'm trying to get a post directly through an endpoint like wp-json/wp/v2/posts/88556 (which is what I did). If feels to me as if the filter would only make sense when using it on something like wp-json/wp/v2/posts.

[rmccue]

As for the actual problem: I tried the post status filter, but it didn't change anything.

Hmm, strange. Can you file an issue over on the main API repo please? Tends to get more traffic than here, so someone may be able to help sooner :)