Axios CORS/Preflight failing with Laravel 5.4 API call

Question

I'm having an issue with Laravel 5.4 and my React application which uses Axios to handle requests.

Here is the error I'm getting.

Here are my request headers for the preflight response which is failing.

Here is the failed request after the preflight:

Here is my Axios request configuration:

let req = axios({
    method: "GET",
    url: https://api.vendorgraphs.com/{queryStringHere}
    headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
        'Authorization': 'Bearer ' + accessToken
    }
});

One interesting thing to note is that it is specifying the endpoint using the HTTPS protocol. Similar requests on my application are working as they should be but this is the only one that is failing. Is it because of the use of a query string?

The request is hitting an API endpoint as a GET request. I'm using Laravel and the laravel-cors package to handle my cors requests.

Here is my configuration for CORS:

This is in my Kernel.php

protected $middleware = [
    \Barryvdh\Cors\HandleCors::class,
    \Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
    \Illuminate\Foundation\Http\Middleware\ValidatePostSize::class,
    \App\Http\Middleware\TrimStrings::class,
    \Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
];

and my cors.php in the config folder

return [
    'supportsCredentials' => false,
    'allowedOrigins' => ['*'],
    'allowedHeaders' => ['*'],
    'allowedMethods' => ["GET", "OPTIONS", "POST", "PUT", "PATCH", "DELETE"],
    'exposedHeaders' => [],
    'maxAge' => 0,
];

I can obviously see that the preflight is failing in the network tab. What I don't understand though is why I'm getting a Mixed Content error instead of a 405 or some other HTTP status code. Seems strange that its saying I'm requesting an endpoint using the HTTP protocol when I'm explicitly setting the url using HTTPS.

I've been stuck on this for some time now and could use some insight on the issue. It seems like a lot of people have had "similar" issues with OPTIONS preflights. I've done things like creating a middleware that just returns a 200 HTTP status code if the method for the request is OPTIONS. But that didn't work either. Changing the request to OPTIONS for Axios and changing the route on Laravel to something like:

Route::options("/api/endpoint", controller@method);

did not work either. I just don't understand why it's redirecting to HTTP protocols and returning mixed content errors when it seems like that has nothing to do with CORS but the preflight request is failing which is indicative of it being a CORS issue. Any and all insight is appreciated.

<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews
    </IfModule>

    RewriteEngine On

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)/$ /$1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    RewriteCond %{HTTPS} !=on
    RewriteCond %{HTTP:X-Forwarded-Proto} ^http$
    RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

Answer 1

The cause of the problem you’re seeing is, that server itself redirects the https URL to http:

$ curl -I 'https://api.vendorgraphs.com/api/dealershipvendorleads/?id=3,4&startDate=2017-4&endDate=2017-8'

HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=iso-8859-1
Date: Wed, 20 Sep 2017 15:33:50 GMT
Location: http://api.vendorgraphs.com/api/dealershipvendorleads?id=3,4&startDate=2017-4&endDate=2017-8
Server: Apache
Connection: keep-alive

Notice the 301 status code, and the Location header with http://api.vendorgraphs.com/…

So what that means is, you can’t make a cross-origin request to that API endpoint from a secure context (https page) without browsers blocking it as mixed content (as you’re seeing).

So this isn’t really a CORS issue — instead it’s purely a mixed-content problem.