CALLBACK

# Syntax

${CALLBACK.<callable>}
${CALLBACK.<callable(...args)>}

# Definition

Trigger any valid callback function or static method that returns some values. This is quite a powerful way to enhance your policies with some dynamic calculations. Each CALLBACK marker has to have a well-defined PHP callbackopen in new window as a string. This means that it has to be either a function name or a static method of a class.

In the example below, we’ll define a policy that restricts a user to access the backend area if the user is not registered with some third-party authentication system (e.g. Active Directory).

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Capability:access_dashboard",
        "Condition": {
          "Equals": {
            "${CALLBACK.\\MyApp\\Auth::isRegistered}": false
          }
        }
    }
}

The code below is just a boilerplate for the actual integration with the third-party authentication server. The ThirdParty\Connector is assumed to be the bridge between the WordPress core and a third party.

<?php
declare(strict_types=1);

namespace MyApp;

use ThirdParty\Connector;

/**
 * Adapter for some third-party authentication server
 */
class Auth {

    /**
     * Check if the current user is registered with the third-party
     *
     * @return bool
     */
    public static isRegistered() : bool {
        $registered = false;
        $user       = wp_get_current_user();

        if (is_a($user, 'WP_User')) {
            // Let's assume that the findUserByEmail method returns an object that contains
            // details about the user and `exists` property is either true or false
            $registered = Connector::findUserByEmail($user->user_email)->exists;
        }

        return $registered;
    }

}

Similarly, the CALLBACK can be any WordPress core function which significantly enhance access policy capabilities. In the following example we deny access to everything if user is in the admin area (/wp-admin/).

{
    "Statement": {
        "Effect": "deny",
        "Resource": "URI:*",
        "Condition": {
            "Equals": {
                "(*bool)${CALLBACK.is_admin}": true
            }
        }
    }
}

# Inline arguments

The CALLBACK marker serves to transmit specific static or dynamic values to the callback function. An illustration of its usage is provided below:

{
    "Statement": {
        "Effect": "deny",
        "Resource": "Post:page:hello-world",
        "Action": "Edit",
        "Condition": {
            "NotEquals": {
                "(*bool)${CALLBACK.current_user_can('edit_post', 10)}": true
            }
        }
    }
}

This configuration rejects editing access to the "Hello World" page if the current user lacks authorization to edit another post with the ID of 10.

You can inline arguments for the callback function in three distinct manners:

• As a literal string, enclosed within single quotes (e.g., 'argument', 'hello world')
• As a literal numeric value (e.g., 10, 2.4, 105)
• As another marker (e.g., CONST.WP_DEBUG). Note there is no need to wrap inline markers in ${} curly brackets

Here is another example of a policy with a marker as inline argument:

{
    "Param": {
        "Key": "sanitizedUserName",
        "Value": "${CALLBACK.sanitize_title(USER.display_name)}"
    }
}