Forem: mohammed osama

NestJS Caching Globally neatly.

mohammed osama — Tue, 02 Nov 2021 15:31:12 +0000

First things first, if you don't know about the NestJS Caching module, It's quite easy to understand, It will let you cache whatever you want through the CACHE_MANAGER and take control over it and make decision whether to keep or delete, and keep for how long etc.., Also allowing you to configure your own cache driver which could be Redis, Memcached etc...

First follow the docs for the installation,
https://docs.nestjs.com/techniques/caching#installation

here is a snippet to register your cache driver.

import {  CacheModule } from '@nestjs/common';
import {ConfigModule} from '@nestjs/config';
import { config } from './shared/config/index';

@Module({
imports: [
 ConfigModule.forRoot({
      cache: true,
      load: [() => config],
      isGlobal: true,
    }),
CacheModule.registerAsync({
      imports: [ConfigModule],
      useFactory: async (config: ConfigService) => {
        const cache = config.get('cache');
        const driver = config.get(cache.driver);
        // Later, if needed, create a cache factory to instantiate different drivers based on config.
        if (cache.driver === 'redis') {
          return {
            ttl: ms(cache.ttl), // using ms package to parse 15m to timestamp.
            store: require('cache-manager-redis-store'),
            host: driver.host,
            port: driver.port,
          };
        }
        return {
          ttl: ms(cache.ttl),
        };
      },
      inject: [ConfigService],
    })
]
});

we are registering the cache module async, and injecting the config service to load the configuration that will be initialised through our .env file, there we will be determining which driver to use and its proper configuration,
while registering the cache module, I'm assuming that I'll be using Redis, unless that, I'll be falling back to the defaults which will be in-memory cache.

If you don't know yet how to handle config or get started with config, here's a snippet of how my config looks like

import 'dotenv/config'
export const config = {
  cache: {
    ttl: process.env.CACHE_TTL as string,
    driver: process.env.CACHE_DRIVER || 'redis',
  },
}

and that's it, we are good to go for the important part of this article, which is caching globally.

NestJS provides a cache interceptor that will cache all of the GET HTTP Requests, but this is kinda insufficient as if you delete/update/create, this cached HTTP request will never be synced, so you will encounter a problem while syncing your frontend or mobile. Luckily, NestJS is binding the caching interceptor at the providers. Therefore, we can provide our own custom cache interceptor which will allow us to avoid this problem and sync properly.

You can take a look at auto-caching responses at the docs to see how they're caching. https://docs.nestjs.com/techniques/caching#auto-caching-responses
Simply, They're using their cache interceptor and adding it to the provider, which will literally intercept each incoming request and make a decision whether to cache or not.

  providers: [
    {
      provide: APP_INTERCEPTOR,
      useClass: CacheInterceptor,
    },
  ],

If you ever wondered, how they're caching, or what's happening behind the scenes, here's a snippet of the interceptor to understand what's going on there, then we will customize it a bit to match our needs.



  async intercept(
    context: ExecutionContext,
    next: CallHandler,
  ): Promise<Observable<any>> {
    const key = this.trackBy(context);
    const ttlValueOrFactory =
      this.reflector.get(CACHE_TTL_METADATA, context.getHandler()) ?? null;

    if (!key) {
      return next.handle();
    }
    try {
      const value = await this.cacheManager.get(key);
      if (!isNil(value)) {
        return of(value);
      }
      const ttl = isFunction(ttlValueOrFactory)
        ? await ttlValueOrFactory(context)
        : ttlValueOrFactory;
      return next.handle().pipe(
        tap(response => {
          const args = isNil(ttl) ? [key, response] : [key, response, { ttl }];
          this.cacheManager.set(...args);
        }),
      );
    } catch {
      return next.handle();
    }
  }

Each Interceptor at NestJS is implementing the NestInterceptor interface which has a method called intercept. in our case, the intercept method at the caching interceptor is going to use the trackBy method, which will define the key of the cached response, so at your first GET Request, the generated key doesn't exist, but later the key will exist so it will return the data from the cache using the generated key earlier. If the key doesn't exist, sure enough, it will just return next to go to the next interceptor or proceed with its life-cycle which could be hitting your controllers/resolvers or whatever.

