Daniel Iser

@vray-admin – Technically speaking yes, there are underlying functions you can call passing in the check details, with or without using out global restrictions or blocks.

You can use helper functions to check if a given post is visible to the current user based on global restrictions in the settings page, or use other helper functions to check manually user permissions such as \ContentControl\user_is_excluded() or \ContentControl\user_meets_requirements( $user_status, $user_roles = [], $role_match = 'match' )
https://github.com/code-atlantic/content-control/blob/master/inc/functions/restrictions.php#L45-L126

That said, given your simple example, you could bypass our plugin entirely:

$user = wp_get_current_user();
$allowed_roles = array( 'editor', 'administrator', 'author' );
if ( array_intersect( $allowed_roles, $user->roles ) ) {
   // Stuff here for allowed roles
}

@simbian For the record I run Query Monitor while developing, and have not once seen these or they would have been cleaned up. I run full WP_DEBUG, SCRIPT_DEBUG enabled. I was only able to replicate this on the WP 6.8-beta.

Not seeing any more after this one was fixed.

• This reply was modified 1 year, 2 months ago by Daniel Iser.

@billakosgr – Quick follow up, we don’t actually “have every rule” in the sense that we made them all on purpose. We simply built logic that auto generates rules for any registered & public post type or taxonomy.

So either their docs are not using the built in custom post type systems, or they have them marked as private. Otherwise they would already just appear like your other content types do.

Some plugins do have content outside the normal content stuff, but we tend to put those rules into our pro offering as they require us to manually maintain them.

You can try forcing then enabled.

add_filter('content_control/get_options', function ( $options ) {
    $options['includePrivatePostTypes'] = true;

    return $options;
} );

Just changed it to

		$is_public = isset( $args['public'] ) && $args['public'];

		// Check if this is a private taxonomy.
		if ( ! $is_public ) {
			if ( $include_private ) {
				$args['show_in_rest'] = true; // Enable REST API.
			}
		} else {
			$args['show_in_rest'] = true; // Enable REST API.
		}

@bighrts – Can you clarify & provide some context? Are you saying our CSS isn’t loading, or your themes CSS isn’t loading. Everywhere or only on restricted pages etc?

Are there any errors in your logs?

In any case, only a change in PHP could realistically make enqueued CSS not load, either by dequeueing it somehow or throwing fatal errors before they can be rendered.

If the page html is loading, but not the CSS, its unlikely a fatal error given CSS is rendered typically in the head, before page html.

As for PHP changes we made, there is a grand total of 2, neither possibly could cause this unless your CSS loads via the REST API Search endpoint where that code runs.

The only other potential vector would be that we updated the version of Trusted Login embedded package, but I just reviewed those changes as well and it appears all to be Coding Standards updates. IE comments, formatting related.

Your free to check the changes in our code here: https://github.com/code-atlantic/content-control/compare/v2.5.0…v2.6.0

And the changes including Trusted Login here: https://plugins.trac.ww.wp.xz.cn/changeset/3253935/content-control/trunk

We also haven’t seen any other reports of such an issue thus far, as it sounds like it would be a pretty noticeable thing I would expect more reports.

I’m inclined to lean towards caching issues or such, but I’d like more context so we can make proper assessments or try to duplicate the issue.

Can you replicate it on our demo site?

@peter8nss – Replicated but not 100% sure why yet. Appears it only affects the rest search results, and it seems the content is not marked restricted.

This leads me to believe that we are detecting an incorrect REST context which will take some testing to work out exactly.

For reference, the WP REST API does not play nice with WP conditionals, like is_post or even has_tag etc, there is no global context set in WP REST requests effectively so none of the traditional stuff just works.

Because we were forced to add REST support last year, we effectively had to invent a system of detecting & utilizing intent of any REST request, along with building an entire wrapper to determine under exactly what context any given rule was being checked.

For example some rules process differently under a main query vs a side query vs rest api etc.

https://github.com/code-atlantic/content-control/blob/master/inc/functions/query.php#L505

So we end up with a much more complicated setup than just some conditional like v1, but as we fully refine the kinks out we can get more and more granular with how rules are checked.

My gut says the context is getting confused for that one rule somehow, but I will likely require testing all rules to validate them again for specifically search context.

@peter8nss Will try to replicate today, if so will get a patch out later tonight.

That said by default now it should be filtering any result from search without that setting be explicitly set so I’m not quite sure how it could be bypassed.

@officezen – Try v2.6.0.

To be clear it is both true, but also a false positive in how it is represented based on generic categorization.

It did not allow any hacking of your site for example, but if you had set up specific features so that your content showed “Restricted Content” notices but still appeared in archives or search results, then someone could effectively guess your content & expose it with repeated searches. Ultimately WP core’s search showing results (which is what was set up by the admin), actually confirms the searched content exists in the restricted item.

You can read about this specific issue here: https://contentcontrolplugin.com/docs/security/preventing-bots-from-discovering-restricted-content/#how-content-can-be-exposed

Now its removed from search by default, and if you turn it on you basically have to acknowledge you know what your doing.