
I usually store the user’s subscription plan in the `users` table. say the `plan_id` which refers to the subscription plans.

Let’s make a stage for this…

our subscription plans.php

```
return [

	cheap_plan ⇒ [

		‘maximum_list’ ⇒ 20,

	],

	expensive_plan ⇒ [

		‘maximum_list’ ⇒ 50,

	],

];

```

Then we can use in the controller like this (already assumes that only logged in users can use this endpoint)

```
public function create()
{
	$postCount = Auth::user()->loadCount('posts')->posts_count;

	if ($postCount > Auth::user()->plan->maximum_list) {
		abort(403, "You've reached your maximum list. Please upgrade your plan.");
	}

	// proceed to create the list
	// $list = List::create(...)

	// return redirect()->route('lists.show', ['list' => $list]);
}

```

This is a valid way, and for most application, I think this has served its purpose to validate the creation limit.

However, like you mentioned, there is another ‘more centralized’ approach with this.

Using Gate and Policy.

Let’s refactor our previous code to a Gate

```
// AuthServiceProvider.php

class AuthServiceProvider extends ServiceProvider
{
	//

	public function boot()
	{
		$this->registerPolicies();

		Gate::define('create-list', function($user) {
			$postCount = Auth::user()->loadCount('posts')->posts_count;

			if ($postCount > Auth::user()->plan->maximum_list) {
				return Response::deny("You've reached your maximum list. Please upgrade your plan.");
			}

			return Response::allow();
		});
	}
}

```

And in your controller, we can refactor to this

```
public function create()
{
	$this->authorize('create-list');
	// or Gate::allows('create-list');
	// or Gate::inspect('create-list'); // if you want more customized response.

	// proceed to create the list
	// $list = List::create(...)

	// return redirect()->route('lists.show', ['list' => $list]);
}

```

This should already have served your needs. But, maybe are there more opinionated way?

You’re right. Using the policy.

They say, Policy is best when you are dealing with a “resource” or models in a domain. Like in our case, the List model.

And gate is best when you’re dealing an “action”.

But, my personal opinion is that we should use policy whenever possible, since… other than it gives you an excuse to create separate files, it also doesn’t litter your `AuthServiceProvider`… (I don’t really like to modify the service Provider by the way, unless really needed).

Let’s refactor our previous code to a Policy

```
class ListPolicy
{
	use HandlesAuthorization;

	public function create(User $user)
	{
		$postCount = Auth::user()->loadCount('posts')->posts_count;

		if ($postCount > Auth::user()->plan->maximum_list) {
			return Response::deny("You've reached your maximum list. Please upgrade your plan.");
		}

		return Response::allow();
	}

}

```

Oh, notice the method mimics the resource controller? That’s by design I believe from the Laravel team. Kudos to them.

and we can simply use like this in the controller

```
public function create()
{
	$this->authorize('create', List::class);
	// or Gate::allows('create-list', List::class);
	// or Gate::inspect('create-list', List::class); // if you want more customized response.

	// proceed to create the list
	// $list = List::create(...)

	// return redirect()->route('lists.show', ['list' => $list]);
}

```

the `List::class` is just there to help Laravel infers which Policy class to use.

All in all, this way we can avoid the problems where… you can literally create the list from 10 different controllers. We can just put the `$this->authorize()` there and be done with it.


Blog