Where’s the start point?

We’ll try to implement what Laravel documentation describes here: https://laravel.com/docs/5.7/passport#consuming-your-api-with-javascript
Due the fact that I felt it is not even close to want it promises I want to share this article with you to understand better what is happening under the hood, or just save you few hour of investigating what is wrong with that.

Security first

For some security improvements I highly recommend adding the following link into .env file: SESSION_SECURE_COOKIE=true. This will allow cookies to be set only over HTTPS connection. This will protect us from any man-in-the middle attack.
Set it ONLY in production, when you load your website over HTTPS.

And in config/session.php ensure that same_site is set to "strict" in order to disable cross origin requests.

To protect against CSRF we will use Laravel’s csrf-token, but we’ll talk about this a bit later.

Generating cookies

Inside app\Http\Kernel.php insert following lines:

 'api' => [
            \App\Http\Middleware\EncryptCookies::class,
             \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Laravel\Passport\Http\Middleware\CreateFreshApiToken::class,
            ...
        ], 

CreateFreshApiToken middleware will generate a JWT access token, create a cookie with it + CSRF token of current session + an expiration date and add it to the response.
EncryptCookies will ensure that any incoming or outgoing cookies will be encrypted so the client cannot see the actual value of it.
AddQueuedCookiesToResponse will attach the cookie to our response.
StartSession will give us a session based on the cookie. This way we can access user’s data from it.

Make sure all 4 classes are inserted above: 'throttle:60,1' and 'bindings'.

Here comes the twist

If you take a look inside CreateFreshApiToken class, you will find the following method:

 
protected function requestShouldReceiveFreshToken($request)
{
        return $request->isMethod('GET') && $request->user($this->guard);
} 

Until now I haven’t find a good reason for checking if the request method is “GET” (Later edit: I’ve found one. Maybe will discuss it in a further post) We need to give the user a valid cookie as soon as he logs in. And for oblivious reasons the login and register methods should always be a “POST”. So I created a CustomCreateApiToken class and override the method as follows:

use Laravel\Passport\Http\Middleware\CreateFreshApiToken as Middleware;

class CustomCreateApiToken extends Middleware
{
   
    /**
     * Determine if the request should receive a fresh token.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return bool
     */
    protected function requestShouldReceiveFreshToken($request)
    {
        return $request->user($this->guard);
    }
}

Routes middleware

 
$api->version('v1', function ($api) {
    $api->group(['middleware' => 'api'], function ($api) {
        $api->post("register", 'App\Http\Controllers\Api\V1\Auth\RegisterController@register');
        $api->get("register/{token}", 'App\Http\Controllers\Api\V1\Auth\RegisterController@registerActivate');
        $api->post("login", 'App\Http\Controllers\Api\V1\Auth\LoginController@login');
        ...
    });

    // Protected routes
    $api->group(['middleware' => 'auth:api'], function ($api) {
        $api->get('profile', 'App\Http\Controllers\Api\V1\ProfileController@show');
        $api->get('logout', 'App\Http\Controllers\Api\V1\Auth\LoginController@logout');
    });
}); 

As you can see above, we added the login and register routes in a group protected by api middleware in order to call CreateFreshApiToken after the user login.
Profile and logout routes are set under auth:api to be protected by Passport API authentication.

Some more tweaks

Cookie’s lifetime can be set in config\session.php :

 
'lifetime' => env('SESSION_LIFETIME', 120), // minutes

If the cookie expires, our client application should be noticed about that in a nice manner. At this moment Passport returns a JSON like this:

{"message":"Unauthenticated.","status_code":500}

It’s not the best message you can receive. A 500 error code is usually returned for a server error but in our case there is an Authorization error which is usually reported as 401. So I created a Authenticate class, override the authenticate method and catch that 500 response and forwarded a 401 response code with a custom message:

use Illuminate\Auth\Middleware\Authenticate as Middleware;
use Exception;

class Authenticate extends Middleware
{

