Permission callbacks in Wordpress - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a permission callback returns false?

In WordPress REST API, if a permission callback returns false, what is the expected behavior when a client tries to access that endpoint?

Wordpress

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

function myplugin_check_permission() {
  return false;
}

A The API returns the data but logs a warning in the server.

B The API returns a 403 Forbidden error to the client.

C The API returns a 404 Not Found error to the client.

D The API ignores the permission callback and returns the data.

💡 Hint

Think about what permission denied means in web APIs.

When a permission callback returns false, WordPress REST API responds with a 403 Forbidden status. This means the client is not allowed to access the endpoint.

📝 Syntax

intermediate

Identify the correct permission callback syntax

Which of the following is the correct way to define a permission callback for a REST API route in WordPress?

Wordpress

register_rest_route('myplugin/v1', '/item', [
  'methods' => 'POST',
  'callback' => 'myplugin_create_item',
  'permission_callback' => ???
]);

A current_user_can('edit_posts')

B myplugin_check_permission()

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

D 'myplugin_check_permission'

💡 Hint

Remember, permission_callback expects a callable, not the result of a function call.

The permission_callback must be a callable function name or closure. Passing the function name as a string is correct. Calling the function immediately (with parentheses) is wrong.

🔧 Debug

advanced

Why does this permission callback cause a fatal error?

Consider this permission callback function:

function myplugin_permission() {
  return current_user_can('edit_posts') ? true : false;
  echo 'Check permission';
}

Why does this cause a fatal error?

Wordpress

register_rest_route('myplugin/v1', '/check', [
  'methods' => 'GET',
  'callback' => 'myplugin_callback',
  'permission_callback' => 'myplugin_permission'
]);

A The function lacks a required parameter for permission callbacks.

B The echo statement after return causes unreachable code error.

C The function returns a boolean but should return a WP_Error object.

D The function name is not a valid callable.

💡 Hint

Check the function signature against how WordPress calls permission callbacks (with $request).

WordPress REST API calls permission callbacks with a WP_REST_Request argument. Defining the function without a parameter causes a PHP ArgumentCountError (fatal error) when called.

❓ state_output

advanced

What is the output when permission callback returns WP_Error?

If a permission callback returns a WP_Error object instead of true or false, what will the REST API response be?

Wordpress

function myplugin_permission() {
  return new WP_Error('rest_forbidden', 'You do not have permission', ['status' => 403]);
}

register_rest_route('myplugin/v1', '/error', [
  'methods' => 'GET',
  'callback' => 'myplugin_callback',
  'permission_callback' => 'myplugin_permission'
]);

A The API returns a 403 error with the message 'You do not have permission'.

B The API ignores the WP_Error and returns the callback data.

C The API returns a 500 Internal Server Error.

D The API returns a 200 OK with empty data.

💡 Hint

WP_Error objects are used to send error responses in WordPress REST API.

Returning a WP_Error from permission_callback causes the REST API to send the error status and message to the client.

🧠 Conceptual

expert

Why use permission callbacks instead of checking permissions inside the main callback?

Why is it better to use a permission_callback in WordPress REST API routes rather than checking permissions inside the main callback function?

A Permission callbacks automatically log user activity, main callbacks do not.

B Permission callbacks are required by WordPress and main callbacks cannot check permissions.

C Permission callbacks prevent unauthorized users from triggering expensive operations in the main callback.

D Permission callbacks run after the main callback to verify results.

💡 Hint

Think about performance and security when handling API requests.

Using permission callbacks stops unauthorized requests early, avoiding running costly code in the main callback. This improves security and efficiency.

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