Laravel “CSRF token mismatch” for POST with laravel-cors and axios

Question

I have a domain_A running Laravel 5.8 engine to return API on web route. It must check origins to let serve just a few domains, included domain_B.

Barryvdh/laravel-cors
I installed barryvdh/laravel-cors by composer and configured it globally updating the Kernel.php. This should works on web route too.

kernel.php

protected $middleware = [
   ...
  \Barryvdh\Cors\HandleCors::class,
];

Then I config the Laravel Cors using the standard configuration as test to allow any domain.

/config/cors.php

 return [
    'supportsCredentials' => false,
    'allowedOrigins' => ['http:www.domain_b.com','https:www.domain_b.com','http:domain_b.com'],
    'allowedHeaders' => ['Access-Control-Allow-Origin', 'X-CSRF-TOKEN', 'Content-Type', 'X-Requested-With'],
    'allowedMethods' => ['*'], // ex: ['GET', 'POST', 'PUT',  'DELETE']
    'exposedHeaders' => [],
    'maxAge' => 0,
];

The axios config is:

(domain_a)/ Repository.js

import axios from 'axios/index';

const baseDomain = "https://domain_a";
const baseURL = `${baseDomain}`;

let withCredentials = false;

const token = document.head.querySelector('meta[name="csrf-token"]');

const headers = {
   'X-CSRF-TOKEN': token.content,
   'Access-Control-Allow-Origin': '*',
   'X-Requested-With': 'XMLHttpRequest',
   'Content-Type': 'application/json',
};


export default axios.create({
    baseURL,
    withCredentials: withCredentials,
    headers: headers
});

GET requests are filtered as well, PUT request return a 419 error why? I have set 'allowedMethods' => ['*'] so it should work... what I'm missing?

[EDIT]

ON debug I got this error right now...

message: "CSRF token mismatch."

Why POST doesn't get the header Token?

I tried to pass the POST token also like this:

 const token = document.head.querySelector('meta[name="csrf-token"]');
const options = {
    headers: {
        'Authorization' :  'bearer '+token.content,
    }
};
const body = {};
return Repository.post(`${resource}/${$playerId}/${$cozzaloID}`, body, options)

Preflight Header Response

 Access-Control-Allow-Headers: authorization, content-type, x-requested-with, x-csrf-token
 Access-Control-Allow-Methods: POST
 Access-Control-Allow-Origin: http://www.******.**
 Cache-Control: no-cache, private
 Connection: Keep-Alive
 Content-Length: 0
 Content-Type: text/html; charset=UTF-8
 Date: Mon, 01 Jul 2019 05:14:22 GMT
 Keep-Alive: timeout=5, max=98
 Server: Apache
 X-Powered-By: PHP/7.1.30, PleskLin

Header Response:

Access-Control-Allow-Origin: http://www.xxxxxxx.xx
Cache-Control: no-cache, private
Connection: Keep-Alive
Content-Type: application/json
Date: Mon, 01 Jul 2019 05:14:22 GMT
Keep-Alive: timeout=5, max=97
Server: Apache
Transfer-Encoding: chunked
Vary: Origin,Authorization
X-Powered-By: PHP/7.1.30, PleskLin

Header Request:

