Ошибка 419 http

Are you getting the Laravel error 419 session expired during a post request?

This occurs due to CSRF token verification failure, misconfigured cache, permissions, improper session settings, etc.

At Bobcares, we fix Laravel errors, as a part of our Server Management Services.

Today, let’s have a look into the session expired error. We’ll also see how our Support Engineers fix it.

Laravel Error: 419 session expired

Laravel is a web development framework. It allows customizing configuration. And the user/developer can create a .env file for this purpose.

By default, Laravel is an HTTP driven application. The session provides ways to store information. The available options are files, cookie, database, Memcached or Redis, and array.

This error shows up when a user submits a post request. The error in front-end appears as,

And, in the command line, the error appears as,

419 Sorry, your session has expired. Please refresh and try again.

Many reasons can lead to session expired error. The most obvious reasons are CSRF token failure, cache, permissions, improper session settings.

How we fix the Laravel error 419 session expired?

Our Support Engineers with expertise over a decade in Server Administration fixes Laravel errors. Let’s see the common causes and how we fix it.

1. CSRF token verification failure

The most common reason for the 419 error is CSRF token failure. Cross-site request forgery token is a unique, encrypted value generated by the server.

Laravel generates a CSRF token for each user session. The token verifies the user by requesting the application.

So always include a CSRF token in the HTML form to validate the user request.

The VerifyCsrfToken middleware automatically crosses checks the token in the request to the token stored in the session.

In addition to CSRF token verification, the VerifyCsrfToken middleware also checks the X-CSRF-TOKEN request header.

So, we store the token in the HTML meta tag. Then a library like jQuery can automatically add a token to all request headers. Therefore to fix the CSRF token failure we check the token in the application.

2. Session expired error due to cache

Sometimes, the cache can also lead to session expired error in front-end. This can be both the server cache and browser cache. So, our Support Engineers clear the server cache using

php artisan cache:clear

If this does not fix the error, we ask the customer to clear the browser cache. Many times this fixes the error.

3. Laravel file and folder permissions

Similarly, improper file or folder permission can also lead to errors. Usually, web servers need write-permissions on the Laravel folders storage and vendor. Also, session storage needs write-permission. So, our Support Engineers give permissions as,

chmod -R 755 storage

chmod -R 755 vendor

chmod -R 644 bootstrap/caches

Mostly, this fixes the error.

4. Laravel session setting

Last but not least, session settings can also cause a 419 error. The app/config/session.php is the session config file. Our Experts check the session settings in this file. Hence we correct if there is an error. We always check for a few important parameters – domain and secure.

'domain' => env('SESSION_DOMAIN', null),
'secure' => env('SESSION_SECURE_COOKIE', false), // in case of cookie

These step by step approach fixes the error and make Laravel working again.

[Need assistance in fixing Laravel errors? – Our Experts are available 24/7.]

Conclusion

In short, the Laravel error 419 session expired occur due to many reasons like CSRF token failure, wrong cache, permissions, improper session settings, etc. Today, we saw how our Support Engineers fix this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

You need to setup CSRF https://laravel.com/docs/8.x/csrf

Introduction

Cross-site request forgeries are a type of malicious exploit whereby unauthorized commands are performed on behalf of an authenticated user. Thankfully, Laravel makes it easy to protect your application from cross-site request forgery (CSRF) attacks.

An Explanation Of The Vulnerability

In case you’re not familiar with cross-site request forgeries, let’s discuss an example of how this vulnerability can be exploited. Imagine your application has a /user/email route that accepts a POST request to change the authenticated user’s email address. Most likely, this route expects an email input field to contain the email address the user would like to begin using.

Without CSRF protection, a malicious website could create an HTML form that points to your application’s /user/email route and submits the malicious user’s own email address:

<form action="https://your-application.com/user/email" method="POST">
    <input type="email" value="malicious-email@example.com">
</form>

<script>
    document.forms[0].submit();
</script>

If the malicious website automatically submits the form when the page is loaded, the malicious user only needs to lure an unsuspecting user of your application to visit their website and their email address will be changed in your application.

To prevent this vulnerability, we need to inspect every incoming POST, PUT, PATCH, or DELETE request for a secret session value that the malicious application is unable to access.

