aamplugin / advanced-access-manager Goto Github PK

Let's say you have Level 1/Level 2/Level 3 hierarchy of terms. If Level 1 has settings defines, they are not displayed for Level 2 or _Level 3

_ as they should

Current, the only way to issue refreshable token is to manually generate it through AAM UI. Would be nice to have the ability to issue it also through RESTful API during authentication process.

In order to prepare the Access Policy that emulates multisite super admin, AAM has to have the ability to hook into the site's option site_admins.

Currently, there is no way to define "Access Denied Redirect" rules with Access Policy. That will be a great addition to the policies.

Only the first role assigned to a user is checked.
The line of code responsible for this is in the file Application\Shortcode\Strategy\Content.php:60

I have replaced the line
$user = array((string)AAM::getUser()->ID, AAM::getUser()->roles[0]);
by
$user = array((string)AAM::getUser()->ID);
array_push($user, ...AAM::getUser()->roles);

That fixes it for me!
But I have little to no experience coding in PHP, so don't know if this is the right way.

Apparently allcaps is no completely correct place to populate user caps with access policy. More specifically additional investigation is needed for the Service/AccessPolicy code between lines 632-640:

foreach($caps as $cap => $statement) {
            $effect = (strtolower($statement['Effect']) === 'allow' ? true : false);
            $wp_user->allcaps[$cap] = $effect;

            // Also update user's specific cap if exists
            if (array_key_exists($cap, $wp_user->caps)) {
                $wp_user->caps[$cap] = $effect;
            }
}

Following access policy does not work when attached to the user:

{
    "Version": "1.0.0",
    "Dependency": {
        "wordpress": ">=5.3.2",
        "advanced-access-manager": ">=6.3.0"
    },
    "Statement": [
        {
            "Effect": "allow",
            "Resource": [
                "Capability:read",
                "Capability:level_0",
                "Capability:wpseo_manage_options"
            ]
        }
    ]
}

If website does not have correctly regisred license key, this PHP notice is triggered.

The problem is in these following lines of code:

public function isHidden($hidden, $screen, $id, $object)
{
        $options  = $object->getOption();
        $wildcard = false;
        $manager  = \AAM::api()->getAccessPolicyManager();
        $key      = strtolower("{$screen}|{$id}");

        if (!empty($manager) && !array_key_exists($key, $options)) {
            if (in_array($screen, array('widgets', 'dashboard', true))) {
                if ($manager->isAllowed('Widget:*') === false) {
                    $wildcard = true;
                }
            } else {
                if ($manager->isAllowed('Metabox:*') === false) {
                    $wildcard = true;
                }
            }
        }

        return $hidden || $wildcard;
}

The in_array function receives the incorrectly defined set of arguments.

The export feature does not export all the policies that are created. Consider adding this missing functionality to the AAM core.

Things are getting quite funky when Yoast plugin is activated. The backend menu and top admin toolbar have unpredictable behavior if there are any access settings defined for those.

Here is the access policy that causes this behavior:

{
    "Version": "1.0.0",
    "Dependency": {
        "wordpress": ">=5.3.2",
        "advanced-access-manager": ">=6.3.0",
        "${CONST.AAM_PLUS_PACKAGE}": {
            "Name": "Plus Package",
            "Version": ">=5.2.3",
            "URL": "https://aamplugin.com/pricing/plus-package"
        }
    },
    "Statement": [
        {
            "Effect": "deny",
            "Resource": [
                "BackendMenu:*",
                "Toolbar:*"
            ]
        },
        {
            "Effect": "deny",
            "Resource": "Widget:*",
            "Condition": {
                "Equals": {
                    "(*boolean)${CALLBACK.is_admin}": true
                }
            }
        },
        {
            "Effect": "allow",
            "Resource": [
                "BackendMenu:menu-wpseo_dashboard",
                "BackendMenu:wpseo_titles",
                "BackendMenu:wpseo_search_console",
                "BackendMenu:wpseo_social",
                "BackendMenu:wpseo_tools",
                "BackendMenu:wpseo_licenses",
                "Toolbar:wpseo-menu",
                "Widget:dashboard|wpseo-dashboard-overview",
                "Capability:read",
                "Capability:level_0",
                "Capability:wpseo_manage_options"
            ]
        }
    ]
}

Any time, single or double quotes are added to the teaser message, they get escaped with backslashes.

Any access options that are designed to protect authors content are not included in generated access policy. For example these options are not present in final JSON policy:

Because of the nature of Nginx redirect rules, the requested physical file is redirected as aam-media query param.

AAM expects the requested file in REQUEST_URI and does not know how to handle NGINX specific redirects. That is why any files that are protected with URI Access service can be read.

AAM fails to evaluate access policy that contains conditions referencing to ${USER.} and statements with Capability or Role resources.

