Authentication for API in Wordpress - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of using OAuth2 in WordPress REST API authentication?

OAuth2 is a common method for API authentication. What does it mainly help with in WordPress REST API?

A It allows users to authenticate without sharing their passwords directly with the client app.

B It automatically encrypts all API data sent between client and server.

C It disables all other authentication methods to improve security.

D It stores user passwords in a special encrypted database.

💡 Hint

Think about how OAuth2 helps users keep their passwords safe when using third-party apps.

OAuth2 lets users authorize apps to access their data without giving out their password, improving security and user control.

❓ component_behavior

intermediate

What happens when you send a REST API request to WordPress without authentication for a protected route?

Consider a WordPress REST API route that requires authentication. What will the server respond if you call it without any authentication?

A The server crashes and stops responding.

B The server returns the requested data without any restrictions.

C The server returns a 401 Unauthorized error response.

D The server returns a 404 Not Found error response.

💡 Hint

Think about what HTTP status code means 'you need to log in first'.

Protected routes require authentication. Without it, WordPress returns a 401 Unauthorized error to indicate access is denied.

📝 Syntax

advanced

Which code snippet correctly adds Basic Authentication support to WordPress REST API?

Choose the code snippet that properly enables Basic Authentication for WordPress REST API requests.

A add_filter('rest_authentication_errors', function($result) { if (empty($_SERVER['PHP_AUTH_USER'])) { return new WP_Error('rest_not_logged_in', 'You are not logged in.', array('status' => 401)); } return $result; });

B add_action('rest_authentication_errors', function($result) { if (!empty($_SERVER['PHP_AUTH_USER'])) { return true; } return $result; });

C add_filter('rest_authentication_errors', function($result) { if (!empty($_SERVER['PHP_AUTH_USER'])) { return true; } return $result; });

D add_filter('rest_authentication_errors', function() { return true; });

💡 Hint

Look for the filter hook that checks if the PHP_AUTH_USER is empty and returns an error if so.

The 'rest_authentication_errors' filter lets you check authentication. Returning a WP_Error with status 401 denies access properly.

❓ state_output

advanced

What is the output of this WordPress REST API authentication check code?

Given the following code snippet inside a REST API callback, what will be the output if the user is not logged in?

Wordpress

<?php
function my_api_callback() {
  if (!is_user_logged_in()) {
    return new WP_Error('rest_forbidden', 'You must be logged in.', array('status' => 403));
  }
  return array('message' => 'Welcome!');
}
?>

A PHP Fatal error: Call to undefined function is_user_logged_in()

B {"message":"Welcome!"}

C null

D {"code":"rest_forbidden","message":"You must be logged in.","data":{"status":403}}

💡 Hint

Think about what happens when the user is not logged in and the function returns a WP_Error.

The function returns a WP_Error with status 403, which the REST API converts to a JSON error response with code and message.

🔧 Debug

expert

Why does this WordPress REST API authentication code always allow access even without credentials?

Examine the code below. It is intended to restrict access to authenticated users only. Why does it fail to do so?

add_filter('rest_authentication_errors', function($result) {
  if (!empty($_SERVER['PHP_AUTH_USER'])) {
    return true;
  }
  return $result;
});

A The filter should return false to block unauthenticated users, not true.

B Returning true from 'rest_authentication_errors' means no error, so unauthenticated users are allowed access.

C Returning true from 'rest_authentication_errors' means authentication passed, so unauthenticated users are blocked correctly.

D The code is missing a check for $_SERVER['PHP_AUTH_PW'], so it always fails.

💡 Hint

Check what returning true or an error from this filter means for access control.

In 'rest_authentication_errors', returning true means no error occurred, so access is granted. To block access, you must return a WP_Error instead.

Practice

1. What is the main purpose of permission_callback in WordPress REST API authentication?

easy

A. To format the API response data

B. To define the URL of the API endpoint

C. To register a new API route

D. To check if the user has permission to access the API endpoint

Solution

1. Step 1: Understand the role of permission_callback

   This callback function is used to verify if the current user has the right permissions to access a specific API route.

2. Step 2: Differentiate from other API registration parts

   Other parts like route URL and response formatting are handled separately; permission_callback specifically controls access.

3. Final Answer:

   To check if the user has permission to access the API endpoint -> Option D

4. Quick Check:

   permission_callback controls access permission [OK]

Hint: Remember permission_callback controls access rights [OK]

Common Mistakes:

• Confusing permission_callback with route registration
• Thinking permission_callback formats data
• Assuming permission_callback sets URL