Preventing CSRF Requests
Laravel automatically generates a CSRF «token» for each active user session managed by the application. This token is used to verify that the authenticated user is the person actually making the requests to the application. Since this token is stored in the user’s session and changes each time the session is regenerated, a malicious application is unable to access it.

The current session’s CSRF token can be accessed via the request’s session or via the csrf_token helper function:

use IlluminateHttpRequest;

Route::get('/token', function (Request $request) {
    $token = $request->session()->token();

    $token = csrf_token();

    // ...
});

Anytime you define a «POST», «PUT», «PATCH», or «DELETE» HTML form in your application, you should include a hidden CSRF _token field in the form so that the CSRF protection middleware can validate the request. For convenience, you may use the @csrf Blade directive to generate the hidden token input field:

<form method="POST" action="/profile">
    @csrf

    <!-- Equivalent to... -->
    <input type="hidden" name="_token" value="{{ csrf_token() }}" />
</form>

The AppHttpMiddlewareVerifyCsrfToken middleware, which is included in the web middleware group by default, will automatically verify that the token in the request input matches the token stored in the session. When these two tokens match, we know that the authenticated user is the one initiating the request.

CSRF Tokens & SPAs
If you are building an SPA that is utilizing Laravel as an API backend, you should consult the Laravel Sanctum documentation for information on authenticating with your API and protecting against CSRF vulnerabilities.

Excluding URIs From CSRF Protection
Sometimes you may wish to exclude a set of URIs from CSRF protection. For example, if you are using Stripe to process payments and are utilizing their webhook system, you will need to exclude your Stripe webhook handler route from CSRF protection since Stripe will not know what CSRF token to send to your routes.

Typically, you should place these kinds of routes outside of the web middleware group that the AppProvidersRouteServiceProvider applies to all routes in the routes/web.php file. However, you may also exclude the routes by adding their URIs to the $except property of the VerifyCsrfToken middleware:

<?php

namespace AppHttpMiddleware;

use IlluminateFoundationHttpMiddlewareVerifyCsrfToken as Middleware;

class VerifyCsrfToken extends Middleware
{
    /**
     * The URIs that should be excluded from CSRF verification.
     *
     * @var array
     */
    protected $except = [
        'stripe/*',
        'http://example.com/foo/bar',
        'http://example.com/foo/*',
    ];
}

You need to setup CSRF https://laravel.com/docs/8.x/csrf

Introduction

Cross-site request forgeries are a type of malicious exploit whereby unauthorized commands are performed on behalf of an authenticated user. Thankfully, Laravel makes it easy to protect your application from cross-site request forgery (CSRF) attacks.

An Explanation Of The Vulnerability

In case you’re not familiar with cross-site request forgeries, let’s discuss an example of how this vulnerability can be exploited. Imagine your application has a /user/email route that accepts a POST request to change the authenticated user’s email address. Most likely, this route expects an email input field to contain the email address the user would like to begin using.

Without CSRF protection, a malicious website could create an HTML form that points to your application’s /user/email route and submits the malicious user’s own email address:

<form action="https://your-application.com/user/email" method="POST">
    <input type="email" value="malicious-email@example.com">
</form>

<script>
    document.forms[0].submit();
</script>

If the malicious website automatically submits the form when the page is loaded, the malicious user only needs to lure an unsuspecting user of your application to visit their website and their email address will be changed in your application.

To prevent this vulnerability, we need to inspect every incoming POST, PUT, PATCH, or DELETE request for a secret session value that the malicious application is unable to access.

Preventing CSRF Requests
Laravel automatically generates a CSRF «token» for each active user session managed by the application. This token is used to verify that the authenticated user is the person actually making the requests to the application. Since this token is stored in the user’s session and changes each time the session is regenerated, a malicious application is unable to access it.

The current session’s CSRF token can be accessed via the request’s session or via the csrf_token helper function:

use IlluminateHttpRequest;

Route::get('/token', function (Request $request) {
    $token = $request->session()->token();

    $token = csrf_token();

    // ...
});

