Permission callbacks in Wordpress - Step-by-Step Execution

Concept Flow - Permission callbacks

Request to access resource

↓

Call permission callback function

↓

Check user capabilities or conditions

↓

Allow access

↓

Return result to caller

When WordPress needs to check if a user can do something, it calls a permission callback. The callback checks conditions and returns true or false.

Execution Sample

Wordpress

function check_permission() {
  return current_user_can('edit_posts');
}

register_rest_route('myplugin/v1', '/data', [
  'methods' => 'GET',
  'permission_callback' => 'check_permission',
  'callback' => 'get_data'
]);

This code registers a REST API route with a permission callback that allows access only if the user can edit posts.

Execution Table

Step	Action	Permission Callback Called?	Callback Result	Access Outcome
1	Request to /myplugin/v1/data	Yes	true (user can edit posts)	Access allowed, main callback runs
2	Request to /myplugin/v1/data	Yes	false (user cannot edit posts)	Access denied, main callback blocked
3	Request to /myplugin/v1/data	Yes	true (user can edit posts)	Access allowed, main callback runs

💡 Access is allowed only when permission callback returns true; otherwise, access is denied.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3
permission_callback_result	undefined	true	false	true
access_granted	undefined	true	false	true

Key Moments - 3 Insights

Why does the permission callback run before the main callback?

The permission callback runs first to check if the user has rights. If it returns false, the main callback never runs. See execution_table step 2 where access is denied.

What happens if the permission callback returns false?

Access is denied immediately and the main callback is not executed. This is shown in execution_table step 2 where callback result is false and access is denied.

Can the permission callback check anything about the user?

Yes, it can check user roles, capabilities, or any condition. In the example, it checks if the user can 'edit_posts' as shown in the code and execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the access outcome when the permission callback returns false?

A Access allowed, but main callback blocked

B Access allowed, main callback runs

C Access denied, main callback blocked

D No effect, permission callback ignored

💡 Hint

Check execution_table row 2 where callback result is false and access is denied

At which step in the execution_table does the permission callback return true and allow access?

A Step 2

B Both Step 1 and Step 3

C Step 3

D Step 1

💡 Hint

Look at execution_table rows 1 and 3 where callback result is true and access is allowed

If the permission callback always returns true, how would the access_granted variable change in variable_tracker?

A It would be true for all steps

B It would alternate true and false

C It would be false for all steps

D It would be undefined

💡 Hint

See variable_tracker where access_granted matches permission_callback_result; if callback always true, access_granted always true

Concept Snapshot

Permission callbacks in WordPress REST API check if a user can access a route.
They run before the main callback.
Return true to allow access, false to deny.
Use user capabilities or custom logic.
If false, main callback never runs.
Always secure routes with permission callbacks.

Full Transcript

In WordPress, permission callbacks are functions that check if a user has the right to access a REST API route. When a request comes in, WordPress calls the permission callback first. This callback checks user capabilities or other conditions and returns true or false. If it returns true, WordPress runs the main callback to provide data or perform actions. If it returns false, WordPress denies access and does not run the main callback. This ensures security by preventing unauthorized users from accessing sensitive routes. The example code shows a permission callback checking if the user can edit posts. The execution table traces requests where the callback returns true or false and shows the resulting access. The variable tracker shows how the permission callback result affects access granted. Key moments clarify why the permission callback runs first and what happens when it returns false. The quiz tests understanding of these steps. Remember, always use permission callbacks to protect your REST API routes in WordPress.

Practice

1. What is the main purpose of a permission callback in WordPress REST API routes?

easy

A. To define the URL of the REST API route

B. To check if the current user has permission to access the route

C. To format the response data before sending

D. To register the REST API route with WordPress

Solution

1. Step 1: Understand permission callback role

   A permission callback is a function that decides if a user can access a REST API route.

2. Step 2: Identify what permission callback checks

   It returns true if the user has the right capability, false otherwise.

3. Final Answer:

   To check if the current user has permission to access the route -> Option B

4. Quick Check:

   Permission callback = access control [OK]

Hint: Permission callbacks control access rights [OK]

Common Mistakes:

