Error when not having access to pages, needs to login for every action

[John]

Description

As I don't have edit access to WP Pages, I get an error on log in which then requires me to keep logging in for any action.

Prerequisites

• Did you study the README to learn how the feature you are reporting a bug is expected to work?
• Did you go through the When Things Go Wrong process? It covers the steps to review many possibilies
• Did you review the issue tracker to see if this bug is already
  reported or resolved?
• Did you consider that what you are describing may be a feature request? If you answered yes, review both the issue tracker and the FUTURE file to see if the feature request already exists.

Environment

• Regarding the feature that you are reporting: 1 Has it ever worked correctly for you? and 2 If so when, and, what do you think might have changed between then and now? This has always been the case
• What operating system are you running Emacs on? Arch Linux
• How did you install Emacs? package (up to date, also happens with emacs-git native-comp version)
• Do you run Emacs in the GUI or a Terminal? both, usually GUI

Org2Blog Runtime: Org2Blog 1.1.10, Emacs 27.1, Org Mode 9.4.4, MetaWeblog 1.1.1, XML-RPC 1.6.15

Did you go through the org2blog-user-report process? If you did then please paste in the log files here [yes/No]:

When logging in:

Loading page list…
Contacting host: [...]
I’m sorry, I ran into an error and couldn’t do that 🙇. Please view the “*Warnings*” buffer for details.

Error (org2blog/wp): 2020-12-26T17:55:35-05:00
Please report that along with the following details:
(error XML-RPC fault ‘Sorry, you are not allowed to edit pages.’)

Steps to Reproduce

1. log in to a blog where you don't have pages edit access

Expected behavior

For org2blog to ignore this and stay logged in (unless trying to actually edit a page).

Actual behavior

Everything works anyway, like saving a buffer as a draft, but need to log in for every action and always receive this error.

[Grant Rettke]

@podiki Thank you for the detailed report.

Overview

During the last three steps of the login process, Org2Blog tries to load your blog's Categories, Tags, and Page Descriptions. If any one of these fails, then your login is considered to have failed. Since you don't have permission to read the Page Descriptions list, Org2Blog thought you never logged in. Consequently, it keeps asking you to log in again before everything that you do.

You are probably the first person ever to report this usage scenario! :)

Research

Org2Blog must consider two scenarios here:

Sometimes, it can't get the Page descriptions because an error happened in Org2Blog, over the network, or WordPress itself. Something went wrong.

• Sometimes, it can't get the Page descriptions because the user doesn't have permission to edit pages. Nothing went wrong, but from our side of things, it shows up as an error.

I just searched for the WordPress error message:

Sorry, you are not allowed to edit pages.

And I'm not finding too much information on it. We are calling wp.getPageList over XML-RPC, so it must be around there.

In the WordPress source code the error message shows up twice in wp-includes/class-wp-xmlrpc-server.php in two places for wp_getPages and wp_getPageList Based upon the result of checking

if ( ! current_user_can( 'edit_pages' ) ) 
{
      return new IXR_Error( 401, __( 'Sorry, you are not allowed to edit pages.' ) );
}

The error code and message are the same for both of them:

2969:36:		return new IXR_Error( 401, __( 'Sorry, you are not allowed to edit pages.' ) );
3191:36:			return new IXR_Error( 401, __( 'Sorry, you are not allowed to edit pages.' ) );

Note: The message is the unique part of the error, not the number.

Those are the only two places the message shows up in the entire project. It is safe to say that the message alone is a good enough identifier to check if this permission error happened.

Execution

What work will this probably require?

• Update README to explain that you edit posts but not pages (this was new to me).
• During login, check if this error occurs, allow it, and notify the user this is the case.
• Disable auto-completion of Pages

How long will it take?

It seems like a straightforward feature: "Add support for users who can edit posts, not pages." Skimming the source code I see that WordPress has loads of errors that we could be handling, and are not. Fortunately, we can afford to ignore all of them for now.

This work should take 2-4 hours.

Right now, there are tickets in front of this one. Consequently, I can't start it immediately. But: I will eventually.

Resources

If I point out to you where to start and work with you through the process, would you like to work on the fix?

[John]

