Eroarea HTTP 419 în Laravel indică de obicei token CSRF lipsă, expirat sau nepotrivit cu sesiunea. Protejează formularele POST, PUT, DELETE împotriva request-urilor cross-site forjate din alte site-uri unde utilizatorul e autentificat. Firul explică mecanismul, cum se leagă token-ul de cookie-ul de sesiune și cazurile legitime de excludere, fără a dezactiva protecția global „temporar” pe producție.
Middleware-ul web pornește sesiunea și compară token-ul din formular sau header `X-XSRF-TOKEN` cu valoarea din sesiune. `@csrf` în Blade inserează câmp hidden. Formulare deschise mult timp pot expira odată cu sesiunea — utilizatorul trebuie reîmprospătat sau informat să reîncarce pagina. Token-ul se rotește când regenerarea sesiunii e cerută explicit; după login reușit, un formular vechi deschis în alt tab poate trimite un token invalid chiar dacă sesiunea e autentificată.
Cookie-ul XSRF poate fi citit de JS și trimis ca header pe request-uri same-origin. Fetch din alt domeniu nu primește token valid fără CORS și credențiale configurate explicit — comportament dorit. Pentru API token-based (Sanctum), CSRF se aplică diferit pe rutele stateful. Biblioteci HTTP trebuie să includă credențiale (`withCredentials`) când folosesc cookie de sesiune; altfel serverul vede un utilizator autentificat fără token CSRF și răspunde 419.
Webhook-uri externe (payment provider) necesită excludere pe URI specific, protejată prin semnătură secretă, nu prin CSRF. Liste largi de `$except` sunt un anti-pattern. Documentează fiecare excludere cu motiv și măsură compensatorie. Upload-uri din aplicații mobile native spre endpoint-uri web pot necesita arhitectură separată (token API) în loc de excluderi permanente pe rute sensibile.
Verifică dacă formularul folosește metoda POST reală, nu GET camuflat. Proxy-uri care strip-uiesc cookie-uri sau mix HTTP/HTTPS strică sesiunea. Două tab-uri cu logout într-unul invalidează token-ul în celălalt — mesaj user-friendly reduce frustrarea. Loghează intern evenimentele 419 cu user id și path, fără a expune token-ul; pattern-urile (doar Safari, doar după cache) ghidează fix-ul.
Cum circulă token-ul
Middleware-ul web pornește sesiunea și compară token-ul din formular sau header `X-XSRF-TOKEN` cu valoarea din sesiune. `@csrf` în Blade inserează câmp hidden. Formulare deschise mult timp pot expira odată cu sesiunea — utilizatorul trebuie reîmprospătat sau informat să reîncarce pagina. Token-ul se rotește când regenerarea sesiunii e cerută explicit; după login reușit, un formular vechi deschis în alt tab poate trimite un token invalid chiar dacă sesiunea e autentificată.
AJAX și SPA
Cookie-ul XSRF poate fi citit de JS și trimis ca header pe request-uri same-origin. Fetch din alt domeniu nu primește token valid fără CORS și credențiale configurate explicit — comportament dorit. Pentru API token-based (Sanctum), CSRF se aplică diferit pe rutele stateful. Biblioteci HTTP trebuie să includă credențiale (`withCredentials`) când folosesc cookie de sesiune; altfel serverul vede un utilizator autentificat fără token CSRF și răspunde 419.
Excluderi în VerifyCsrfToken
Webhook-uri externe (payment provider) necesită excludere pe URI specific, protejată prin semnătură secretă, nu prin CSRF. Liste largi de `$except` sunt un anti-pattern. Documentează fiecare excludere cu motiv și măsură compensatorie. Upload-uri din aplicații mobile native spre endpoint-uri web pot necesita arhitectură separată (token API) în loc de excluderi permanente pe rute sensibile.
Debugging 419
Verifică dacă formularul folosește metoda POST reală, nu GET camuflat. Proxy-uri care strip-uiesc cookie-uri sau mix HTTP/HTTPS strică sesiunea. Două tab-uri cu logout într-unul invalidează token-ul în celălalt — mesaj user-friendly reduce frustrarea. Loghează intern evenimentele 419 cu user id și path, fără a expune token-ul; pattern-urile (doar Safari, doar după cache) ghidează fix-ul.