I think you might be wondering how the key is going to be generated, or how the trackBy method is actually working.

 trackBy(context: ExecutionContext): string | undefined {
    const request = context.switchToHttp().getRequest();
    const { httpAdapter } = this.httpAdapterHost;

    const isGetRequest = httpAdapter.getRequestMethod(request) === 'GET';
    const excludePaths = [
      // Routes to be excluded
    ];
    if (
      !isGetRequest ||
      (isGetRequest &&
        excludePaths.includes(httpAdapter.getRequestUrl(request)))
    ) {
      return undefined;
    }
    return httpAdapter.getRequestUrl(request);
  }

As you see, the trackBy method accepts a context which could be your GraphQL context, express Context which contains (request, response etc..) or fastify context which contains (request, response etc..).
then it will retrieve your request via switching the context to HTTP (incase of graphql, this will be undefined) and therefore, this cache interceptor won't be working if you are working via graphql, however, you can make this work with graphql using

 GqlExecutionContext.create(context).getContext()

NOTE: If you are following along and trying to cache globally the responses while using graphql, this will just give you an idea, of what to do, but this isn't adopted yet to work with graphql, as you will be facing problems with caching depending on the fetched attributes or so.

Then it will be checking if the incoming request if it is a GET Request. If our case is a get request, the method will return the url (including your query parameters) which will be your key for caching. So, in essence, NestJS is caching your responses by taking the URL and making it the key of your cache and its value is the full response that was returned on the first cycle.
Therefore, they were mentioning out at the docs, that it will literally auto-cache your responses and globally if you set up the interceptor, Hopefully, you got the idea now!.

Now, Let's dive into the most interesting part which is syncing the cache and make our own interceptor.


import { Injectable, CacheInterceptor, ExecutionContext, CACHE_KEY_METADATA } from '@nestjs/common';

@Injectable()
export class HttpCacheInterceptor extends CacheInterceptor {
  protected cachedRoutes = new Map();
  trackBy(context: ExecutionContext): string | undefined {
    const request = context.switchToHttp().getRequest();
    // if there is no request, the incoming request is graphql, therefore bypass response caching.
    // later we can get the type of request (query/mutation) and if query get its field name, and attributes and cache accordingly. Otherwise, clear the cache in case of the request type is mutation.
    if (!request) {
      return undefined;
    }
    const { httpAdapter } = this.httpAdapterHost;
    const isHttpApp = httpAdapter && !!httpAdapter.getRequestMethod;
    const cacheMetadata = this.reflector.get(CACHE_KEY_METADATA, context.getHandler());

    if (!isHttpApp || cacheMetadata) {
      return cacheMetadata;
    }
    const isGetRequest = httpAdapter.getRequestMethod(request) === 'GET';
    if (!isGetRequest) {
      setTimeout(async () => {
        for (const values of this.cachedRoutes.values()) {
          for (const value of values) {
            // you don't need to worry about the cache manager as you are extending their interceptor which is using caching manager as you've seen earlier.
            await this.cacheManager.del(value);
          }
        }
      }, 0);
      return undefined;
    }
    // to always get the base url of the incoming get request url.
    const key = httpAdapter.getRequestUrl(request).split('?')[0];
    if (this.cachedRoutes.has(key) && !this.cachedRoutes.get(key).includes(httpAdapter.getRequestUrl(request))) {
      this.cachedRoutes.set(key, [...this.cachedRoutes.get(key), httpAdapter.getRequestUrl(request)]);
      return httpAdapter.getRequestUrl(request);
    }
    this.cachedRoutes.set(key, [httpAdapter.getRequestUrl(request)]);
    return httpAdapter.getRequestUrl(request);
  }
}

Depending on the REST API conventions, if you have posts CRUD for example, the index will be /api/posts, and the show by id can be like /api/posts/1, and if you are searching and using query string it might be like /api/posts?search=title and so on...

