«Срок действия страницы истек из-за бездействия» - Laravel 5.5

На моей странице регистрации форма отображается правильно, и в ней {{ csrf_field() }}присутствует CsrfToken ( )).

Форма HTML

<form class="form-horizontal registration-form" novalidate method="POST" action="{{ route('register') }}">
        {{ csrf_field() }}
        ....
</form>

Я использую встроенную аутентификацию для пользователей. Не менял ничего кроме маршрутов и редиректов.

Когда я отправляю форму (также сразу после перезагрузки), она сообщает, что срок действия страницы истек из-за бездействия. Обновите страницу и попробуйте еще раз. ошибка.

Боже, я упускаю очень маленькую вещь. Но не уверен, что это такое. Любая помощь?

Обновить

Нашел проблему. Драйвер сеанса был установлен на массив. Изменил его на файл, и ошибка исчезла. Но что не так, если я использую массив?

Если вы приходите к этому ответу непосредственно из поиска , убедитесь, что вы уже добавили токен csrf в свою форму с {{ csrf_field() }}помощью OP.

Если у вас установлен драйвер сеанса в файл:

Возможно, это связано с тем, что storage_path недоступен для записи. Здесь хранятся данные сеанса относительно токенов, если вы используете сеансы на основе файлов. Это можно проверить с помощьюis_writable(config('session.files'))

Для OP драйвер сеанса был установлен в массив. Массив предназначен только для тестирования. Поскольку данные не сохраняются, он не сможет сравнить токен при следующем запросе.

Драйвер массива используется во время тестирования и предотвращает сохранение данных, хранящихся в сеансе.

https://laravel.com/docs/5.5/session#configuration

Проверьте config / session.php

Наконец, у меня возникла проблема: у нас был проект с доменом сеанса и безопасными настройками в config / session.php, но сайт разработки не использовал HTTPS (SSL / TLS). Это вызвало эту общую ошибку, поскольку по умолчанию для sessions.secure было установлено значение true.

Я столкнулся с той же проблемой в Laravel 5.5. В моем случае это произошло после изменения маршрута с GET на POST. Проблема заключалась в том, что я забыл передать токен CSRF, когда переключился на POST.

Вы можете опубликовать токен CSRF в своей форме, позвонив:

 {{ csrf_field() }}

Или исключите свой маршрут в app / Http / Middleware / VerifyCsrfToken.php

 protected $except = [
        'your/route'
    ];

Попробуйте их все.

composer dump-autoload
php artisan optimize
php artisan cache:clear
php artisan config:clear
php artisan route:clear
php artisan view:clear

Это вызвано тем, что Illuminate\Session\TokenMismatchException посмотрите на этот пример кода, как правильно с этим справиться:

https://gist.github.com/jrmadsen67/bd0f9ad0ef1ed6bb594e

Мой случай был решен SESSION_DOMAIN, на моем локальном компьютере нужно было установить xxx.localhost. Это вызывало конфликты с продуктом SESSION_DOMAIN, xxx.comкоторый был установлен непосредственно в файле конфигурации session.php.

Некоторая информация хранится в куки, которая связана с предыдущими версиями laravel в разработке. Таким образом, это противоречит токенам, сгенерированным csrf, которые генерируются другими версиями. Просто очистите файл cookie и попробуйте.

Для тех, у кого проблема осталась и ничего не помогло. Обратите внимание на параметр mbstring.func_overload в php.ini. Он должен быть установлен в 0. И mbstring.internal_encoding установить в UTF-8. В моем случае это было проблемой.

Я меняю разрешение на хранилище и ошибка пропала. Казалось, проблема заключалась в отсутствии разрешения.

sudo chmod -R 775 storage/

Добавить @csrf в форму и также перейдите на VerifyCsrfToken.php

приложение-> Http-> Middleware-> VerifyCsrfToken.php

protected $except = [
        'paste your route here'
    ];

В моем случае сайт был в порядке на сервере, но не на локальном. Потом я вспомнил, что работал над безопасным сайтом.
Итак, в файле config.session.php установите для переменной secure значение false.

'secure' => env('SESSION_SECURE_COOKIE', false),

У меня было приложение с несколькими поддоменами, и проблема с файлом cookie была между ними. Очистка файлов cookie решила мою проблему.

Кроме того , попробуйте установить SESSION_DOMAINв .env файле. Используйте именно тот субдомен, который вы просматриваете.

Убедитесь, что на вашем веб-сервере установлено правильное системное время. В моем случае бродячая машина была в будущем (26 января 14:08:26 UTC 2226), поэтому, конечно, время в cookie сеанса моего браузера истекло около 200+ лет назад.

установить mbstring.func_overload = 2

это помогло мне

Я нашел два решения, чтобы избежать этой ошибки: 1) добавив protected $ except = ['/ yourroute'], возможно отключить проверку токена csrf из определенного корня. 2) просто прокомментируйте строку \ App \ Http \ Middleware \ VerifyCsrfToken :: class в группе защищенного промежуточного программного обеспечения в ядре

У меня была такая же проблема, но проблема не во фреймворке, а в браузере. Я не знаю почему, но в моем случае Google Chrome автоматически блокирует файлы cookie. После разрешенных файлов cookie проблема была решена.

Короткий ответ

Добавьте запись маршрута для registerвapp/Http/Middleware/VerifyCsrfToken.php

protected $except = [
        '/routeTo/register'
    ];

и очистите кеш и маршрут кеша с помощью команд:

php artisan cache:clear && php artisan route:clear

подробности

Каждый раз, когда вы заходите на сайт Laravel, генерируется токен, даже если сеанс не был запущен. Затем в каждом запросе этот токен (хранящийся в файлах cookie) будет проверяться на соответствие сроку его действия, установленному в SESSION_LIFETIMEполе config/session.phpфайла.

Если вы оставите сайт открытым дольше, чем время истечения срока действия, и попытаетесь сделать запрос, этот токен будет оценен, и ошибка истечения срока действия вернется. Итак, чтобы пропустить эту проверку в формах, которые не входят в функции аутентифицированных пользователей (например, регистрация или вход), вы можете добавить маршрут except в app/Http/Middleware/VerifyCsrfToken.php.

Много раз это происходит, потому что вы тестируете проект на заднем плане.

Решение:

используйте новую вкладку в режиме инкогнито, а затем проверьте ее снова.

причина:

в моем случае другой пользователь вошел в мою админ-панель