CSRF token mismatch and Unauthenticated #41
Comments
mbougarne commented Jan 13, 2020
I can’t get it to work with Nuxt in the front-end, firstly I got the **419 ** error number when I tried to access to /login which is a CSRF token issue, I disabled the **CSRF ** token by adding wildcard access in VerifyCsrfToken Middleware:
I passed the login part with that, but I faced another one which is 401
Unauthenticated: Although I’m in the stateful mode
Laravel app is running on: http://localhost:8000/
Nuxt app is running on: http://localhost:3000/
I think, there’s an issue on «`EnsureFrontendRequestsAreStateful«
My Request using Axios as Nuxt Module:
The text was updated successfully, but these errors were encountered:
danpastori commented Jan 13, 2020
mbougarne commented Jan 14, 2020
driesvints commented Jan 14, 2020
I’ll leave this to @taylorotwell to investigate.
taylorotwell commented Jan 14, 2020
No. Airlock does not require you to put everything in the same app. I’ve tested it fine with Vue CLI. These are all CORS issues.
mbougarne commented Jan 14, 2020
I don’t think so, I used laravel-cors
monsterdream commented Jan 16, 2020
@mbougarne agree, that same situation here.
danpastori commented Jan 17, 2020
I got to this point yesterday and part of it was CORS. However if you are to the point where you are getting a valid 401 response, try changing the SESSION_DRIVER to cookie (mentioned in #11). A combination of correct CORS, SESSION_DOMAIN, and SESSION_DRIVER got this resolved.
I managed to get this working with the NuxtJS auth module as well and pushed the code to help out.
I wrote a quick guide to getting them working together focused mainly on NuxtJS frontend with their first class auth module: https://serversideup.net/using-laravel-airlock-with-nuxtjs/.
If you guys need any help, let me know!
SeinopSys commented Jan 18, 2020 •
I found that I needed the following middleware to get any form of working CSRF with the current instructions as written.
Reading the token from the cookie header like the middleware above does will not protect against CSRF since that cookie is sent along with the request regardless of where it came from, defeating the purpose of CSRF protection entirely.
billisonline commented Jan 24, 2020
@SeinopSys your solution worked for me, thanks!
SeinopSys commented Jan 24, 2020 •
@billisonline I sincerely hope that you meant appending the header via JS, otherwise, by adding that middleware in your codebase, you are effectively making CSRF protection pointless. I’ve edited my previous comment to make this clearer nonetheless.
wannymiarelli commented Feb 1, 2020 •
@SeinopSys Yes, this is what I actually did with fetch. The Laravel doc is clear about how to send back the CSRF token but yes, I think that would be a good idea to add some kind of reference in the readme.
steks89 commented Mar 6, 2020 •
@danpastori solution’s worked for me
SESSION_DRIVER=cookie (maybe is obvious for some people, but I think it could be in the airlock’s documentation),
Also people need to clear cookies before every test.
ouhaohan8023 commented Mar 13, 2020
I find another reason. If you use Api Token rather than SPA. Your app/Http/Kernel.php file should look like this
paprotsky commented Mar 19, 2020
tnduc commented Mar 20, 2020 •
@taylorotwell Can you support me
POST: /api/curent-user: message: «Unauthenticated.»
My config:
SESSION_DRIVER=cookie
patrikengborg commented Mar 23, 2020
I had this problem with getting an «Unauthenticated» error (401) for subsequent requests after a successful login. In my case it was because I made some API requests in nuxtServerInit or in the created hook. Because of how Nuxt works, those requests are made from the server and not from the client. And I guess the appropriate headers is not included then by default. I found two different solutions.
Make sure the request is made only from the client by using:
The other solution is to set proxyHeaders: true in the axios options. According to the docs:
In SSR context, this options sets client requests headers as default headers for the axios requests. This is useful for making requests which need cookie based auth on server side. This also helps making consistent requests in both SSR and Client Side code.
I hope this helps someone. I was banging my head for a while, before I figured out what was going on.
@taylorotwell @driesvints I think you would spare yourself a lot of support requests if you added a note about this trap in the docs. Many users seem to be stuck because of this, and think this is a problem with Sanctum, which it’s not. Nuxt and Laravel seems to be a popular combo, and it would be a shame if they gave up on using Sanctum because of this.
Laragon/Nginx + Laravel + Nuxt: 419 — CSRF token mismatch?
Прошу помочь разобраться и решить задачу. Серия уроков, материал которых взял за основу: https://youtu.be/KFgi3IqavK4
Путь к проекту:
C:\laragon\www\larastart-project
В этой директории две папки:
C:\laragon\www\larastart-project\backend
C:\laragon\www\larastart-project\frontend
В первую (backend) установлен фреймворк Laravel.
Во вторую (frontend) установлен фреймворк Nuxt.
Содержимое файла auto.larastart-project.test.conf:
Зависимости в composer.json. Для аутентификации используется пакет Sanctum: https://laravel.com/docs/7.x/sanctum#spa-authentication
Зависимости в package.json
Файл nuxt.config.js. Показаны настройки относящиеся к аутентификации.
Проверяем запрос токена в программе Postman: https://www.postman.com/
Видно, что данные отдаются.
Далее делаем страницу с формой для теста: pages\auth\signin.vue
В списке Cookies на вкладке Application нет XSRF-TOKEN. Вроде бы здесь он тоже должен быть при отправке данных формы.
Простой 2 комментария
laravel csrf token mismatch exception after session timeout
in our laravel 5 app, the login is through ajax. if user logout and log back in before session expires, everything is fine. but if user logout and stay idle on that page until session is expired, user will get a csrfTokenMismatch exception if they attempt to log back in.
i know in verifyCsrfToken middleware, laravel checks if session matches with the csrf token. also in Guard.php logout() method, session will be cleared on logout.
so my questions are:
is session really flushed on logout, if so how come user can still log back in before the session i set expires?
what happens to csrf token when session is expired?
and lastly, how is this issue usually handled in an elegant way?
3 Answers 3
This answer is in reference to version 5.4, perhaps previous versions but I haven’t tested those.
The root of the problem is the CSRF token is expired on the client side which makes any POST to the server fail with that token.
IF you’re using AJAX, you could use the API routes which do not do CSRF verification by default.
In addition, you should handle the CSRF error when it occurs in a way that works well for your application. Below is an example of something very basic you could do.
By the way, to test both of these changes, you can modify the session settings. I just set the lifetime to 1 for testing. Then, set it back when you’re finished (it is 120 by default). You’ll want to login, load your form page, wait over a minute, then attempt your POST.
Laravel Framework Russian Community
Пролог
Начало работы
Архитектурные концепции
Основное
Погружение
Безопасность
База данных
Eloquent ORM
Тестирование
Пакеты
Предотвращение атак CSRF
Введение
Межсайтовая подделка запроса – это разновидность вредоносного эксплойта, при котором неавторизованные команды выполняются от имени аутентифицированного пользователя. К счастью, Laravel позволяет легко защитить ваше приложение от Межсайтовой подделки запроса (Сross Site Request Forgery – CSRF).
Объяснение уязвимости
Без защиты от CSRF вредоносный веб-сайт может создать HTML-форму, которая указывает на маршрут вашего приложения /user/email и отправляет собственный адрес электронной почты злоумышленника:
Если вредоносный веб-сайт автоматически отправляет форму при загрузке страницы, злоумышленнику нужно только подтолкнуть ничего не подозревающего пользователя вашего приложения посетить свой веб-сайт, и его адрес электронной почты будет изменен в вашем приложении.
Предотвращение запросов от CSRF
Laravel автоматически генерирует «токен» CSRF для каждой активной пользовательской сессии, управляемой приложением. Этот токен используется для проверки того, что аутентифицированный пользователь действительно является лицом, выполняющим запросы к приложению. Поскольку этот токен хранится в сессии пользователя и изменяется каждый раз при повторном создании сессии, вредоносное приложение не может получить к нему доступ.
К CSRF-токену текущей сессии можно получить доступ через сессию запроса или с помощью глобального помощника csrf_token :
Каждый раз, когда вы создаете HTML-форму в своем приложении, вы должны включать в форму скрытое поле _token CSRF, чтобы посредник CSRF мог проверить запрос. Для удобства вы можете использовать директиву Blade @csrf для создания скрытого поля ввода, содержащего токен:
CSRF-токены и SPA-приложения
Если вы создаете SPA, который использует Laravel в качестве серверной части API, вам следует обратиться к документации Laravel Sanctum для получения информации об аутентификации с помощью вашего API и защите от уязвимостей CSRF.
Исключение URI из защиты от CSRF
По желанию можно исключить набор URI из защиты от CSRF. Например, если вы используете Stripe для обработки платежей и используете их систему веб-хуков, вам нужно будет исключить маршрут обработчика веб-хуков Stripe из защиты от CSRF, поскольку Stripe не будет знать, какой токен CSRF отправить вашим маршрутам.
Для удобства посредник CSRF автоматически отключается для всех маршрутов при выполнение тестов.
Токен X-CSRF
Затем, вы можете указать библиотеке, такой как jQuery, автоматически добавлять токен во все заголовки запросов. Это обеспечивает простую и удобную защиту от CSRF для ваших приложений с использованием устаревшей технологии JavaScript на основе AJAX:
Токен X-XSRF
Этот файл Cookies, в первую очередь, отправляется для удобства разработчика, поскольку некоторые фреймворки и библиотеки JavaScript, такие как Angular и Axios, автоматически помещают его значение в заголовок X-XSRF-TOKEN в запросах с одним и тем же источником.
ERROR CSRF token mismatch #2719
Comments
StormYudi commented Nov 16, 2020 •
Background:
Describe
I’ve installed the latest 1.1.1 version panel in my CentOS 7 server, after the setup, I was trying to login in the panel, and then I’ve got an error with message CSRF token mismatch, http code 419.
The login form with X-CSRF-Token header is empty, I think something is wrong, is that a bug?
The text was updated successfully, but these errors were encountered:
DomiiBunn commented Nov 16, 2020
Most likley your php version is out of date. Try asking for help here 1st https://discord.gg/PN6eYsBY if that’s the solution close the issue please ^.^
StormYudi commented Nov 17, 2020
Most likley your php version is out of date. Try asking for help here 1st https://discord.gg/PN6eYsBY if that’s the solution close the issue please ^.^
Thanks for your help, But I am using PHP7.4 with Mysql 5.7 🙁
DomiiBunn commented Nov 17, 2020
StormYudi commented Nov 17, 2020
There is no logs 🙁 the file is empty, I will try to reinstall the panel in ubuntu, thanks
DomiiBunn commented Nov 17, 2020
There has to be a log if you get an error ^.^ try to go to the panel again and than run the log command
StormYudi commented Nov 17, 2020
I checked it again and it was really not there 🙁
mistermodcreator commented Nov 17, 2020 •
I got the same Error and the log is the following:
Probably this can help?
YajTPG commented Nov 18, 2020
Usually clearing Cookies fixes that error. (Atleast for me)
alexevladgabriel commented Nov 18, 2020
Are you using a ssl configuration with http:// connection?
Do you have generated ssl for that domain?
StormYudi commented Nov 20, 2020
@alexevladgabriel I am not using https at that time.
I simply reinstall the OS and reinstall the panel again, it works now, thank you all.
ajarmoszuk commented Dec 15, 2020
This is unfortunately still an issue, running PHP 7.4.13. Not sure what is happening but there is no information to suggest any issues. Nothing is to be found in the logs.
ajarmoszuk commented Dec 15, 2020
Site is running on HTTPS.
Techwolf12 commented Dec 23, 2020
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
fabm3n commented Jan 12, 2021
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
This would not change anything because the default value is already false: https://github.com/pterodactyl/panel/blob/develop/config/session.php#L163
Dungeonseeker commented Feb 2, 2021
Same issue here on Ubuntu Server 20.10 running Apache & PHP 7.14
#0 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(358): Swift_Transport_AbstractSmtpTransport->assertResponseCode #1 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(147): Swift_Transport_AbstractSmtpTransport->readGreeting #2 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/SendmailTransport.php(50): Swift_Transport_AbstractSmtpTransport->start #3 /var/www/pterodactyl/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Mailer.php(65): Swift_Transport_SendmailTransport->start #4 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php(521): Swift_Mailer->send #5 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Mail/Mailer.php(288): Illuminate\Mail\Mailer->sendSwiftMessage #6 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Notifications/Channels/MailChannel.php(65): Illuminate\Mail\Mailer->send #7 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Notifications/NotificationSender.php(146): Illuminate\Notifications\Channels\MailChannel->send #8 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Notifications/NotificationSender.php(105): Illuminate\Notifications\NotificationSender->sendToNotifiable #9 /var/www/pterodactyl/vendor/laravel/framework/src/Illuminate/Support/Traits/Localizable.php(19): Illuminate\Notifications\NotificationSender->Illuminate\Notifications\
eupedroosouza commented Sep 19, 2021
Sem SSL aqui. Ele falha ao criar um cookie «XSRF-TOKEN» porque deseja definir como seguro e os cookies não https não podem ser definidos como seguros.
Consertar isso:
This worked for me, thanks!
SovernT13 commented Nov 21, 2021
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
This also worked for me. I was using a custom installer script though.
jordi2010 commented Nov 21, 2021 •
No SSL here. It fails on creating a cookie «XSRF-TOKEN» because it wants to set it as secure and non-https cookies can’t be set as secure.
Worked for me. I used https first instead of http.
This setting was not changed back when going through the installer
Software-Noob commented Nov 21, 2021
We don’t offer any installers. If you have an issue with such, contact the author of it directly. The fix is above should someone stumble upon this in the future.
The value depends on what protocol scheme you choose during installation, and also, our support bot in Discord can respond to this issue.