The Idea is depending on the base url of the CRUD which in our example is /api/posts, this will be our key and will have other sub-keys which could be /api/posts/3 or api/posts/4 for another post, or /api/posts?search=title

we are using a Map data-structure to have our own key is the base key which will be /api/posts and the rest of the sub-keys will be inside an array, so the map would look like this

'/api/posts' => ['/api/posts', '/api/posts/1', '/api/posts?search=title'];

Why doing so?, because if there is any upcoming request that Isn't GET method, it means that we are either updating/creating/deleting, so we will have to invalidate these related urls keys and flush their responses so we can sync later on the next request. and we are invaliding them at this snippet

Note: If we haven't done it this way, we will just invalidate the whole cache to re-sync later, which isn't really a great thing to do, therefore we made the Map to keep track of what's going to be updated, and what's related to flush it later.


if (!isGetRequest) {
      setTimeout(async () => {
        for (const values of this.cachedRoutes.values()) {
          for (const value of values) {
            await this.cacheManager.del(value);
          }
        }
      }, 0);
      return undefined;
    }

why setTimeout?, because we want to do this in the background, and not to throttle the incoming http request and make it wait for the in-validating process.

So If the incoming request is Get Request, we will need to add it our map

Scenario 1:

The Map has the base key which is /api/posts, but we couldn't find at the array of this key the incoming request url string.

   if (this.cachedRoutes.has(key) && !this.cachedRoutes.get(key).includes(httpAdapter.getRequestUrl(request))) {
      this.cachedRoutes.set(key, [...this.cachedRoutes.get(key), httpAdapter.getRequestUrl(request)]);
      return httpAdapter.getRequestUrl(request);
    }

Example: If we are having the map like this

'/api/posts' => ['/api/posts']

and the incoming request is something like this /api/posts?search=title
then we will be inserting this to our map. We don't even have the incoming key

this.cachedRoutes.set(key, [httpAdapter.getRequestUrl(request)]);

Example: If you are hitting for the first time
api/posts
we don't have this yet at the map, so we are setting it.

Scenario 2:

What if our first HTTP GET Request is
api/posts?search=title
No problems, cause we are taking the first segment of the url since are splitting the url by ? which will always return us the base url and in our case will be 'api/posts', same goes if your first hit is /api/posts, this as well will always return us the base url.

Caveats: this is the most simplest way to cache and sync your responses automatically without being involved at the hassle of doing it on your own. For example, It's a bit redundant to save all of the posts and when showing the post by id, you also save it on its own, would be better if you get it from the cached values (would introduce complexity as if you have many posts and trying to find this post, this would be heavier than querying it from the database directly and will slow down your response due to looping and trying to find the post.).

Don't forget to use the custom HTTP Interceptor we just made to see it in action.😂

providers: [{
    provide: APP_INTERCEPTOR,
    useClass: HttpCacheInterceptor,
  }]

Alright, that's it for the custom caching interceptor . I hope you enjoyed it ✌️, I see ya at another article 🙈. Don't forget to follow me if you enjoyed this one 👀

How to separate your Routes at Laravel conveniently.

mohammed osama — Wed, 25 Mar 2020 11:22:51 +0000

I think we all have encountered a situation where we had a massive file contains our routes. I can't lie, this was driving me crazy for a long time and I had to figure a solution to tackle this issue. So, Here is what I have ended up using to structure my routes files.

Initially, I thought of making use of the fact that the group route method accepts a file, and that's how laravel addresses our routes at RouteServiceProvider

 <?php

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Route;

class RouteServiceProvider extends ServiceProvider
{
    /**
     * This namespace is applied to your controller routes.
     *
     * In addition, it is set as the URL generator's root namespace.
     *
     * @var string
     */
    protected $namespace = 'App\Http\Controllers';

    /**
     * Define your route model bindings, pattern filters, etc.
     *
     * @return void
     */
    public function boot()
    {
        //

        parent::boot();
    }

    /**
     * Define the routes for the application.
     *
     * @return void
     */
    public function map()
    {
        $this->mapApiRoutes();

        $this->mapWebRoutes();

        //
    }