2. Which of the following is the correct way to register a REST API route with authentication in WordPress?

easy

A. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission_callback' => '__return_true'))

B. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data'))

C. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'auth_callback' => '__return_true'))

D. register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission' => '__return_true'))

Solution

1. Step 1: Identify the correct parameter for authentication

   The correct parameter to control access is permission_callback, which should be set to a callable that returns true or false.

2. Step 2: Check the syntax of the registration function

   register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission_callback' => '__return_true')) correctly includes permission_callback with a valid callable __return_true allowing access.

3. Final Answer:

   register_rest_route('myplugin/v1', '/data', array('methods' => 'GET', 'callback' => 'get_data', 'permission_callback' => '__return_true')) -> Option A

4. Quick Check:

   Use permission_callback for authentication [OK]

Hint: Use permission_callback, not auth_callback or permission [OK]

Common Mistakes:

• Using 'auth_callback' instead of 'permission_callback'
• Omitting permission_callback entirely
• Using 'permission' instead of 'permission_callback'

3. Given this code snippet, what will be the output when an unauthenticated user tries to access the API?

register_rest_route('myplugin/v1', '/secret', array(
  'methods' => 'GET',
  'callback' => 'get_secret_data',
  'permission_callback' => function() {
    return current_user_can('read');
  }
));

function get_secret_data() {
  return 'Secret Info';
}

medium

A. Returns a 401 Unauthorized error

B. Returns a 404 Not Found error

C. Returns an empty string

D. Returns 'Secret Info' to everyone

Solution

1. Step 1: Understand the permission_callback logic

   The callback checks if the user has the 'read' capability. Unauthenticated users do not have this capability, so it returns false.

2. Step 2: Know WordPress REST API behavior on permission failure

   If permission_callback returns false, the API returns a 401 Unauthorized error to block access.

3. Final Answer:

   Returns a 401 Unauthorized error -> Option A

4. Quick Check:

   Permission denied returns 401 error [OK]

Hint: Permission callback false means 401 error [OK]

Common Mistakes:

• Assuming data is returned without permission
• Confusing 401 Unauthorized with 404 Not Found
• Thinking empty string is returned on failure

4. Identify the error in this WordPress REST API route registration code:

register_rest_route('myplugin/v1', '/info', array(
  'methods' => 'GET',
  'callback' => 'get_info',
  'permission_callback' => 'current_user_can('read')'
));

function get_info() {
  return 'Info';
}

medium

A. The callback function 'get_info' is missing parameters

B. The 'methods' value should be an array, not a string

C. The 'permission_callback' should be a callable, not a function call string

D. The route namespace 'myplugin/v1' is invalid

Solution

1. Step 1: Check the type of permission_callback

   permission_callback must be a callable function, not the result of a function call. Here, 'current_user_can('read')' is a string calling the function immediately, which is incorrect.

2. Step 2: Correct usage of permission_callback

   It should be a callable like a function name or anonymous function that returns a boolean when called by the API.

3. Final Answer:

   The 'permission_callback' should be a callable, not a function call string -> Option C

4. Quick Check:

   permission_callback must be callable, not called [OK]

Hint: permission_callback needs a callable, not a called function [OK]

Common Mistakes:

• Passing function call result instead of callable
• Using string with quotes incorrectly
• Confusing methods string vs array

5. You want to create a WordPress REST API endpoint that only logged-in users with the 'edit_posts' capability can access. Which of these permission_callback implementations correctly enforces this?

hard

A. permission_callback => function() { return is_user_logged_in(); }

B. permission_callback => function() { return is_user_logged_in() && current_user_can('edit_posts'); }

C. permission_callback => function() { return current_user_can('read'); }

D. permission_callback => function() { return true; }

Solution

1. Step 1: Understand the requirement

   The endpoint must allow only logged-in users who have the 'edit_posts' capability.

2. Step 2: Analyze each permission_callback

   permission_callback => function() { return is_user_logged_in() && current_user_can('edit_posts'); } checks both if the user is logged in and if they have the capability, fulfilling the requirement exactly.

3. Step 3: Why other options fail

   A only checks login without the 'edit_posts' capability. B checks current_user_can('read') which many users have but not 'edit_posts'. D allows everyone.

4. Final Answer:

   permission_callback => function() { return is_user_logged_in() && current_user_can('edit_posts'); } -> Option B

5. Quick Check:

   Check login and capability together [OK]

Hint: Check both login and capability for secure access [OK]

Common Mistakes:

• Using wrong capability like 'read' instead of 'edit_posts'
• Checking only login without capability
• Allowing all users by returning true