Anytime you define a «POST», «PUT», «PATCH», or «DELETE» HTML form in your application, you should include a hidden CSRF _token field in the form so that the CSRF protection middleware can validate the request. For convenience, you may use the @csrf Blade directive to generate the hidden token input field:

<form method="POST" action="/profile">
    @csrf

    <!-- Equivalent to... -->
    <input type="hidden" name="_token" value="{{ csrf_token() }}" />
</form>

The AppHttpMiddlewareVerifyCsrfToken middleware, which is included in the web middleware group by default, will automatically verify that the token in the request input matches the token stored in the session. When these two tokens match, we know that the authenticated user is the one initiating the request.

CSRF Tokens & SPAs
If you are building an SPA that is utilizing Laravel as an API backend, you should consult the Laravel Sanctum documentation for information on authenticating with your API and protecting against CSRF vulnerabilities.

Excluding URIs From CSRF Protection
Sometimes you may wish to exclude a set of URIs from CSRF protection. For example, if you are using Stripe to process payments and are utilizing their webhook system, you will need to exclude your Stripe webhook handler route from CSRF protection since Stripe will not know what CSRF token to send to your routes.

Typically, you should place these kinds of routes outside of the web middleware group that the AppProvidersRouteServiceProvider applies to all routes in the routes/web.php file. However, you may also exclude the routes by adding their URIs to the $except property of the VerifyCsrfToken middleware:

<?php

namespace AppHttpMiddleware;

use IlluminateFoundationHttpMiddlewareVerifyCsrfToken as Middleware;

class VerifyCsrfToken extends Middleware
{
    /**
     * The URIs that should be excluded from CSRF verification.
     *
     * @var array
     */
    protected $except = [
        'stripe/*',
        'http://example.com/foo/bar',
        'http://example.com/foo/*',
    ];
}

Likely Laravel Framework fix

IlluminateFoundationHttpMiddlewareVerifyCsrfToken and EncryptCookies should be changed to never PHP serialize the CSRF token.

Explanation

I believe it’s a framework problem caused by PHP serialization in the X-XSRF-TOKEN cookie used by Telescope’s Ajax request.

IlluminateFoundationHttpMiddlewareVerifyCsrfToken@getTokenFromRequest()

protected function getTokenFromRequest($request)
{
    $token = $request->input('_token') ?: $request->header('X-CSRF-TOKEN');

    if (! $token && $header = $request->header('X-XSRF-TOKEN')) {
        $token = $this->encrypter->decrypt($header, static::serialized());
    }

    return $token;
}

static::serialized() in that decrypt call is always false even if your application’s middleware asks for cookie PHP serialization.

i.e., status code 419 comes from these hashes being compared by the VerifyCsrfToken middleware:

• 'YHOOALqzvSbuzQQVurmTpQJM5NaVArIgoEStYrgd'
• 's:40:"YHOOALqzvSbuzQQVurmTpQJM5NaVArIgoEStYrgd'

https://laravel.com/docs/5.6/upgrade «Configuring Cookie Serialization»

It’s suggested to make this change:

AppHttpMiddlewareEncryptCookies

protected static $serialize = true;

AppHttpMiddlewareVerifyCsrfToken::serialized() is pulling the base IlluminateCookieMiddlewareEncryptCookies::$serialize = false rather than the documented AppHttpMiddlewareEncryptCookies$serialize = true override.

App-level fix

Instead of protected static $serialize = true; as suggested by the 5.6 upgrade guide, override the serialized() method and don’t serialize the CSRF token:

class EncryptCookies extends BaseEncrypter
{
    public static function serialized($name)
    {
        return $name !== 'XSRF-TOKEN';
    }
}

Framework fix

Never PHP serialize the CSRF token since this hasn’t been working since August and nobody complained about it until now. It doesn’t really make any sense to serialize short-lived tokens (~3 hours?) that are just PHP strings? Anyone still serializing cookies are probably to cover complex data (array, object) or long time-to-live expiration that could be a pain to migrate to plain unserialized cookies.

Why hasn’t anyone noticed this problem in Laravel?

Because the stragglers still PHP serializing cookies probably use Blade @csrf / request('_token') to pass CSRF tokens across requests. In that case, VerifyCsrfToken@getTokenFromRequest() short-circuits the buggy conditional.