Policies & Authorization

Every REST route group is guarded by a policy — a class in app/Http/Policies/ that decides whether the current user may run the request. A group attaches its policy with ->withPolicy('PolicyName').

How a policy works

Policies extend BasePolicy and implement verifyRequest() (and optionally per-method verifiers). Returning false short-circuits the request with an error response before the controller runs.

namespace WPSocialReviews\App\Http\Policies;

use WPSocialReviews\Framework\Http\Request\Request;

class CustomSourcesPolicy extends BasePolicy
{
    public function verifyRequest(Request $request)
    {
        return $this->currentUserCan('wpsn_full_access');
    }
}

currentUserCan() checks a WP Social Ninja capability. The admin capability used for most checks is filterable:

apply_filters('wpsr_admin_permission', 'manage_options');

Core policy classes

Policy	Guards
AdminPolicy	Admin-only groups (e.g. onboarding)
PlatformPolicy	platforms/*
ReviewPolicy	reviews
TestimonialPolicy	testimonials
CategoryManagementPolicy 4.4.0	Category rename & delete under both prefixes
DashboardNoticesPolicy 4.4.0	platforms/dashboard-notices
SettingsPolicy	settings, and Pro's pro/*
WidgetsPolicy	chat-widgets
ShoppablePolicy	shoppable
NotificationsPolicy	notifications
PagesPolicy	pages
TemplatePolicy	templates
ReviewFormPolicy	Pro pro/review-forms
CustomSourcesPolicy	Pro pro/custom-sources
ReviewsPlatformsSettingsPolicy	Pro pro/settings
BasePolicy	Base class for all of the above

Pro reuses core policies

Pro does not ship its own Policies/ directory. Its pro/* route groups reference the policy classes that live in the core plugin (SettingsPolicy, ReviewFormPolicy, CustomSourcesPolicy, ReviewsPlatformsSettingsPolicy). This is one reason Pro requires a compatible core version — see Core ↔ Pro Coupling.

Policies that widen or narrow a group 4.4.0

A policy normally guards a whole prefix. Two routes break that pattern, and both are worth knowing about before you assume a prefix implies a capability.

CategoryManagementPolicy — demands both capabilities

Review categories are one shared vocabulary across reviews and testimonials, and deleting one detaches it from rows on both screens. Renaming and deleting therefore reach past a single capability's rows, so the policy requires both rather than either:

public function verifyRequest(Request $request)
{
    return $this->currentUserCan('wpsn_manage_reviews')
        && $this->currentUserCan('wpsn_manage_testimonials');
}

The routes are mounted under /reviews/categories/{id} and /testimonials/categories/{id}, but the prefix is cosmetic — it exists so each screen's modal keeps its own URL. Reading categories and bulk-assigning them stay behind each screen's own policy.

Source: app/Http/Policies/CategoryManagementPolicy.php

DashboardNoticesPolicy — accepts any plugin capability

platforms/dashboard-notices serves general plugin UI — announcements, the pro-update prompt, newsletter and opt-in notices — rendered by the global admin component on every screen. Gating it on wpsn_manage_platforms (as the surrounding PlatformPolicy does) 403s any single-capability user, so it is opened to any plugin capability instead:

public function verifyRequest(Request $request)
{
    return PermissionManager::currentUserCanAny();
}

PermissionManager::currentUserCanAny() returns true for manage_options holders and for anyone with at least one plugin capability.

Changed in 4.4.0

GET/POST /platforms/dashboard-notices moved out of the PlatformPolicy group into its own group. Code that assumed every platforms/* route implies wpsn_manage_platforms no longer holds.

Source: app/Http/Policies/DashboardNoticesPolicy.php

The permission model

Capabilities and roles are assembled by Services/PermissionManager.php, which exposes filters to customize what is readable and which capabilities map to which users:

apply_filters('wpsocialreviews/readable_permissions', $permissions);
apply_filters('wpsocialreviews/plugin_permissions', $permissions);
apply_filters('wpsocialreviews/user_permissions', $permissions);

Use these (rather than editing policies) to adjust who can access WP Social Ninja features — for example, to grant a custom role management access.

Added in 4.4.0

wpsn_feeds_advance_settings ("Manage Advanced Settings", dashboard group) joins the capability list. SettingsPolicy accepts it, and SettingsController maps it to the advance_settings screen alongside wpsn_reviews_platforms_settings.

SettingsController also narrows the group per platform through wpsocialreviews/settings_platform_capabilities — see Permissions & Licensing filters. A platform absent from that map is refused, so register yours there when you add one.