Here is the example of a policy:

{
    "Version": "1.0.0",
    "Dependency": {
        "wordpress": ">=4.0.0",
        "advanced-access-manager": ">=6.0.0"
    },
    "Statement": [
        {
            "Effect": "allow",
            "Resource": [
                "Capability:read",
                "Capability:level_0",
                "Capability:level_1",
                "Capability:level_2",
                "Capability:level_3",
                "Capability:level_4",
                "Capability:level_5",
                "Capability:level_6",
                "Capability:level_7",
                "Capability:edit_posts",
                "Capability:delete_posts",
                "Capability:upload_files",
                "Capability:edit_published_posts",
                "Capability:publish_posts",
                "Capability:delete_published_posts",
                "Capability:moderate_comments",
                "Capability:manage_categories",
                "Capability:manage_links",
                "Capability:unfiltered_html",
                "Capability:edit_others_posts",
                "Capability:edit_pages",
                "Capability:edit_others_pages",
                "Capability:edit_published_pages",
                "Capability:publish_pages",
                "Capability:delete_pages",
                "Capability:delete_others_pages",
                "Capability:delete_published_pages",
                "Capability:delete_others_posts",
                "Capability:delete_private_posts",
                "Capability:edit_private_posts",
                "Capability:read_private_posts",
                "Capability:delete_private_pages",
                "Capability:edit_private_pages",
                "Capability:read_private_pages",
                "Capability:editor"
            ],
            "Condition": {
                "In": {
                    "${USER.user_email}": [
                        "[email protected]"
                    ]
                }
            }
        }
    ]
}

The AAM\AddOn\PlusPackage\Visibility\Initializer::initializeTermPostsVisibility does not prepare the array of properties correctly. There has to be clear separation of a post and term access settings with post_options and term_options indexes.

Currently, there is no way with UI to specified areas where taxonomy/term is visible or hidden. Something very similar to what post/post type offers would be lovely.

If one of the pages is hidden, the empty search result appears because Plus Package incorrectly prepares the MySQL query by adding (wp_posts.post_type = 'page' AND (wp_posts.ID NOT IN (14))).

There is no need to specify post type if any post has to be excluded.

SELECT 
	SQL_CALC_FOUND_ROWS wp_posts.ID 
FROM 
	wp_posts  
WHERE 
	((wp_posts.post_title LIKE '%article%') OR (wp_posts.post_excerpt LIKE '%article%') OR (wp_posts.post_content LIKE '%article%')) 
AND 
	(wp_posts.post_password = '') 
AND 
	wp_posts.post_type IN ('post', 'page', 'attachment') 
AND 
	(wp_posts.post_status = 'publish' OR wp_posts.post_status = 'acf-disabled') 
AND 
	(wp_posts.post_type = 'page' AND (wp_posts.ID NOT IN (14)))  
ORDER BY 
	wp_posts.post_title LIKE '%article%' DESC, wp_posts.post_date DESC LIMIT 0, 10

Hi Team ,
After some changes have been made to some roles and users, the toolbar will not be displayed at the site frontend
The settings are checked Show Toolbar when viewing site
The interesting thing is that this problem only exists on some of the users in which they are role, not all
i'm use jannah template
wordpress version is 5.3.2
aam plugin is latest version
sorry for week english
best regards

WordPress 5.3.2
Disabled all plugins except AAM.

To reproduce the issue.

1. Go to WP Admin Panel => AAM plugin page
2. Select "Manage Rules for Visitors"
3. Pick any REST API URL, e.g. /wp/v2/posts, and check the box "Deny" for it
4. Select "Manage Rules for Administrators", make sure that checkbox "Deny" is unchecked

Now

1. Open some page as unauthenticated user and try to get /wp/v2/posts
2. It shows access denied as expected for unauthenticated visitors

Then

1. Try to add JWT token created in admin panel to any valid place - query string, post body, authentication header, or authorization header and try to get /wp/v2/posts
2. Still "Access Denied" even though I tried to use JST token in various places

The issue #1 why I get "Access Denied" is because this method can identify user only in admin panel. When REST requests goes through it, the method below is called multiple times, and on the last call WP_User is always identified as "Unauthenticated Visitor".

/**
 * Change current user
 *
 * This method is triggered if some process updates current user
 *
 * @return AAM_Core_Subject
 *
 * @access public
 * @version 6.0.0
 */
public function initializeUser()
{
    global $current_user;

    // Important! Do not use WP core function to avoid loop
    $id = (is_a($current_user, 'WP_User') ? $current_user->ID : null);

// is_a() method works only in admin panel, but not in REST API
print '<pre>';
var_dump(is_a($current_user, 'WP_User'));
print_r($current_user);

   // Change current user
    if ($id) {
        $user = (new AAM_Core_Subject_User($id))->initialize();
    } else {
        $user = new AAM_Core_Subject_Visitor();
    }

    $this->setUser($user);

    return $user;
}