    /**
     * Determine if the user is logged in to any of the given guards.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function authenticate($request, array $guards)
    {
        try {
            parent::authenticate($request, $guards);
        } catch (Exception $e) {
            abort(401, 'Unauthorized action.');
        }
    } 
}

To be sure it is active you shall check the app\Http\Kernel.php file to have the right route to your class:

 
protected $routeMiddleware = [
        'auth' => \App\Http\Middleware\Authenticate::class,
         ...
    ]; 

Final thoughts

You can craft your own cookie session handling.
If you are implementing this in a low risk app you can set a forever cookie. This way, the user will never be logged out.
If you are working on something big (eg. a bank software) you can set a low lifetime, let’s say 15 mins and after this user should login again.

You can find the updated code here: https://github.com/danielcrt/laravel5.7-passport-dingo-api-boilerplate

If you have any questions or improvements please let us know in comments section.

The post Laravel Basic Authentication with Passport & Dingo API – Improvements appeared first on Crosstech IT | Blog.

• You might save few hours of googling
• You care about your users so you don’t want them to be hacked by a 10yo

Our mission

Create a secure API boilerplate which can be consumed by any client (web & mobile app)

Final result

If you want to skip the process here you can find the result: https://github.com/danielcrt/laravel5.7-passport-dingo-api-boilerplate

Let’s start!

The setup is inspired by ChristophSchmidl’s boilerplate available here: https://github.com/ChristophSchmidl/laravel-5.4-dingo-passport-boilerplate

Install Laravel: https://laravel.com/docs/5.7/installation#installing-laravel

Add Dingo API to composer.json (find latest version here: https://github.com/dingo/api/releases):

"require": {     
    ...     
    "dingo/api": "2.0.0-alpha1" 
}

Put Dingo\Api\Provider\LaravelServiceProvider::class into the providers array of config/app.php 

Run php artisan vendor:publish --provider="Dingo\Api\Provider\LaravelServiceProvider"

Put 'DingoApi' => Dingo\Api\Facade\API::class, 'DingoRoute' => Dingo\Api\Facade\Route::class into aliases array of config/app.php

Update .env file and insert:
API_PREFIX=api API_VERSION=v1

Install CORS. Using this you can handle Cross-Origin Resource Sharing headers and OPTIONS requests.

Run: php artisan vendor:publish --provider="Barryvdh\Cors\ServiceProvider"

Make CORS available to all routes. You can change that behaviour by updating app/Http/Kernel.php and put \Barryvdh\Cors\HandleCors::class into your middleware array.

Move the User-model from app into namespace App\Models and adjust all config files (if any) so everything works as before.
In config/auth.php update:

'providers' => [
    'users' => [
        'driver' => 'eloquent',
        'model' => App\Models\User::class,
    ],
    ...
],

Install Passport via composer require laravel/passport
Register PassportServiceProvider by adding Laravel\Passport\PassportServiceProvider::class to the providers array of config/app.php

Run php artisan vendor:publish --tag=passport-migrations to put the default Passport migrations into database/migrations folder.

Run php artisan migrate

Error?!

If you receive: “Specified key was too long; max key length is 767 bytes”

Open app/Providers/AppServiceProvider.php and inside the boot method set a default string length:

use Illuminate\Support\Facades\Schema;

public function boot() {
     Schema::defaultStringLength(191);
}

We are close

Run php artisan passport:install This command will create the encryption keys needed to generate secure access tokens. In addition, the command will create “personal access” and “password grant” clients which will be used to generate access tokens.

Add Laravel\Passport\HasApiTokens to App\Models\User

Final steps

Thanks to ChristophSchmidl we have some nicely crafted controllers and transformers which we will just describe in few words. You can find them on github.
Under app/Http/Controllers/Api/V1 we create a custom Controller named DingoController which will throw all Laravel exceptions and validation errors to our API responses. You can also find there a LoginController and a RegisterController which validate the input and return the responses.

Under app/Http we have created a folder named Transformers. These are meant to convert your Eloquent objects (eg. User) to a custom JSON which is sent in your API response.

In app/Providers We have DingoExceptionHandlerProvider which handles the HTTP errors related to authentication (eg. 401, 403) and DingoPassportServiceProvider validates the Authorization header.

And finally in routes/api.php you can see some defined routes for Login, Register and Logout.

You’re done!

Thanks for reading by here!

If you have any questions or improvements please let us know in comments section.

The post Laravel Basic Authentication with Passport & Dingo API – Setup appeared first on Crosstech IT | Blog.