    /**
     * Define the "web" routes for the application.
     *
     * These routes all receive session state, CSRF protection, etc.
     *
     * @return void
     */
    protected function mapWebRoutes()
    {
        Route::middleware('web')
             ->namespace($this->namespace)
             ->group(base_path('routes/web.php'));
    }

    /**
     * Define the "api" routes for the application.
     *
     * These routes are typically stateless.
     *
     * @return void
     */
    protected function mapApiRoutes()
    {
        Route::prefix('api')
             ->middleware('api')
             ->namespace($this->namespace)
             ->group(base_path('routes/api.php'));
    }
}

I abstracted the routes which concern the user for example to a file called users.php and duplicated the mapApiRoutes to be mapUsersRoutes and navigated to my users.php file.

 /**
     * Define the routes for the application.
     *
     * @return void
     */
    public function map()
    {
        $this->mapApiRoutes();

        $this->mapWebRoutes();

        $this->mapUsersRoutes();

        //
    }
/**
     * Define the "api" routes for the application.
     *
     * These routes are typically stateless.
     *
     * @return void
     */
    protected function mapUsersRoutes()
    {
        Route::prefix('api')
             ->middleware('api')
             ->namespace($this->namespace)
             ->group(base_path('routes/users.php'));
    }

I know what you are thinking of, apparently, this isn't the best solution as whenever we start to create a new file, we will have to register it as we did before. So, I had to improve this initial idea.

I thought of breaking the routes file into regions that are common across the whole application, and I've come into a thought that all of our routes can't be out of this scope: authenticated, guest, and public routes.

I structured my routes folder to the following:

├── routes   

│   ├── api    

│   │   ├── public

│   |   │   ├── users.php 

│   │   ├── auth

│   |   │   ├── users.php 

│   │   ├── guest

│   |   │   ├── users.php

at first glance, you might think that "well, It didn't change much, we are going to map these files again". But, we can actually make use of a function called "glob" that php provides by nature which is sort of out of the box solution, as we aren't coupled to laravel solutions.

glob accepts a pattern and can find filenames under a path that's matching our pattern. Hence our routes are structured under specific folders, we can now find all of the files under these folders and register them to their middlewares.

<?php

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Route;

class RouteServiceProvider extends ServiceProvider
{
    /**
     * This namespace is applied to your controller routes.
     *
     * In addition, it is set as the URL generator's root namespace.
     *
     * @var string
     */
    protected $namespace = 'App\Http\Controllers';

    /**
     * Define the routes for the application.
     *
     * @return void
     */
    public function map()
    {
        $this->mapAuthRoutes();
        $this->mapGuestRoutes();
        $this->mapPublicRoutes();
//        $this->mapWebRoutes();

        //
    }

    /**
     * Define the "web" routes for the application.
     *
     * These routes all receive session state, CSRF protection, etc.
     *
     * @return void
     */
    protected function mapWebRoutes()
    {
        Route::middleware('web')
            ->namespace($this->namespace)
            ->group(base_path('routes/web.php'));
    }

    /**
     * Define the "api" routes for the application.
     *
     * These routes are typically stateless.
     *
     * @return void
     */
    protected function mapAuthRoutes()
    {
        foreach (glob(base_path('routes/api/auth/*.php')) as $file) {
            Route::prefix('api')
                ->middleware(['api', 'auth:api'])
                ->group($file);
        }
    }

    protected function mapGuestRoutes()
    {

        foreach (glob(base_path('routes/api/guest/*.php')) as $file) {
            Route::prefix('api')
                ->middleware(['api', 'guest:api'])
                ->group($file);
        }
    }
    protected function mapPublicRoutes()
    {
        foreach (glob(base_path('routes/api/public/*.php')) as $file) {
            Route::prefix('api')
                ->middleware('api')
                ->group($file);
        }
    }
}

Now, whenever we create a new file, the foreach is going to have it as it's a matching pattern (the file is under the pathname and it has the extension of PHP, so it matches our pattern). Brilliant!, but hold on for a minute.

How these files are going to be registered?

