"La pagina è scaduta per inattività" - Laravel 5.5

La mia pagina di registrazione mostra correttamente il modulo con CsrfToken ( {{ csrf_field() }}) presente nel modulo).

Modulo HTML

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

Sto usando l'autenticazione incorporata per gli utenti. Non è cambiato nulla tranne le rotte e i reindirizzamenti.

Quando invio il modulo (subito dopo averlo ricaricato anche), dà che La pagina è scaduta per inattività. Aggiorna e riprova. errore.

Però mi manca una cosa molto piccola. Ma non sono sicuro di cosa sia. Qualsiasi aiuto?

Aggiornare

Trovato il problema. Il driver di sessione è stato impostato su array. L'ho cambiato in file e l'errore è scomparso. Ma cosa c'è di sbagliato se uso l'array?

Se stai arrivando a questa risposta direttamente da una ricerca , assicurati di aver già aggiunto il token csrf al tuo modulo con {{ csrf_field() }}come l'OP.

Se il tuo driver di sessione è impostato su file:

Potrebbe avere qualcosa a che fare con storage_path non scrivibile. Qui è dove memorizza i dati di sessione relativi ai token se stai utilizzando sessioni basate su file. Può essere verificato conis_writable(config('session.files'))

Per l'OP, il driver di sessione era impostato su array. L'array è solo per test. Poiché i dati non sono persistenti, non sarà in grado di confrontare il token alla richiesta successiva.

Il driver dell'array viene utilizzato durante il test e impedisce la persistenza dei dati archiviati nella sessione.

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

Controlla config / session.php

Infine, un problema che ho appena avuto, avevamo un progetto che ha il dominio della sessione e le impostazioni di sicurezza in config / session.php ma il sito di sviluppo non utilizzava HTTPS (SSL / TLS). Ciò ha causato questo errore generico poiché sessions.secure era impostato su true per impostazione predefinita.

Ho riscontrato lo stesso problema in Laravel 5.5. Nel mio caso, è successo dopo aver modificato un percorso da GET a POST. Il problema era perché ho dimenticato di passare un token CSRF quando sono passato a POST.

Puoi pubblicare un token CSRF nel modulo chiamando:

 {{ csrf_field() }}

Oppure escludi il tuo percorso in app / Http / Middleware / VerifyCsrfToken.php

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

Provali tutti.

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

Ciò ha causato a causa di Illuminate\Session\TokenMismatchException guardare questo esempio di codice come gestirlo correttamente:

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

Il mio caso è stato risolto con SESSION_DOMAIN, nella mia macchina locale doveva essere impostato su xxx.localhost. Stava causando conflitti con la produzione SESSION_DOMAIN, xxx.comche era impostata direttamente nel file di configurazione session.php.

Alcune informazioni sono memorizzate nel cookie che è correlato alle versioni precedenti di laravel in fase di sviluppo. Quindi è in conflitto con i token generati da csrf che vengono generati dalle versioni di un altro. Cancella il cookie e fai un tentativo.

Per chi ha ancora problemi e nulla ha aiutato. Presta attenzione al parametro php.ini mbstring.func_overload. Deve essere impostato su 0. E mbstring.internal_encoding impostato su UTF-8. Nel mio caso è stato un problema.

Ho cambiato l'autorizzazione all'archiviazione e l'errore è sparito. Sembrava che il problema fosse la mancanza di autorizzazione.

sudo chmod -R 775 storage/

aggiungi @csrfnel modulo e vai anche a VerifyCsrfToken.php

App-> HTTP> Middleware-> VerifyCsrfToken.php

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

Nel mio caso, il sito andava bene nel server ma non in locale. Poi mi ricordo che stavo lavorando su un sito web sicuro.
Quindi nel file config.session.php, imposta la variabile secure su false

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

Avevo l'app con più sottodomini e il cookie di sessione era il problema tra quelli. La cancellazione dei cookie ha risolto il mio problema.

Inoltre, prova a impostare il file SESSION_DOMAINin .env . Usa l'esatto sottodominio che stai esplorando.

Assicurati di avere l'ora di sistema corretta sul tuo server web. Nel mio caso, la macchina vagabonda era nel futuro (26 gennaio 14:08:26 UTC 2226) quindi ovviamente il tempo nel cookie di sessione del mio browser era scaduto circa 200 anni fa.

impostare mbstring.func_overload = 2

mi ha aiutato

Ho trovato due soluzioni per evitare questi errori 1) aggiungendo $ protetto tranne = ['/ yourroute'] possibile disabilitare l'ispezione del token csrf dalla root definita. 2) basta commentare \ App \ Http \ Middleware \ VerifyCsrfToken :: riga di classe nel gruppo middleware protetto nel kernel

Ho avuto lo stesso problema ma il problema non è nel framework ma nel browser. Non so perché, ma Google Chrome blocca automaticamente i cookie, nel mio caso. Dopo aver consentito i cookie, il problema è stato risolto.

Risposta breve

Aggiungi la voce del percorso per registerinapp/Http/Middleware/VerifyCsrfToken.php

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

e svuota la cache e il percorso della cache con i comandi:

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

Dettagli

Ogni volta che accedi a un sito Laravel, viene generato un token, anche se la sessione non è stata avviata. Quindi, in ogni richiesta, questo token (memorizzato nei cookie) verrà convalidato rispetto alla sua data di scadenza, impostata nel SESSION_LIFETIMEcampo su config/session.phpfile.

Se mantieni il sito aperto per più del tempo di scadenza e provi a fare una richiesta, questo token verrà valutato e verrà restituito l'errore di scadenza. Quindi, per saltare questa convalida sui moduli che sono al di fuori delle funzioni degli utenti autenticati (come la registrazione o il login) puoi aggiungere la route eccetto in app/Http/Middleware/VerifyCsrfToken.php.

Molte volte sta accadendo perché stai testando il progetto in una data precedente

Soluzione:

usa la nuova scheda in incognito, quindi prova di nuovo.

Motivo:

nel mio caso un altro utente ha effettuato l'accesso con il mio pannello di amministrazione