ReviewRateable.
Live demo
Developer docs Core 2.2 · Pro 1.x

Search documentation

Search Core and Pro guides, including code examples.

↑ ↓ to browse · Enter to open · Esc to close
PRO · COMMERCIAL

Authorization & guards.

Install the complete review experience, choose an interface, and configure customer and team workflows.

← All Pro topics

Authorization

Pro's customer and management services use the configured guard. Set guard to null for your application's default, or use a named guard.

'guard' => null,
'view_ability' => 'viewProductReviews',
'create_ability' => 'reviewProduct',
'moderation' => ['ability' => 'moderateReviews', 'per_page' => 10],

View and create abilities receive the reviewable model. A null view ability allows public viewing of published reviews; a null create ability allows any authenticated user to submit. A configured but undefined ability denies access.

Choose who can moderate

Pro deliberately does not create an administrator column, role system, or moderator list. Choose one authorization source already owned by the consuming application, then define the configured Gate in App\Providers\AppServiceProvider::boot().

Option A: an application-owned admin flag. If your user table already has a trusted is_admin boolean, use it directly:

use App\Models\Product;
use App\Models\User;
use Illuminate\Support\Facades\Gate;

Gate::define('moderateReviews', fn (User $user, Product $product): bool =>
    $user->is_admin
);

If the application does not have that field, create it with an application migration and cast it to a boolean on User. Default it to false and grant it only through a trusted administrative workflow—never accept is_admin from registration, profile, or review-form input.

Schema::table('users', function (Blueprint $table): void {
    $table->boolean('is_admin')->default(false)->index();
});

// App\Models\User
protected function casts(): array
{
    return ['is_admin' => 'boolean'];
}

Option B: roles or permissions. If the application already uses Spatie Laravel Permission or an equivalent authorization package, delegate the Gate to its existing API. Pro does not require or install that package.

Gate::define('moderateReviews', fn (User $user, Product $product): bool =>
    $user->hasRole('admin') || $user->hasPermissionTo('moderate reviews')
);

Create the admin role or moderate reviews permission through that application's normal seeder or administration workflow, assign it only to trusted accounts, and keep the permission's guard consistent with Pro's configured guard.

Option C: model ownership. For a marketplace or multi-owner application, authorize the owner of the specific reviewable model:

Gate::define('moderateReviews', fn (User $user, Product $product): bool =>
    $user->getKey() === $product->owner_id
);

Rules can be combined when administrators and model owners should both moderate:

Gate::define('moderateReviews', fn (User $user, Product $product): bool =>
    $user->is_admin || $user->getKey() === $product->owner_id
);

Define the other customer-facing abilities separately; moderator permission does not automatically grant submission or other application permissions:

Gate::define('viewProductReviews', fn (?User $user, Product $product): bool => true);

Gate::define('reviewProduct', fn (User $user, Product $product): bool =>
    $user->hasVerifiedEmail()
);

Guest-accessible view Gates must accept a nullable user. Require authentication on your submission/admin routes and use your real purchase/booking eligibility rules where needed. If view_ability is configured, moderators must pass both the view ability and moderateReviews.

Management fails closed: a missing, null, or empty moderation ability does not grant access. Normal reviewer authentication is not moderator permission. Target, department, connection, and permissions are rechecked during actions.

Use a shared cache for production throttling across multiple servers. Built-in limits are safeguards, not comprehensive spam prevention. For tenant databases, establish the correct connection on every request and model class; changing a connection during Livewire hydration is rejected rather than silently crossing databases.