If you reviewed laravel's lifecycle, you would understand that service providers are part of the lifecycle of laravel's request, which we can make use of this feature to register our routes dynamically.

That's it for this one!, I hope you enjoyed it. Don't forget to follow me! ✌️

Laravel Form Request Tips & Tricks.

mohammed osama — Fri, 13 Mar 2020 00:13:24 +0000

First things first, If you don't understand laravel's form request, or you haven't got your legs wet yet. It's super easy to understand.

In essence, we use the laravel form request to validate the incoming request to your endpoint but abstracted out of your controller, which is neater than validating the request at the controller's method. this opens the ability to reuse the validation rules as they're abstracted away.
Laravel provides you with the ability to create a form request validation throughout its artisan command.

php artisan make:request UpdatePostFormRequest

Alright, Let's destruct the output class of this command piece by piece to understand what's there.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UpdatePostFormRequest extends FormRequest
{

    public function authorize()
    {
      return true;
    }

    public function rules()
    {
         return [
            'title' => sprintf(
              'required|string|unique:posts,title,%s', $this->post->title
            ),
            'description' => 'required|min:8|max:255|string',
        ];
    }
}

authorize method is used to determine whether the user is authorized or not make to this request. Thus, it must return boolean.
rules method is used to determine the validation rules which we will use later to validate the incoming request against.

We can use it as follows.


<?php

namespace App\Http\Controllers;

use App\Post;
use App\Http\Controllers\Controller;
use App\Http\Requests\UpdatePostFormRequest;

class PostController extends Controller
{

    public function edit(Post $post)
    {
        return view('posts.edit')->withPost($post);
    }

    /**
     * @param UpdatePostFormRequest $request
     */
    public function update(Post $post, UpdatePostFormRequest $request)
    {

        $post->update($request->all());
    }
}

Let's hold on for a minute here to figure out what's going on here.

we used the edit method to show up the form that will contain a couple of inputs to let the user update that post.
we used the update method to update the post.

After understanding what's going on here, Let's understand the update method specifically as it uses the form request.

It's simple, you won't proceed to the body of the update method if there is something went wrong with the validation, as the validation will spit the error messages and redirect you back ( we might not need that in case of API handling because redirecting will cause you a 404 error. We will look into that later).

Note: Don't use $request->all() as this eliminates the benefit of form validation because once you pass the validation stage, you are going to use all of the submitted form data and insert them to the database and these inputs may contain a hidden one or unneeded input that might cause a security issue.

For example, imagine a user used the inspect element or intercepted the request after bypassing the client-side validation, and injected an input field with id value, most probably this will cause the database to squawk if you haven't determined what inputs are fillable or what is guarded.

Instead, you can just use $request->validated(), which will get only the inputs that are passed by the validation, which you only need to insert to the database.

Tip: the validated method behind the scenes works by retrieving the data from the request via the keys of the array we have at our rules method at our form request.


     /**
     * Get the attributes and values that were validated.
     *
     * @return array
     *
     * @throws \Illuminate\Validation\ValidationException
     */
    public function validated()
    {
        if ($this->invalid()) {
            throw new ValidationException($this);
        }

        $results = [];

        $missingValue = Str::random(10);

        foreach (array_keys($this->getRules()) as $key) {
            $value = data_get($this->getData(), $key, $missingValue);

            if ($value !== $missingValue) {
                Arr::set($results, $key, $value);
            }
        }

        return $results;
    }

Alright, I think you got the idea of how to play around with form request, Let's get advanced.

What's there for advanced usage?.

how to handle custom messages.
handle authorize dynamically.
handle failed validation and control redirection in case of dealing with API.
handle failed authorization.
how to inject data that must be validated however you don't want the user to submit.
how to customize the passed values after validation.

1. How to handle custom messages

at a certain point while coding, you might need to show a custom message for the user that might be more readable. Fortunately, laravel gives you this advantage by using a method called messages.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UpdatePostFormRequest extends FormRequest
{

    public function authorize()
    {
      return true;
    }

    public function rules()
    {
      return [
            'title' => sprintf(
              'required|string|unique:posts,title,%s', $this->post->title
            ),
            'description' => 'required|min:8|max:255|string',
        ];
    }

    public function messages()
    {
        return [
            'title.unique' => 'title must be a unique.',
            'description.min'  => 'description minimum length bla bla bla'
        ];
    }
}