• Confusing permission callback with route registration
• Thinking it formats data instead of checking access
• Assuming it sets the route URL

2. Which of the following is the correct way to define a permission callback in register_rest_route?

easy

A. "permission_callback" => array(check_user_permission)

B. "permission_callback" => check_user_permission()

C. "permission_callback" => "check_user_permission()"

D. "permission_callback" => check_user_permission

Solution

1. Step 1: Understand callback syntax in PHP arrays

   Callbacks are passed as callable references without parentheses.

2. Step 2: Identify correct syntax for permission_callback

   It should be a string or callable without calling it immediately, so no parentheses.

3. Final Answer:

   "permission_callback" => check_user_permission -> Option D

4. Quick Check:

   Callback = function name without () [OK]

Hint: Use function name without parentheses for callbacks [OK]

Common Mistakes:

• Adding parentheses calls the function immediately
• Using array() incorrectly for single function
• Passing callback as a string with quotes and parentheses

3. Given this permission callback function, what will register_rest_route allow?

function my_permission_check() {
  return current_user_can('edit_posts');
}

register_rest_route('myplugin/v1', '/data', [
  'methods' => 'GET',
  'callback' => 'my_data_callback',
  'permission_callback' => 'my_permission_check'
]);

medium

A. Only users who can edit posts can access the route

B. All users can access the route

C. No users can access the route

D. Only administrators can access the route

Solution

1. Step 1: Analyze the permission callback function

   The function returns true if the current user has the 'edit_posts' capability.

2. Step 2: Understand effect on route access

   Only users with 'edit_posts' capability can access the route; others get denied.

3. Final Answer:

   Only users who can edit posts can access the route -> Option A

4. Quick Check:

   Capability check controls access [OK]

Hint: Permission callback returns true only for allowed users [OK]

Common Mistakes:

• Assuming all users can access without checking capability
• Confusing 'edit_posts' with administrator only
• Ignoring the return value of permission callback

4. Identify the error in this permission callback code:

function check_permission() {
  if (current_user_can('edit_posts')) {
    return true;
  }
}

medium

A. Function should not return boolean

B. Incorrect capability name used

C. Missing return false when user lacks permission

D. Permission callback must be anonymous function

Solution

1. Step 1: Review function return paths

   The function returns true if user can edit posts, but returns nothing otherwise.

2. Step 2: Understand permission callback requirements

   Permission callbacks must return true or false explicitly to avoid unexpected behavior.

3. Final Answer:

   Missing return false when user lacks permission -> Option C

4. Quick Check:

   Always return true or false in permission callbacks [OK]

Hint: Always return false if permission denied [OK]

Common Mistakes:

• Omitting return false causes implicit null return
• Assuming no return means false automatically
• Using wrong capability names

5. You want to create a REST API route that only allows users who can either edit_posts or publish_posts. Which permission callback function correctly implements this?

hard

A. function permission_check() {
return current_user_can('edit_posts') || current_user_can('publish_posts');
}

B. function permission_check() {
return current_user_can('publish_posts');
}

C. function permission_check() {
if (current_user_can('edit_posts')) {
return true;
}
return false;
}

D. function permission_check() {
return current_user_can('edit_posts') && current_user_can('publish_posts');
}

Solution

1. Step 1: Understand the requirement

   Access should be granted if user can edit posts OR publish posts.

2. Step 2: Analyze each function logic

   function permission_check() { return current_user_can('edit_posts') && current_user_can('publish_posts'); } requires both capabilities (AND), which is too strict. function permission_check() { return current_user_can('edit_posts') || current_user_can('publish_posts'); } uses OR, which matches requirement. function permission_check() { if (current_user_can('edit_posts')) { return true; } return false; } only checks edit_posts. function permission_check() { return current_user_can('publish_posts'); } only checks publish_posts.

3. Final Answer:

   function permission_check() { return current_user_can('edit_posts') || current_user_can('publish_posts'); } -> Option A

4. Quick Check:

   Use OR for either capability allowed [OK]

Hint: Use || to allow either capability [OK]

Common Mistakes:

• Using && instead of || for either/or logic
• Checking only one capability when two are needed
• Not returning false explicitly when needed