policy bug with allow, deny in v6.5.2

klagreca

Hi Vasyl, Tony and I are able to reproduce a new bug with access policies in v6.5.2, plus v5.4.0.

Here's the test case:

Our policy is titled: "disable post editing unless tag set in user profile"
we update AAM from 6.4.3 to 6.5.2
and AAM Plus Package update from 5.3.4 to 5.4.0
The first part of the command works (the "deny"), but the second part seems to fail (the "allow").

Policy:

{
    "Version": "1.0.0",
    "Dependency": {
        "wordpress": ">=5.3.2",
        "advanced-access-manager": ">=6.2.2"
    },
    "Statement": [
        {
            "Effect": "deny",
            "Resource": [
                "PostType:post:posts",
                "PostType:building:posts",
                "PostType:testimonial:posts",
                "PostType:programs:posts",
                "PostType:person:posts",
                "PostType:department:posts",
                "PostType:tribe_events:posts",
                "PostType:page:posts",
                "PostType:dws_file:posts"
            ],
            "Action": [
                "Edit",
                "Delete",
                "Publish"
            ]
        },
        {
            "Effect": "allow",
            "Enforce": true,
            "Resource": "Term:post_tag:%s:posts => ${USER_META.editable_post_tags}",
            "Action": [
                "Edit"
            ]
        }
    ]
}

This worked previously. Please let me or Tony know if we can help debug.
Thanks! Kris

vasyl

klagreca Kris,

Can you please also let me know what information you have in the usermeta editable_post_tags. You can quite literally copy & paste the data that is in the database for this user meta key.

Meantime I'll try to reproduce the issue.

Thank you,

vasyl

klagreca I was able to spend a bit more time and tried to reproduce your situation and I can see the problem.

So, first of all, Plus Package 5.4.0 slightly changed the way it executes access settings inheritance mechanism and there is a valid reason why your policy is not working. Standard WordPress post (post type post) always belongs to at least one category (typically "Uncategorized"). In your case, you are targeting post tags and basically stating that any post that is tagged with one of the tags in user meta editable_post_tags is allowed to be managed.

All is great, HOWEVER, in your situation, any post has at least two terms assigned to it: "Uncategorized" term and some tag. AAM sees that your post has two or more categories and merges access settings with default preference "deny". Because the "Uncategorized" category inherits access settings from PostType post, the final access settings for any post will state that access is denied to edit it.

Solution

First, you need to redefine access settings merging preference to honor "allow". You can do that with ConfigPress:

[aam]
; Manage access preference to hierarchical terms (categories)
core.settings.term.merge.preference = "allow"

While I was investigating the issue, I've discovered a bug that is described here. It was fixed in 5.4.1 release that is about to be published.

Keep me posted.
Vasyl

klagreca

Hi Vasyl,
Thanks so much for the quick turn around! That actually fixed that issue, but cause another policy to break. The below policy is attached to "visitors" and restricts them from seeing content that is tagged "Intranet." This policy now no longer works.


{
    "Version": "1.0.0",
    "Dependency": {
        "wordpress": ">=5.3.2",
        "advanced-access-manager": ">=6.2.2"
    },
    "Statement": [
        {
            "Effect": "deny",
            "Enforce": true,
            "Resource": [
                "Term:post_tag:intranet:posts"
            ],
            "Action": [
                "Read"
            ],
            "Metadata": {
                "Redirect": {
                    "Type": "login"
                }
            }
        }
    ]
}

vasyl

klagreca if you redefined access settings merging preferences to "allow", then most definitely any post that has at least one category or another tag assigned will have access to posts that have "intranet" tag.

In your case, you should consider to avoid using ConfigPress settings and redefine your access policies. In this Github issue I've mentioned about new type of resource s that is supported with the latest AAM update https://github.com/aamplugin/advanced-access-manager/issues/121.

So in your case, remove ConfigPress settings and update the first policy to something like this:

{
    "Version": "1.0.0",
    "Dependency": {
        "wordpress": ">=5.3.2",
        "advanced-access-manager": ">=6.2.2"
    },
    "Statement": [
        {
            "Effect": "deny",
            "Resource": [
                "PostType:post:posts",
                "PostType:building:posts",
                "PostType:testimonial:posts",
                "PostType:programs:posts",
                "PostType:person:posts",
                "PostType:department:posts",
                "PostType:tribe_events:posts",
                "PostType:page:posts",
                "PostType:dws_file:posts"
            ],
            "Action": [
                "Edit",
                "Delete",
                "Publish"
            ]
        },
        {
            "Effect": "allow",
            "Enforce": true,
            "Resource": [
                 "PostType:post:taxonomy:category:posts",
                 "Term:post_tag:%s:posts => ${USER_META.editable_post_tags}"
             ],
            "Action": [
                "Edit"
            ]
        }
    ]
}