Post request in Laravel - Erreur - 419 Désolé, votre session/ 419 votre page a expiré

Question

J'ai installé Laravel 5.7

Ajout d'un formulaire dans le fichier \resources\views\welcome.blade.php

<form method="POST" action="/foo" >
    @csrf
    <input type="text" name="name"/><br/>
    <input type="submit" value="Add"/>
</form>

Ajouté au dossier \routes\web.php

Route::post('/foo', function () {
    echo 1;
    return;
});

Après avoir envoyé une requête POST :

419 Désolé, votre session a expiré. Veuillez rafraîchir et réessayer.

En version 5.6 il n'y avait pas de tel problème.

Answer 1

C'est un problème que j'ai constaté à quelques reprises et qui se produit généralement lorsque l'on utilise apache .

S'il y a des caractères errants ou de nouvelles lignes avant l'ouverture <?php dans l'un des fichiers exécutés, ces caractères sont émis par le serveur web avant que les cookies ne soient préparés et envoyés.

Cela empêche l'envoi de cookies au client, qui doit recommencer une nouvelle session à chaque demande.

Malheureusement, la seule solution est de regarder chaque fichier que vous avez créé ou modifié (ce qui n'est pas si mal si vous utilisez Git) et de s'assurer que <?php sont les premiers caractères de chaque fichier php.

Vous pouvez ignorer les fichiers de visualisation car ils ne sont utilisés qu'après l'envoi des cookies.

Les candidats les plus probables sont les contrôleurs, les fournisseurs de services et les fichiers d'itinéraire.

Answer 2

J'ai également eu un problème de ce type et j'ai découvert que les fichiers de session étaient verrouillés en écriture. Donc, je ne sais pas si vous exécutez votre Laravel via des trucs comme vagrant ou Docker, mais je vous conseille d'essayer de changer les droits du répertoire de session (et des fichiers bien sûr) (Lorsque vous exécutez Laravel dans une VM, vous devriez changer les droits localement et dans la VM (comme, lorsque vous partagez les fichiers via NFS)

Comme ça :

chmod -R 777 storage/framework/sessions
chmod -R 777 storage/logs

Je sais, une permission de 777 est le pire désastre que vous puissiez imaginer. Mais elles sont pratiques pour le dépannage.

Pour être sûr de ne jamais l'oublier j'ai fait un bash script. (Je l'ai appelé lalog, juste parce que je voulais effacer les fichiers journaux et définir les permissions)

Note : Veillez à l'utiliser dans le répertoire de la session. Dans config/session.php, il y a un files déclarée avec l'emplacement. Dans mon cas :

<?php
//...........
'files' => storage_path('framework/sessions'),
//...........

Emplacement : /usr/bin/lalog (C'est un fichier, pas un répertoire)
Exécuter dans le shell en tant que lalog

#!/bin/bash
rm -rf /home/username/Projects/x/storage/logs/laravel.log
echo "Laravel log removed"
touch /home/username/Projects/x/storage/logs/laravel.log
echo "Laravel log created"
chmod -R 777 /home/username/Projects/x/storage/
echo "CHMOD 777 on Storage dir"

Attention ! Cela va permettre l'accès en écriture pour tout le monde, donc soyez prudent avec cela ! Aussi, peut-être qu'il y a des informations utiles dans le fichier journal de Laravel. (soyez sûr de regarder dans ce fichier de log avant d'exécuter mon bash script)

Aussi, je sais que c'est déjà mentionné. Mais, soyez totalement sûr que vous avez toujours

1. Autoriser les cookies dans le navigateur, afin que le jeton puisse être défini dans les cookies.
2. Vérifiez si vous utilisez le @csrf dans votre fichier de lame

Le formulaire devrait ressembler à ceci

<form method="POST" action="{{ route('login') }}">
@csrf
.......
</form>

Answer 3

J'ai eu un problème similaire et j'ai trouvé une solution à cela

si vous faites un écho ou imprimez quelque chose à partir du contrôleur tout en revenant à la vue, ce problème apparaîtra.

donc assurez-vous que vous n'utilisez pas echo ou print quand votre contrôleur retourne

Answer 4

Juste pour dire que j'ai eu les mêmes problèmes. Sur ma propriété locale, cela fonctionnait comme prévu, mais après l'avoir poussé sur le serveur de développement, j'ai également obtenu le message de dépassement du temps de session. Je me suis dit que c'était un problème d'environnement et j'ai remplacé Apache par Nginx, ce qui a miraculeusement fait disparaître le problème.

Answer 5

J'ai eu le même problème dans mon environnement de développement. Il a été résolu en utilisant http://127.0.0.1:8000 au lieu de http://localhost:8000 .