@grettke Thanks for the detailed investigation and response! Does look like I'm the first to run into this, probably because I've been using Org2Blog to interact with a shared WP blog. As I mentioned, everything works just with more logging in (and could always ask for Pages access, just haven't bothered).

Happy to help! While I generally know my way around Lisp, my elisp has been generally for Emacs tweaks. But I think I can help as well as test. Seems the first 2 bullet points you list will be straightforward, while the third may need some flag/variable/data (just guessing without looking at Org2Blog internals). If you let me know the areas I should look at first, I can give it a go.

[Grant Rettke]

Doing what makes us happy is the most important thing we can ever do. It sounds like you are doing it, and I am glad Org2Blog can be a part of that. It might not be obvious but even just talking through this with you is immensely helpful. Now: digging deeper (yes, deeper) into this topic tonight, I did some reading, and it was interesting (and entirely new to me).

All users have Roles and Capabilities. They are permissions to do things on the blog. In your case, for example, you are allowed to edit Posts but not Pages. Because you are forbidden from modifying Pages: when Org2Blog tries to get the Pages list, WordPress returns an error. The question is how to check if we can do things for your user, and then if you have permission, do it.

My first reaction to this was before doing things in WordPress is to check your Role. That way Org2Blog knows what you can and can't do. That won't work, though, because Role doesn't provide precise enough information. My next thought was to look at the WordPress source code and find some way to check permissions manually. The call current_user_can lets you do that but I don't see any way to access that from the XML-RPC API. Then doh: Org2Blog can only talk over the API and has to use WordPress objects.

The WordPress API sees the world in terms of the "Object Types" Posts, Taxonomies, Media, Comments, Options, and Users. The permission control lets Administrators grant or revoke access to all of them. Therefore is impossible to predict who has permission do what on those objects.

The biggest impact here is that any one user may or may not have permission to edit Posts, Categories, or Pages: the core functionality utilized in Org2Blog. For example in your case you can edit Posts and Categories but not Pages. Well if you read this far, here is something else to consider.

From an API perspective there really isn't a notion of "You are logged in to WordPress, or not". Rather, every time a call is made the username and password are sent. From an Org2Blog perspective, it checks once if you can make a call, and if you can, then Org2Blogs marks you as "Logged In". The issue in this ticket is that Org2Blog assumes that you are logged in only if you edit all of those objects: Categories, Tags, and Pages. That is the bug. The question remains then how to check if you can login and then what you can edit here.

The right way to check (the way we'll try here) is to try and load your profile (for user username and password) with wp.getProfile. The fact (not problem) is that we still don't know what permissions you have, so it obvious yet to check, so for now just try doing stuff and see if it fails. Here are the changes that have to happen:

• Change the check if you are logged in.
• Investigate if your Profile lists your permissions.
• During login try to load the list of Categories, Tags, and Pages. Assume that each one might be disallowed from editing: so don't fail "the login". Instead give a message to the user and proceed.
• Update the auto-complete to account for any of those things missing.

The ball is now in my court to do some research here to understand what is going on. Org2Blog works by knowing just enough to do what it needs and nothing more. There really isn't any reason to dig further than what it needs. Then when stuff comes up like this, Org2Blog learns a little more. This is that process. Where does that leave you?

There is a simple fix: we'll assume for now that if you can see a list of Tags then you are logged in. The reason to try this approach is that it only takes changing two lines of code. So we'll start from there and try to get you up and running without the hassle. In the meantime I'll have this ticket in the list. It won't get resolved immediately, it will eventually.

Here is temporary fix for what you need:

• Download this temporary fix:
  • Find your installation directory for org2blog. If you installed the package then it is probably ~/.emacs.d/elpa/org2blog-xxxx.
  • Rename org2blog.el to org2blog-dist.el
  • Download this temporary org2blog.el into this directory.
• Restart Emacs.

If this temporary fix needs tweaking then we can work on it here.

Let me know how it goes.

[John]

Thanks for the detailed and thoughtful followup. I think this rather simplifies the problem to handle permissions.

I can confirm with a quick test that this works: I get the warning message you added, but Org2Blog doesn't keep asking me to log in. I created a buffer, added it as a draft, all worked without a problem.

(In the meantime I have a separate issue with getting Org2Blog to load, which I've been trying to figure out. I don't think it is on my end, but I could be wrong. I'll open a separate issue.)

[Grant Rettke]

@podiki Sounds good.

[Grant Rettke]

v1.1.13 makes the change. I just tagged it so it should be out soon.