You can destruct every single validation rule you created as shown above and write your custom message if needed. Moreover, you can use localization to show message depending on the user's language.

2. handle authorize dynamically.

You probably noticed that we return a hardcoded boolean value at the authorize method, which is useless at the moment. So, how could we take control over that dynamically?. you can do whatever you want using the authenticated user and dig into your roles relationships and by the end of whatever you do, you must return a boolean value. Or, you can just use policy and gates which is something, fortunately, laravel provides by nature.

Have you ever meditated the app/Http/Kernel.php file specifically at the $routeMiddleware array


<?php

namespace App\Http;

use Illuminate\Foundation\Http\Kernel as HttpKernel;

class Kernel extends HttpKernel
{
     /**
     * The application's route middleware.
     *
     * These middlewares may be assigned to groups or used individually.
     *
     * @var array
     */
    protected $routeMiddleware = [
        'auth' => \App\App\Http\Middleware\Authenticate::class,
        'auth.basic' => \Illuminate\Auth\Middleware\AuthenticateWithBasicAuth::class,
        'bindings' => \Illuminate\Routing\Middleware\SubstituteBindings::class,
        'cache.headers' => \Illuminate\Http\Middleware\SetCacheHeaders::class,
        'can' => \Illuminate\Auth\Middleware\Authorize::class,
        'guest' => \App\App\Http\Middleware\RedirectIfAuthenticated::class,
        'signed' => \Illuminate\Routing\Middleware\ValidateSignature::class,
        'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
        'verified' => \Illuminate\Auth\Middleware\EnsureEmailIsVerified::class,
    ];
}

We have got the can middleware there which we can use on our routes/controllers. Luckily Laravel gives us the ability to use the functionality of can middleware through our user model if you extend Authenticatable. Here is why.



<?php

namespace App\User;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
}

If you take a look at the Authenticatable which is Illuminate\Foundation\Auth\User.

<?php

namespace Illuminate\Foundation\Auth;

use Illuminate\Auth\Authenticatable;
use Illuminate\Auth\MustVerifyEmail;
use Illuminate\Auth\Passwords\CanResetPassword;
use Illuminate\Contracts\Auth\Access\Authorizable as AuthorizableContract;
use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract;
use Illuminate\Contracts\Auth\CanResetPassword as CanResetPasswordContract;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Foundation\Auth\Access\Authorizable;

class User extends Model implements
    AuthenticatableContract,
    AuthorizableContract,
    CanResetPasswordContract
{
    use Authenticatable, Authorizable, CanResetPassword, MustVerifyEmail;
}

Then if you take a look at the Authorizable trait, you will see it there.


<?php

namespace Illuminate\Foundation\Auth\Access;

use Illuminate\Contracts\Auth\Access\Gate;

trait Authorizable
{
    /**
     * Determine if the entity has a given ability.
     *
     * @param  string  $ability
     * @param  array|mixed  $arguments
     * @return bool
     */
    public function can($ability, $arguments = [])
    {
        return app(Gate::class)->forUser($this)->check($ability, $arguments);
    }

    /**
     * Determine if the entity does not have a given ability.
     *
     * @param  string  $ability
     * @param  array|mixed  $arguments
     * @return bool
     */
    public function cant($ability, $arguments = [])
    {
        return ! $this->can($ability, $arguments);
    }

    /**
     * Determine if the entity does not have a given ability.
     *
     * @param  string  $ability
     * @param  array|mixed  $arguments
     * @return bool
     */
    public function cannot($ability, $arguments = [])
    {
        return $this->cant($ability, $arguments);
    }
}

Take a look at the can method, It uses service container to resolve the gate which we talked about earlier. Also, it returns boolean. Which makes you easily can do that

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UpdatePostFormRequest extends FormRequest
{

    public function authorize()
    {
      return auth()->user()->can('update-post', $this->post);
    }
}

