Change the token check to use the passed user_id

[georgeh]

The wpcom servers do not always retrieve the master user_id when signing requests. When the wrong user_id is sent over, the request will fail. During the oauth connection flow, this would result

This change uses the user_id that is encoded in the token format to check requests.

Fixes #5847

Changes proposed in this Pull Request:

• Update wpcom token checks to use user_id encoded in the token instead of the master_user token

Testing instructions:

• Find a blog where the Jetpack_Options::get_option( 'master_user' ); is not the same as the id returned by public-api's Jetpack_Data::get_access_token_by_blog_id_user_id( $someBlogId, JETPACK__ANY_USER_TOKEN )
• Attempt to connect an Oauth application to that blog
• Confirm that the Oauth flow is successful

Proposed changelog entry for your changes:

[lezama]

Thanks for working on this @georgeh!

I think this is safe to go but let's wait on @mdawaffe advice!

[mdawaffe]

I think this is just one more (the last?) holdover from when only one user per Jetpack site could be connected to WordPress.com.

As you point out, on WordPress.com, we sometimes look for any non-blog token to sign the request. This ensures that the site is fully connected. (Having only a blog token could mean the site is in some half-way state.) In ye olde times, looking for any non-blog token would always return nothing or the master user's token. So on the Jetpack side, we could always check JETPACK_MASTER_USER.

Those days are long gone, and we can't depend on any specific behavior when looking for "any non-blog token".

This change makes sense, though it feels a little odd to use an arbitrary (even if now consistent) user token to do all this. I don't think it has any security concerns, though. Something may break if the Jetpack site loses its half of the connection for that user, though, and WP.com still tries to sign things with that user's details.

@lezama, @ebinnion, I take it SSO and this patch play nicely together?

At any rate, looks good to me.

[zinigor]

OK, so I think that I'm either testing it incorrectly, or there's a problem. My setup is that I have a Jetpack site with two connected administrators. One of them is the master user, the other one is just an administrator.

So when I try to publish a document from StackEdit.io, it works with the master user, but doesn't work with the second user. By using error_log in class.jetpack.php I can say that $environment seems to always have 1 as the user ID, therefore get_access_token always returns the token for the master user.
Can you tell me if my testing is wrong, or is it a problem with the code?

[zinigor]

OK, finally got it to work by switching a master user by installing Jetpack 4.1 :) Works well, now for all users, not only for the master.