If a category is marked as HIDDEN, any access settings defined to posts that belong to it, are not taken into consideration. This is due to a few lines of code in WordPress core implementation:

How to reproduce:

1. Enable "Page Categories";
2. Create a sample category "Page Category A" and check HIDDEN for it:

3. Assing this category to any page and on the Posts & Terms, drill-down to find the "Page Category A". Define access settings by selecting RESTRICTED.

Confirm that page that supposedly should be restricted is still accessible.

Term_Query may use the slug property to query for terms. In this case, the query is prepared incorrectly and breaks the flow.

Do research on all possible combinations of properties that are used to construct WHERE clause with IN and NOT IN parts.

There is a bug when modifying the jwt expires.

To reproduce:

authentication.jwt.expires = 7200

Result:

"token_expires": "11/05/7200, 07:58 +0000",

Wordpress Version 5.2.4
AAM Version 5.11

Instead of adding 2 hours it became 11/05/7200

Currently, there is no way to define "Login Redirect" rules with Access Policy. That will be a great addition to the policies.

Latest AAM Plus Package add-on causes fatal error when Access Policy service is disabled:

[13-Jan-2020 08:53:14 UTC] PHP Fatal error: Uncaught Error: Call to a member function isAllowed() on null in /wp-content/plugins/aam-plus-package/application/Hooks/MetaboxHooks.php:73
Stack trace:
#0 /wp-includes/class-wp-hook.php(288): AAM\AddOn\PlusPackage\Hooks\MetaboxHooks->isHidden(false, 'dashboard', 'b2b_help_widget', Object(AAM_Core_Object_Metabox))
#1 /wp-includes/plugin.php(206): WP_Hook->apply_filters(false, Array)
#2 /wp-content/plugins/advanced-access-manager/application/Core/Object/Metabox.php(70): apply_filters('aam_metabox_is_...', false, 'dashboard', 'b2b_help_widget', Object(AAM_Core_Object_Metabox))
#3 /wp-content/plugins/advanced-access-manager/application/Service/Metabox.php(254): AAM_Core_Object_Metabox->isHidden('dashboard', 'b2b_help_widget')
#4 /wp-content/plugins/advanced-access-manager/application/Service/Metabox.php(232): AAM_Service_Metabox->removeMetaboxes('normal', Array, 'dashboard')
#5 /wp-conten in /home/newsroom/web/wp-content/plugins/query-monitor/collectors/php_errors.php on line 82

For multisite network, for convenience, would be nice to add the ability to jump to AAM page from the top admin toolbar.

To mitigate any unexpected issues between PHP 5 & 7, it is recommended to avoid using list function https://www.php.net/manual/en/function.list.php

Warning! In PHP 5, list() assigns the values starting with the right-most parameter. In PHP 7, list() starts with the left-most parameter.

If you are using plain variables, you don't have to worry about this. But if you are using arrays with indices you usually expect the order of the indices in the array the same you wrote in the list() from left to right, which is not the case in PHP 5, as it's assigned in the reverse order.

Generally speaking, it is advisable to avoid relying on a specific order of operation, as this may change again in the future.

In theory, only published access policies should be applied. However, if you create an access policy, attach it to any role or user and save it as a draft. It is going to be applied.

Currently, when you generate a new access policy, it downloads a JSON file that we have to copy and paste into a new policy record on the backend site.

It would be nice to have the ability to choose between "Download as File" & "Create a New Policy" when selecting the "Policy Generation" button.

AAM:6.3.3
Wordpress: 5.3.2

Selecting an existing page for redirection is problematic in a few ways. I am using polylang and I have two languages in my site (Greek and English). I want to create a redirection rule for a page in both languages so naturally I should apply this rule for both versions (GR and EN) of the page.