Note: In order to use the currently authenticated user, make sure that this route is protected with the auth middleware, in order to avoid crashing. unless that, you are trying to use can method on null.

In order to achieve the above methodology, you have to register a policy and define a gate with the name of 'create-post' and it calls the policy which contains your logic.

Laravel also has an artisan command to make you a policy.

php artisan make:policy PostPolicy

The convention to name policy is {ModelName} concatenated by Policy.


<?php

namespace App\Policies;

use App\{User, Post};

class PostPolicy
{
    /**
     * Determine if the given post can be updated by the user.
     *
     * @param  \App\User  $user
     * @param  \App\Post  $post
     * @return bool
     */
    public function update(User $user, Post $post)
    {
        return $user->id === $post->user_id;
    }
}

Laravel reserves the first parameter of any policy method and retrieves the user for you. If you have any other model needed you can pass it as other parameters to the method which in our case is the post model.
Note: In a real-world example, I keen on using a declarative programming style which at this point can be followed like this.



    public function update(User $user, Post $post)
    {
        return $user->is($post->user);
        // or with extra check if we have roles the declarative way.
        // return $user->is($post->user) && $user->roles->contains($roleModel);

    }

This is way more declarative, as we don't put any logic here that is a burden code and can't be reused, try to avoid that.

Note: If you don't what is "is" method, It's used to determine if two models have the same ID and belong to the same table.

Alright, we created our logic for the update method, how to bind this to a gate?.


<?php

namespace App\Providers;

use App\Post;
use App\Policies\PostPolicy;
use Gate;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;

class AuthServiceProvider extends ServiceProvider
{
    /**
     * The policy mappings for the application.
     *
     * @var array
     */
    protected $policies = [
        Post::class => PostPolicy::class,
    ];

    /**
     * Register any application authentication / authorization services.
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();
        Gate::define('update-post', 'App\Policies\PostPolicy@update');


        //
    }
}

Congratulations, now we can achieve what we have done earlier, as we bound the gate name 'update-post' to the logic that's at our policy via using the can method.

3. handle failed validation and control redirection in case of dealing with API.

Laravel by default invokes the method failedValidation whenever any of the rules we created aren't passed. If we dig into this method at the form request that laravel provides we will understand why we get a redirection.

<?php
namespace Illuminate\Foundation\Http;

class FormRequest extends Request implements ValidatesWhenResolved
{

     /**
     * Handle a failed validation attempt.
     *
     * @param  \Illuminate\Contracts\Validation\Validator  $validator
     * @return void
     *
     * @throws \Illuminate\Validation\ValidationException
     */
    protected function failedValidation(Validator $validator)
    {
        throw (new ValidationException($validator))
                    ->errorBag($this->errorBag)
                    ->redirectTo($this->getRedirectUrl());
    }
}

Uhmmm, we got the error bag there and we got a redirection there which is pretty annoying in case of API requests. How to tackle this? 🙄

Let's create our own form request that extends laravel's form request to override this.


<?php

namespace App\Http\Requests;

use Illuminate\Contracts\Validation\Validator;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Exceptions\HttpResponseException;

abstract class APIRequest extends FormRequest
{
    /**
     * Determine if user authorized to make this request
     * @return bool
     */
    public function authorize()
    {
        return true;
    }
    /**
     * If validator fails return the exception in json form
     * @param Validator $validator
     * @return array
     */
    protected function failedValidation(Validator $validator)
    {
        throw new HttpResponseException(response()->json(['errors' => $validator->errors()], 422));
    }
    abstract public function rules();
}

Then at any form request that's used for an API endpoint, we can use this class instead of the form request that laravel provides.

4. handle failed authorization.

whenever there is a failed authorization, laravel throws an exception by default that you can handle at the render method at app/Exceptions/Handler.php


<?php

namespace App\Exceptions;

use Exception;
use Illuminate\Auth\Access\AuthorizationException;
use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler;