Provisional headers are shown
Accept: application/json, text/plain, */*
Authorization: Bearer jW6pFcVlkKyApCxtZIlfaHDPMSFWCWcbnPPTQ7EJ
Content-Type: application/json
Origin: http://www.xxxxxxx.xx 
Referer: http://www.xxxxxx.xx/players/739
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 
Safari/537.36
X-CSRF-TOKEN: jW6pFcVlkKyApCxtZIlfaHDPMSFWCWcbnPPTQ7EJ
X-Requested-With: XMLHttpRequest

Note about token: It should be OK because it is the same as another GET request done in the same task.

You don’t need to put Access-Control-Allow-Origin into the allowedHeaders value. — sideshowbarker, Jun 30 '19 at 22:08
Tanks. Removed both on client and server side: GET it's working and POST continue to NOT working for a bad token passed — Uncoke, Jul 01 '19 at 04:35
Have you tried `'Bearer '+token.content`? That is, uppercase, instead of `bearer`. I don’t know whether it’s case-sensitive or not… — sideshowbarker, Jul 01 '19 at 04:40
It should work with and without any capital letters. But not in my case :( — Uncoke, Jul 01 '19 at 04:48
Have you tried debugging to ensure that your `document.head.querySelector('meta[name="csrf-token"]')` is actually getting what you expect? And that `token.content` is? — sideshowbarker, Jul 01 '19 at 04:58
Yes, I agree with you but I can't figure it. I have edited my question with header request/response — Uncoke, Jul 01 '19 at 05:23
does `(domain_a)/Repository.js` above mean you are running the script from `domain_a` instead of `domain_b`? — Yohanes Gultom, Jul 01 '19 at 05:31
@YohanesGultom I have 2 (sub)domains: www.domain.com (A) and api.domain.com (B) — Uncoke, Jul 01 '19 at 05:34
@YohanesGultom Repository.js is on the forntend side (www by VUE), and config/cors.php is on backend side (api by Laravel) — Uncoke, Jul 01 '19 at 05:35
On the backend of the server you’re sending the request to, have you checked to see what token it’s actually expected? Maybe the server logs show that — *“expected token XXX but received token YYY”* or whatever. If not, maybe you can add some debugging on the server side to print out the expected token value to the logs or wherever, and you can examine that. — sideshowbarker, Jul 01 '19 at 06:01
The answers at https://stackoverflow.com/a/43845050/441757 and https://stackoverflow.com/a/36615149/441757 and https://stackoverflow.com/a/38764345/441757 suggest that you might be able to resolve this by clearing your session storage files with `rm -f {your_web_app}/storage/framework/sessions/*` or such. — sideshowbarker, Jul 01 '19 at 06:11
Try passing the CSRF token in `X-CSRF-TOKEN` header (not in `Authorization`) https://laravel.com/docs/5.8/csrf#csrf-x-csrf-token — Yohanes Gultom, Jul 01 '19 at 09:33
@sideshowbarker nope... sorry it doesn't fix it. But I got solution! It was in web router back to api router. — Uncoke, Jul 01 '19 at 11:20
@YohanesGultom, thanks for the help but it doesn't fix... I got solution restoring the web route using API route. I wrote about this in the first lines of my post... I really appreciate your help guys! TAHNKS! — Uncoke, Jul 01 '19 at 11:22

Milan Katariya · Accepted Answer · 2019-07-04T13:53:05.923

5

Please use routes/api.php for apis routing, don't use the routes/web.php for api.

If you want to use sub-domain then do required changes in following file:

app/Providers/RouteServiceProvider.php

Original:

protected function mapApiRoutes() {
    Route::prefix('api')
    ->middleware('api')
    ->namespace($this->namespace)
    ->group(base_path('routes/api.php'));
}

Updated:

protected function mapApiRoutes() {
    Route::domain('api.' .  env('APP_URL'))
    ->middleware('api')
    ->namespace($this->namespace)
    ->group(base_path('routes/api.php'));
}

edited Jul 04 '19 at 13:53

answered Jul 01 '19 at 06:19

Milan Katariya

356
1
12

Thanks for writing, Milan! I prefer to use a dedicated subdomain (api.domain.com) instead of www.domain.com/api. For this reason, I'm using the web route. Do you think this is not correct? Why? – Uncoke Jul 01 '19 at 06:42
Wow! Thanks to @Milan, I think to have fixed my issue!!! I had to change the ENV var APP_URO from APP_URL=https://api.domain.org to APP_URL=domain.org is it ok? Or it could have a bad effect? – Uncoke Jul 01 '19 at 11:18
1

In your case you must need to set APP_URL to main domain. This is the right way don't fear for that. – Milan Katariya Jul 04 '19 at 19:12
I'm getting an issue sending the recover password link, because of this I receive link having a double domain: https://api.domain.org/domain.org/password/reset/xxxx . Can you help me to fix it? Thanks!! https://stackoverflow.com/questions/57073662/laravel-wrong-domain-in-reset-password-link – Uncoke Jul 17 '19 at 11:05

score 0 · Answer 2 · answered Mar 31 '21 at 20:59

0

in the address

vendor/fruitcake/laravel-cors/src/HandleCors.php

comment this

        // Check if we're dealing with CORS and if we should handle it
         if (! $this->shouldRun($request)) {
         return $next($request);
          }

answered Mar 31 '21 at 20:59

OmidDarvishi

558
4
8

Laravel “CSRF token mismatch” for POST with laravel-cors and axios

2 Answers2

Linked