Yes, this plugin is compatible with V2. As a matter of fact, all tests are done with v2.
Ensure that you are not logged into WordPress normally if you are want to us REST API with WP OAuth Server.
- Log out of WP
- Try the REST API endpoint with the access token
Thread Starter
Pavlo
(@pavloopanasenko)
Than maybe I’m doing something wrong. Maybe you could recognize where the mistake is.
My Steps:
– successfully obtain a an access_token with following request
POST /?oauth=token HTTP/1.1
Authorization: Basic Q0RQZzRPYXhTZENxc2VBWUl0aUd2eFdYdk1FMFQ3OnB3TGVOUDJZblZiWmxEZVdDV3BWRFZ0elNZbXhaZw==
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=263793c289e388c49599ab9def797b53
Host: www.myhost.com
Connection: close
User-Agent: Paw/2.2.5 (Macintosh; OS X/10.11.3) GCDHTTPRequest
Content-Length: 63
grant_type=password&username=myuser&password=mypass
– when trying to make a call to GET https://www.myhost.com/wp-json/wp/v2/users/me?access_token=iwkl3yfwuv5fr5c7pz3ko8mlftjhsnddmnre1qc0 I get an 401 error You are not currently logged in.
Any ideas what could be wrong here?
Thread Starter
Pavlo
(@pavloopanasenko)
Yes, I already logged out. Was trying different user.
Maybe clearing cookies could help?
There is know issues when using different authentication types at the same time in the same machine.
Clearing cookies may help but I really do not think that would work. What is your system specs? I would like to try to replicate the issue just to see first hand.
Thread Starter
Pavlo
(@pavloopanasenko)
Clearing cookies didn’t help.
System Specs: MAMP v3.5 PHP 5.6.10, WP 4.2.2
Actually the WP installation I have is quite complicated and heavily customized. Not sure if you can recreate it.
Maybe you could give me and entry point (file/path:string_number) where the access_token parameter is grabbed from the url? Debugging might help and I will tell you what I found.
Looks like no action is fired at all when access_token is added to the url.
Thread Starter
Pavlo
(@pavloopanasenko)
Here’s some more info from Server Status tab in admin area:
Apache/2.2.29 (Unix) mod_wsgi/3.5 Python/2.7.10 PHP/5.6.10 mod_ssl/2.2.29 OpenSSL/0.9.8zg DAV/2 mod_fastcgi/2.4.6 mod_perl/2.0.9 Perl/v5.22.0
Thread Starter
Pavlo
(@pavloopanasenko)
Looks like createFromGlobals() function ( app/plugins/oauth2-provider/library/OAuth2/Request.php:192 ) is doing that but it does’t fire on GET request.
The entry point for REST uses the filter determine_current_user. This is where WP OAuth Server checks for the access token and assigns a user id if the token is valid.
In order for this to work, the access token must have been granted to a user ID (using user credentials or auth code grant types). Grant types like client credentials do not assign a user ID thus making the access token not valid in REST API.
Thanks for the information. I am going to look and see if I can not come up with something.
Thread Starter
Pavlo
(@pavloopanasenko)
Looks like add_filter( 'determine_current_user', array( $this, '_wo_authenicate_bypass' ), 21 ); runs after determine_current_user filter is fired. Thus _wo_authenicate_bypass() function is never executed.
Thread Starter
Pavlo
(@pavloopanasenko)
I spent all day debugging and found what was wrong.
One of the installed plugins (let it be APlugin) needs to determine if user is logged in when APlugin is loaded. Function is_user_logged_in() is unavailable while plugins are loading. To enable this function APlugin includes pluggable.php which sets current user to zero.
Plugin loading order is alphabetical which means that by the time your plugin is loaded APlugin already set current user to zero.
Believe it or not but renaming your plugin to AWP OAuth Server will improve its compatibility. 🙂
I hope it will help you in development. WordPress has its ways to surprise.
If you need more information about this case, feel free to ask. I’m happy to help.
Well thanks for the crazy info :p. I think I have an idea what I can do to make this better for the future releases.
Thread Starter
Pavlo
(@pavloopanasenko)
Yes the info is crazy indeed. 🙂
Will be glad to hear your idea. Not in details of course, just general direction of thinking.
It’s interesting how people deal with issues like this.
Basically is_user_logged_in() is set after _deturmine current urser filter (in other words it uses deturmine_current_user). Sooo. if we just check current_user then we should have an ID of the user based on the cookie information ect.
Thread Starter
Pavlo
(@pavloopanasenko)
Could be a good point.
Thanks for your time and good luck with new releases!
Closing the topic.
