WordPress.org

Make WordPress Core

Opened 7 years ago

Last modified 5 months ago

#21386 new enhancement

XML-RPC needs a user permission method

Reported by: markoheijnen Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: XML-RPC Keywords: needs-patch
Focuses: Cc:
PR Number:

Description

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.

Attachments (1)

21386.diff (706 bytes) - added by markoheijnen 5 years ago.

Download all attachments as: .zip

Change History (23)

#1 @daniloercoli
7 years ago

  • Cc ercoli@… added

#2 @markoheijnen
7 years ago

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

#3 @maxcutler
7 years ago

  • Cc maxcutler added

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?

#4 @markoheijnen
7 years ago

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

#5 @daniloercoli
7 years ago

  • Cc ercoli@… removed

#6 @daniloercoli
7 years ago

  • Cc ercoli@… added

#7 @nacin
7 years ago

  • Keywords punt added
  • Type changed from defect (bug) to enhancement

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?

#8 @koke
7 years ago

  • Cc koke added
  • Keywords mobile added

#9 @markoheijnen
7 years ago

  • Keywords punt removed
  • Milestone changed from 3.5 to Future Release

#10 @danielbachhuber
7 years ago

  • Cc danielbachhuber added

#11 @koke
7 years ago

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?

#12 @markoheijnen
7 years ago

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.

#13 @nacin
7 years ago

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
5 years ago

#14 @markoheijnen
5 years ago

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.

#15 @nacin
5 years ago

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?

#16 follow-ups: @markoheijnen
5 years ago

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.

#17 in reply to: ↑ 16 ; follow-up: @rmccue
5 years ago

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.

#18 in reply to: ↑ 17 ; follow-up: @markoheijnen
5 years ago

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?

#19 in reply to: ↑ 16 @maxcutler
5 years ago

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.

#20 in reply to: ↑ 18 @rmccue
5 years ago

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 :)

#21 @markoheijnen
5 years ago

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.

#22 @chriscct7
4 years ago

  • Keywords needs-patch added; mobile removed
Note: See TracTickets for help on using tickets.