class Handler extends ExceptionHandler
{
    /**
     * A list of the exception types that are not reported.
     *
     * @var array
     */
    protected $dontReport = [
        //
    ];

    /**
     * A list of the inputs that are never flashed for validation exceptions.
     *
     * @var array
     */
    protected $dontFlash = [
        'password',
        'password_confirmation',
    ];

    /**
     * @param  Exception $execption
     * @return void
     */
    public function report(Exception $exception)
    {
        parent::report($exception);
    }

    /**
     * Render an exception into an HTTP response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Exception  $exception
     * @return \Illuminate\Http\Response
     */
    public function render($request, Exception $exception)
    {
        if ($exception instanceof AuthorizationException) {
            return response()->json([
                'message' => $exception->getMessage(),
            ], 401);
        }
        return parent::render($request, $exception);
    }
}

If you don't know what's going on here, whenever an exception is thrown, laravel passes by the render method and then it renders this exception, we can check against the upcoming exception and intercept that and return our own message or whatever you want. unless that let laravel renders.

Alright, but how did we know that the thrown exception is authorization exception?. If we check at the form request class of laravel, we will see that the failed authorization method throws this exception.
we can override this method once more and throw this exception with our own message instead of rendering the message to the end-user "unauthorized attempt" which isn't clear enough at a certain point.


<?php
use Illuminate\Auth\Access\AuthorizationException;

class UpdatePostFormRequest extends FormRequest
{
   public function failedAuthorization()
   {
      throw new AuthorizationException("You don't have the authority to update this post");
   }
}

It's not only tied to throwing this exception with a custom message, feel free to implement any logic needed.

5. how to inject data that must be validated however you don't want the user to submit.

I remember once upon a time I needed that, but I don't remember the situation at the moment. Anyways!, I'll show you how to achieve that, and you might use it at a certain scenario you have.

Laravel takes the request inputs and queries passed and apply the validation rules on them, but it doesn't do that directly, it uses a method called validationData. and at this point, we can override it and inject whatever we want and this method will be called and the validation will be applied on what's returned from the validationData.

Let's take a look at the base form request of laravel, what it does there.


    /**
     * Get data to be validated from the request.
     *
     * @return array
     */
    public function validationData()
    {
        return $this->all();
    }

It returns all of the request data, and it uses the all method because we extend the laravel's request class which has all method.

we can make use of that by overriding this method.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UpdatePostFormRequest extends FormRequest
{

    public function authorize()
    {
      return true;
    }

    public function rules()
    {
         return [
            'title' => sprintf(
              'required|string|unique:posts,title,%s', $this->post->title
            ),
            'description' => 'required|min:8|max:255|string',
            'user_id' => ''
        ];
    }
    protected function validationData()
    {
        return array_merge($this->all(), [
            'user_id' => $this->user()->id
        ]);
    }
}

We added the user_id to the validation rules, the user won't be passing that for sure, and even if the user passed it, we are going to override it by the user id of the currently authenticated id.

Tip: passing a value of empty string for a key means that there's no validation for this key. However, it can exist and we can take it when using validated (since it's a key of the array we have at our rules method)

6. how to customize the passed request values after validation.

I guess you probably guessed it since we have the validated method, we can override it and merge the values coming from the original validated method with whatever we want.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UpdatePostFormRequest extends FormRequest
{

    public function authorize()
    {
      return true;
    }

    public function rules()
    {
         return [
            'title' => sprintf(
              'required|string|unique:posts,title,%s', $this->post->title
            ),
            'description' => 'required|min:8|max:255|string',
        ];
    }
    public function validated()
    {
        return array_merge(parent::validated(), [
            'user_id' => $this->user()->id
        ]);
    }
}

at this point, the user doesn't pass his user_id, and when we call the validated method, we are calling the validated method we created here which overrides the one that laravel gives us by default. We get the parent validated values and merge them with the user_id, and that way we have the user_id automatically injected and we can use it to directly update/create the record at the database without preparing/associating/attaching it.

Alright, that's it for the form request. I hope you enjoyed it ✌️, I see ya at another article 🙈. Don't forget to follow me if you enjoyed this one 👀