Don't store passwords for WordPress.com

[koke]

Since we're using OAuth2, we shouldn't be storing the user's password. According to RFC 6749 #4.3.1:

The client MUST discard the credentials once an access token has been obtained.

Besides following the standard, this is interfering with #269: if the master password is sent, some parts of the API will fail, even if there's a valid OAuth2 authorization header.

This would probably make obsolete: #488, #422, #965 .

[koke]

Maybe related #1151

[sendhil]

Moving to 4.0.1.

[koke]

Update:

Migrated WPAccount syncBlogs to REST, noticed xmlrpc was missing from /me/sites, fixed it
It works, but /me/sites also returns jetpack sites, and those have the xmlrpc url set to https even if the self hosted doesn’t support https. Added a patch to make jetpack sites use http.

But once that’s fixed, obviously the self hosted xmlrpc won’t take oauth2 tokens, and we don’t have the passwords. We’ll have to hide Jetpack sites for now or move everything to REST.

Hiding jetpack sites proves more difficult than expected. /me/sites doesn’t have any filtering capabilities so we’d have to filter client-side. But the jetpack attribute is always false, looks like a bug.

We can’t get auth cookies from oauth tokens. We just need to be able to preview draft posts and view private sites, so maybe we can figure out a read only auth cookie.

So, in summary:

• Jetpack sites won't work unless we ditch XML-RPC
• We can't hide Jetpack sites until we fix the API
• We still need the password for preview and private sites.

[sendhil]

Moving to 4.1.1.