XML-RPC needs a user permission method

[markoheijnen]

At this moment when calling a XML-RPC method you will receive a error when the user can't do that method.

What would be better if there is a way an app can retrieve the user permissions and act on that without the need to call the method.

[markoheijnen]

As an addon on this we should have a way that wp.getPostTypes only returns post types a user can add/edit to.

[maxcutler]

See #18428 for XML-RPC user management methods. It has wp.getUser and wp.getUsers methods that return capabilities. Is there more that you think is needed?

[markoheijnen]

That almost solves the problem. I do think we should have an option in wp.getPostTypes so it only returns the post types the user can add.
So some of the capability issues will be solved by the XML-RPC server instead of in the app

[nacin]

This is an enhancement.

#18428 will not end up returning capabilities.

I don't know the best way to solve this. No action here, either. Punt?

[koke]

For now, our use case for this would be ​http://ios.trac.wordpress.org/ticket/1475

If the user can't publish posts but save them (contributor?) the UI shouldn't say "Publish"

What's the reason behind wp.getUser not returning capabilities? Would adding wp.hasCap(blogId, username, passsword, cap) make sense if we don't want to return the full list?

[markoheijnen]

You can read #18428. Probably something to do with security. From my point of view it doesn't matter that much but you should ask Nacin about this.

[nacin]

Fairly little to do with security. Rather, returning a raw array of capabilities and roles doesn't help when it comes to actually processing capability. No filters are run, nor would map_meta_cap() get a chance to do its magic. Raw role names could go a long way for basic sanity checks, which is why those almost made it in.

[markoheijnen]

I'm currently thinking about closing this issue. The thing why this ticket was created was because of the issue koke mentioned. The problem here is that map_meta_cap() doesn't do it' magic so this doesn't work. For that I would close this ticket.

But what we could do however passing some information when retrieving the post types. Check 21386.diff for the idea. It only shows some basic information where we still could add edit_others_posts.

[nacin]

At this point in the game, our efforts should probably be focused on the REST API (and getting this right there), and if we end up with something we like, we could maybe bring it back into the XML-RPC API. It does bother me that the mobile apps don't know when a contributor can't publish, but that seems to be the primary (only?) real use case that's important to offer a solution for. Maybe a flag on wp.getPost?

[markoheijnen]

I totally get that. Thats what I'm cleaning the XML-RPC component a bit and see if there is something useful in it.
Reason why I created this was that contributors also see pages because of the same reason.

I believe that getPostTypes is the right method since someone could retrieve all the post types to build up a menu (always wishful thinking for our mobile apps). I will create a ticket for the REST API to look into this too. They return get_post_types() which also generates the same problems.

[rmccue]

Replying to markoheijnen:

I believe that getPostTypes is the right method since someone could retrieve all the post types to build up a menu (always wishful thinking for our mobile apps). I will create a ticket for the REST API to look into this too. They return get_post_types() which also generates the same problems.

FWIW, you can get all the permissions you (as a logged in user) have via a request to your user information (GET /users/me) which simply returns $user->allcaps.

[markoheijnen]

Replying to rmccue:

Replying to markoheijnen:

I believe that getPostTypes is the right method since someone could retrieve all the post types to build up a menu (always wishful thinking for our mobile apps). I will create a ticket for the REST API to look into this too. They return get_post_types() which also generates the same problems.

FWIW, you can get all the permissions you (as a logged in user) have via a request to your user information (GET /users/me) which simply returns $user->allcaps.

And then "no filters are run, nor would map_meta_cap() get a chance to do its magic." right?

[maxcutler]

Replying to markoheijnen:

I believe that getPostTypes is the right method since someone could retrieve all the post types to build up a menu (always wishful thinking for our mobile apps). I will create a ticket for the REST API to look into this too. They return get_post_types() which also generates the same problems.

wp.getPostTypes already filters based on caps. Combined with wp.getUser(s) which can return an array of roles, a client can get a pretty good approximation of what the user can do with regards to posts. It's not perfect, since with some substantial cap logic a plugin/theme could violate assumptions that a client is making, but for the 90% case it's adequate. I don't know why the official apps haven't gone down this road (likely cause they've never seriously adopted the 3.4/3.5 improvements), but I've used it with success for my own (as yet unpublished) app.

I agree with nacin's comments here, and I don't think it's worth modifications to XML-RPC at this point. For the REST API you can reevaluate if you'd like.

[rmccue]

Replying to markoheijnen:

And then "no filters are run, nor would map_meta_cap() get a chance to do its magic." right?

Correct; as far as I'm aware, meta caps only exist in the switch statement inside map_meta_cap, not anywhere else.

You don't necessarily have edit_post on a post until the post is accessed, so you can't really check it in the general case. We'll probably add some extra fields somewhere to indicate these things (likely metaparameters on links or something).

This was just to note what the current state of the code is in the REST API :)

[markoheijnen]

External apps should not guess based on caps what to do. To me that should be a property that is true/false.
I do disagree that modification to XML-RPC are not worth it. It will still be used for a while and something like this will increase the UX of the mobile apps.