“A página expirou devido à inatividade” - Laravel 5.5

Minha página de registro está exibindo o formulário corretamente com CsrfToken ( {{ csrf_field() }}) presente no formulário).

HTML do formulário

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

Estou usando autenticação embutida para os usuários. Não mudou nada, exceto as rotas e redirecionamentos.

Quando eu envio o formulário (logo após recarregar também), dá que A página expirou devido à inatividade. Atualize e tente novamente. erro.

Meu Deus, estou faltando uma coisa muito pequena. Mas não tenho certeza do que é. Qualquer ajuda?

Atualizar

Encontrou o problema. O driver da sessão foi definido como array. Alterou para arquivo e o erro desapareceu agora. Mas o que há de errado se eu usar array?

Se você chegou a esta resposta diretamente de uma pesquisa , certifique-se de que já adicionou o token csrf ao seu formulário com {{ csrf_field() }}o OP semelhante.

Se você tiver o driver de sessão definido como arquivo:

Pode ter algo a ver com o storage_path não ser gravável. É aqui que ele armazena os dados da sessão relativos aos tokens, se você estiver usando sessões baseadas em arquivo. O pode ser verificado comis_writable(config('session.files'))

Para o OP, o driver da sessão foi definido como array. Array é apenas para teste. Como os dados não são persistentes, não será possível comparar o token na próxima solicitação.

O driver de array é usado durante o teste e evita que os dados armazenados na sessão sejam mantidos.

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

Verifique config / session.php

Por último, um problema que acabei de ter, tínhamos um projeto que tinha o domínio da sessão e configurações seguras em config / session.php, mas o site de desenvolvimento não estava usando HTTPS (SSL / TLS). Isso causou esse erro genérico, uma vez que sessions.secure foi definido como true por padrão.

Encontrei o mesmo problema no Laravel 5.5. No meu caso, aconteceu depois de mudar uma rota de GET para POST. O problema era porque eu esqueci de passar um token CSRF quando mudei para o POST.

Você pode postar um token CSRF em seu formulário chamando:

 {{ csrf_field() }}

Ou exclua sua rota em app / Http / Middleware / VerifyCsrfToken.php

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

Experimente todos eles.

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

Isso ocorreu devido ao Illuminate\Session\TokenMismatchException olhar para este exemplo de código de como lidar com isso corretamente:

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

Meu caso foi resolvido com SESSION_DOMAIN, na minha máquina local teve que ser definido como xxx.localhost. Isso estava causando conflitos com a produção SESSION_DOMAIN, xxx.comque foi definida diretamente no arquivo de configuração session.php.

Algumas informações são armazenadas no cookie que estão relacionadas a versões anteriores do laravel em desenvolvimento. Portanto, está em conflito com tokens gerados por csrf que são gerados por versões de terceiros. Limpe o cookie e experimente.

Pra quem ainda tem problema e nada ajudou. Preste atenção no parâmetro php.ini mbstring.func_overload. Ele deve ser definido como 0. E mbstring.internal_encoding definido como UTF-8. No meu caso, isso foi um problema.

Mudei a permissão para armazenamento e o erro desapareceu. Parecia que a falta de permissão era o problema.

sudo chmod -R 775 storage/

adicione @csrfno formulário e também vá para VerifyCsrfToken.php

app-> Http-> Middleware-> VerifyCsrfToken.php

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

No meu caso, o site estava bem no servidor, mas não no local. Então me lembro que estava trabalhando em um site seguro.
Portanto, no arquivo config.session.php, defina a variável secure para false

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

Eu tinha o aplicativo com vários subdomínios e o cookie de sessão era o problema entre eles. Limpar os cookies resolveu meu problema.

Além disso, tente definir o SESSION_DOMAINem .env arquivo. Use o subdomínio exato que você está navegando.

Certifique-se de ter a hora correta do sistema em seu servidor web. No meu caso, a máquina vagabunda estava no futuro (26 de janeiro 14:08:26 UTC 2226), então é claro que o tempo no cookie de sessão do meu navegador expirou cerca de 200 anos atrás.

definir mbstring.func_overload = 2

isso me ajudou

Eu descobri duas soluções para evitar esses erros 1) adicionando protected $ except = ['/ yourroute'] possível desabilitar a inspeção do token csrf da raiz definida. 2) apenas comentar a linha \ App \ Http \ Middleware \ VerifyCsrfToken :: class no grupo de middleware protegido no kernel

Tive o mesmo problema, mas o problema não está no framework e sim no navegador. Não sei por que, mas o google chrome bloqueia cookies automaticamente, no meu caso. Após a permissão dos cookies, o problema foi resolvido.

Resposta curta

Adicionar a entrada da rota para registeremapp/Http/Middleware/VerifyCsrfToken.php

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

e limpe o cache e a rota do cache com os comandos:

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

Detalhes

Cada vez que você acessa um site Laravel, um token é gerado, mesmo que a sessão não tenha sido iniciada. Então, a cada solicitação, esse token (armazenado nos cookies) será validado contra seu tempo de expiração, definido no SESSION_LIFETIMEcampo em config/session.phparquivo.

Se você mantiver o site aberto por mais do que o tempo de expiração e tentar fazer uma solicitação, esse token será avaliado e o erro de expiração retornará. Portanto, para pular essa validação em formulários que estão fora das funções de usuários autenticados (como registro ou login), você pode adicionar a rota exceto em app/Http/Middleware/VerifyCsrfToken.php.

Muitas vezes está acontecendo porque você está testando o projeto em data anterior

Solução:

use a nova guia anônima e teste-a novamente.

razão:

no meu caso, outro usuário fez login no meu painel de administração