However when I select the existing page choice for redirection, it shows only the pages in one language (GR or EN) for both versions. So I can choose a Greek page (or English, it's a random happenstance) for a redirection for both versions of a page when naturally I would need to select a Greek page when redirecting from a Greek page and an English page when redirecting from a English page. Or at least, return all the pages and let me select the one I want.

But this isn't the case. So what I do is set the redirection for one language via the existing page choice and the other by giving the full url of the destination.

It appears that "JWT Token" service is incompatible with the Jetpack plugin that relies on the rest_authentication_errors to return true. AAM overrides it with false value to halt the nonce check during the RESTful API call for authentication.

This implementation has to be rewritten to be compatible with other plugins and for more information refer to https://wordpress.org/support/topic/jetpack-and-rest-api/

This is a trade-off that IP Check has to make. If user, first time, comes from some referred host, this information is stored in cookie as JWT claim. However, when user navigates to a different page, he/she gets "Access Denied". It is because of the HTTP_REFERER option changes to point to previously viewed page and this overrides the value stored in claims.

prepareUserIdentity has to be modified to honor information that is already stored in the JWT token.

If the URI access service is used to protect the homepage, it does not work. To reproduce the issue:

• Switch to manage visitors and go to URI Access tab;
• Create a new rule and add / with Redirect To Login Page;
• Go to the homepage as visitor and nothing happens;

Currently, there are no ways to restrict access to all API Routes and exclude only few. Would be lovely to have the ability to do something like this:

{
    "Effect": "deny",
    "Resource": "Route:*"
}

or even more granular access controls. For example, restrict the ability to invoke any RESTful API endpoint with GET verb:

{
    "Effect": "deny",
    "Resource": "Route:RESTful:*:GET"
}

WordPress core is very limited when it comes to managing access to a term creation process. There are multiple programmatic paths defined for this simple functionality and neither gives full control over it.

Additional research has to be conducted to determine the best possible way to prevent users from creating term of any given taxonomy.

It appears that the following access options are not working as expected: RESTRICTED TO OTHERS, DELETE BY OTHERS, EDIT BY OTHERS, PUBLISH BY OTHERS.

The root cause is in the incorrect order the Plus Package hooks into the aam_post_object_option_filter filter.

Hello,

First of all a big thanks for providing best plugin for the wp security and access management.

I just updated to the new version and noticed that individual check boxes don't have any effect.

If you take a look at the ajax request, the "Status" parameter always says: 0

As far as I could understand it needs to be: 1 to disable it and needs to be 0 to enable it.

I did a clean install on my local system and I don't see this issue on new install.

However the issue is still present in the Multisite installation.

Now I can conclude two problems from here.

2) Or we need a complete new database

Now I am going to convert the working wordpress into multisite and will see if issue is still there or not.

Just converted the working site into multisite and it's working fine.

Now it must be a database issue.

When there are few categories that are explicitly allowed, those become as preselected categories when a post is saved. So the side effect is that multiple categories get preselected.

This is due to the fact that term query is not constructed properly.

The error emits when you click on the PASSWORD PROTECTED option and before the modal window pops up.

It appears that AAM reloads the Post Access Form, however, still does not have the password stored in database:

Array
(
    [visitor] => Array
        (
            [term] => Array
                (
                    [77|category|post] => Array
                        (
                            [post/protected] => Array
                                (
                                    [enabled] => 1
                                )
                        )
                )
        )
)

It would be nice to integrate with geo services like ipstack.com to be able to define restrictions and access policies based on the geographical location.

Conflict After Update to Version 6.0.1
Seems like there is a conflict with the ACF Plugin Pro (5.8.7). When AAM is updated to Version 6.0.1 and activated with Wordpress (5.3) it is not possible to edit consisting ACF Field Groups.
Before updating the plugin this was possible with AAM 5.9.x

The backend only loads WP sidebar and top menu bar. Console throws no errors tough.

We've acknowledged that more organized and structured teams using CI/CD pipelines and the ability to pull and deploy premium AAM add-ons with PHP Composer and/or WP-CLI are very critical.

When manually triggered check for updates, the PHP warning occurs.

The "ADD NEW" access option was added with Plus Package 5.3.0, however, there is no support for this option in the access policy.

We need to implement support for the following statement:

{
    "Effect": "deny",
    "Resource": "Taxonomy:category:terms",
    "Action": "Create"
}

The ASSIGN option for any given category can be bypassed with a classical WordPress editor. Post actually gets created and is assigned to protected category.

To reproduce the issue, create a new post, enter a title and select category that is restricted to be ASSIGNED to. Then select "Publish". The error message will indicate that "You are not allowed to edit this post", which is already wrong behavior. Going back to the list of posts reveals a newly created post in the protected category.

Each time I click on the lock user icon, the spins icon never stops.

When you create a URI Access rule and then change it's URI, a new rule is created instead of updating the one that was edited.

In the example below, I've created the first rule to restrict access to the homepage / and then selected to edit it and changed the URI to /latest-posts/. Instead of updating the first rule, it created a new one.

In AAM 6, options that are deleted from the database are removed explicitly. That keeps all legacy options still in the database.

When WP core function wp_parse_url parses a requested URI, the path option may be missing in the returned array. This triggers PHP notice.

More details mentioned in this forum thread .

Currently, AAM basic version restricts to attach access policies to everybody (Default Access Settings) and requires at least Plus Package add-on.

We should move this ability to the basic version as access policies are getting more attention and the ability to attach them to all users at once becomes critical.