No 'Access-Control-Allow-Origin' header is present on the requested resource

[fruitcake]

No 'Access-Control-Allow-Origin' header is present on the requested resource

[davidnknight]

Just a word of advice @jeroennoten and to anyone else who might be seeing the XMLHttpRequest cannot load http://api.example.com/whatever. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://whatever.com' is therefore not allowed access.

When you're making cross origin requests and there's a fatal error on the receiving end, you will see the above error, which naturally leads you to think that there's an issue with the CORS headers, because that's what the console error refers to after all. However, whilst the browser console is correct in reporting that the headers are missing, it's not because this package is at fault, or you haven't setup your headers properly, it's actually because if there's a fatal error, the CORS headers never actually get output because the exception is thrown before the application reaches a point of returning those headers and therefore the request isn't allowed and you see no result, not even information about the true underlying error because as said, the CORS headers are missing because an internal 500 error has been thrown.

If you were working on a single subdomain application (i.e. www.example.com), where all requests were being made from and to www., you would be seeing the usual Laravel exception thrown message and stack trace at this point but you can't see that when it's cross domain because it's missing the headers to allow the request and therefore return the response/error.

Hopefully the above made some sense, and the bottom line of the story is to check your PHP error log when you see this in your browser console as it's likely nothing to do with your CORS package, headers or setup but actually an underlying fatal error. It caught me out a few times, hoping this will save some headaches/time for others, reduce confusion and furthermore reduce the number of issues/comments about this for @barryvdh. =)

[JaviLopezM]

I only put this line at the top of routes files

header('Access-Control-Allow-Origin: *');

and works.

[karunkshrestha]

I am using the new style config

<?php

return array(

    /*
     |--------------------------------------------------------------------------
     | Laravel CORS Defaults
     |--------------------------------------------------------------------------
     |
     | The defaults are the default values applied to all the paths that match,
     | unless overridden in a specific URL configuration.
     | If you want them to apply to everything, you must define a path with ^/.
     |
     | allow_origin and allow_headers can be set to * to accept any value,
     | the allowed methods however have to be explicitly listed.
     |
     */
    'defaults' => array(
        'supportsCredentials' => false,
        'allowedOrigins' => array('*'),
        'allowedHeaders' => array('authorization','x-requested-with','apiKey'),
        'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
        'exposedHeaders' => array(),
        'maxAge' => 0,
        'hosts' => array(),
    ),

    'paths' => array(
        'v1/*' => array(
            'allowedOrigins' => array('*'),
            'allowedHeaders' => array('authorization','x-requested-with','apiKey'),
            'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
            'maxAge' => 3600,
            //'hosts' => array('*')
        ),

    ),

);

The 403 forbidden error only appears in chrome, in firefox it is fine.

[shanecp]

If you're using this package in Chrome + localhost, it won't work. This is a bug/feature in Chrome - http://stackoverflow.com/questions/10883211/deadly-cors-when-http-localhost-is-the-origin

[dees040]

I upgraded from Laravel 5.4 to 5.5. In Postman all requests where working. But in my VueJS application all requests where failing with the error of this issue. But in Laravel 5.4 everything was working perfectly. I'm not sure if my issue had to do with L5.5 or that I might did something wrong with the upgrade, but moving the HandleCors from the api middleware group to the global middleware group fixed the issue.

[kennonb]

Not sure if I should leave this comment here or in another thread, but something I ran into... I noticed that CORS wasn't working unless I added "http(s)://" to the domain definition "allowedOrigins" in the config.

So, "https://admin.domain.com" instead of "admin.domain.com".

I just wanted to make sure that I wasn't missing something. If this is true, then I can submit a pull request to update the documentation a little bit to note that, if you'd like?

Thanks for the awesome package. :)

[barryvdh]

Well, the readme does say that, on the 'known problems' part..

[barryvdh]

Try upgrading the config to the new style, soms things might have changed.

[barryvdh]

Maybe set the headers also to *? Not really sure what is wrong.

[karunkshrestha]

I set exposed headers to * , still the same errors

<?php

return array(

    /*
     |--------------------------------------------------------------------------
     | Laravel CORS Defaults
     |--------------------------------------------------------------------------
     |
     | The defaults are the default values applied to all the paths that match,
     | unless overridden in a specific URL configuration.
     | If you want them to apply to everything, you must define a path with ^/.
     |
     | allow_origin and allow_headers can be set to * to accept any value,
     | the allowed methods however have to be explicitly listed.
     |
     */
    'defaults' => array(
        'supportsCredentials' => false,
        'allowedOrigins' => array('*'),
        'allowedHeaders' => array('authorization','x-requested-with','apiKey'),
        'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
        'exposedHeaders' => array('*'),
        'maxAge' => 0,
        'hosts' => array(),
    ),

    'paths' => array(
        'v1/*' => array(
            'allowedOrigins' => array('*'),
            'allowedHeaders' => array('authorization','x-requested-with','apiKey'),
            'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
            'exposedHeaders' => array('*'),
            'maxAge' => 3600,
            //'hosts' => array('*')
        ),
    ),

);

[karunkshrestha]

I am going to revert back to the previous version. I don't know if it is chrome's stricter CORS requirement or my laravel setup. Let me know if you stumble upon a solution.

[barryvdh]

Okay, can you post your old (working) config here?
Op 6 jun. 2014 17:03 schreef "karunkshrestha" [email protected]:

I am going to revert back to the previous version. I don't know if it is
chrome's stricter CORS requirement or my laravel setup. Let me know if you
stumble upon a solution.

—
Reply to this email directly or view it on GitHub
#15 (comment)
.

[karunkshrestha]

I reverted back to version 0.1.2 , and used the default config

return array(

 /*
  |--------------------------------------------------------------------------
  | Laravel CORS Defaults
  |--------------------------------------------------------------------------
  |
  | The defaults are the default values applied to all the paths that match,
  | unless overriden in a specific URL configuration.
  | If you want them to apply to everything, you must define a path with ^/.
  |
  | allow_origin and allow_headers can be set to * to accept any value,
  | the allowed methods however have to be explicitly listed.
  |
  */
  'defaults' =>  array(
      'allow_credentials' => false,
      'allow_origin'=> array(),
      'allow_headers'=> array(),
      'allow_methods'=> array(),
      'expose_headers'=> array(),
      'max_age' => 0
  ),

  'paths' => array(
      '^/api/' => array(
          'allow_origin'=> array('*'),
          'allow_headers'=> array('authorization','x-requested-with','apiKey'),
          'allow_methods'=> array('POST', 'PUT', 'GET', 'DELETE'),
          'max_age' => 3600
      )
  ),

);

[barryvdh]

So the path has changed from api/ to v1/?
You can try just setting the config in thedefaults and leaving the paths array empty, so that it always matches. Or try using the old matching scheme (^/api/)

[karunkshrestha]

sorry, the path is still '^/v1/'

return array(


    'defaults' => array(
        'allow_credentials' => false,
        'allow_origin' => array(),
        'allow_headers' => array(),
        'allow_methods' => array(),
        'expose_headers' => array(),
        'max_age' => 0,
    ),

    'paths' => array(
        '^/v1/' => array(
            'allow_origin' => array('*'),
            'allow_headers' => array('authorization','x-requested-with','apiKey'),
            'allow_methods' => array('POST', 'PUT', 'GET', 'DELETE'),
            'max_age' => 3600,
        ),
    ),

);

[lgt]

I have the same issue laravel 4.1 controller under /api/products

return array(

/*
 |--------------------------------------------------------------------------
 | Laravel CORS Defaults
 |--------------------------------------------------------------------------
 |
 | The defaults are the default values applied to all the paths that match,
 | unless overridden in a specific URL configuration.
 | If you want them to apply to everything, you must define a path with ^/.
 |
 | allow_origin and allow_headers can be set to * to accept any value,
 | the allowed methods however have to be explicitly listed.
 |
 */
'defaults' => array(
    'supportsCredentials' => false,
    'allowedOrigins' => array(),
    'allowedHeaders' => array(),
    'allowedMethods' => array(),
    'exposedHeaders' => array(),
    'maxAge' => 0,
    'hosts' => array(),
),

'paths' => array(
    'api/products/*' => array(
        'allowedOrigins' => array('*'),
        'allowedHeaders' => array('Content-Type'),
        'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
        'maxAge' => 3600,
    )
),

);

headers response 403

[barryvdh]

And does only

'defaults' => array(
    'supportsCredentials' => false,
    'allowedOrigins' => array('*'),
    'allowedHeaders' => array('*'),
    'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
    'maxAge' => 3600,
    'exposedHeaders' => array(),
    'hosts' => array(),
),

work?

or

'defaults' => array(
    'supportsCredentials' => false,
    'allowedOrigins' => array(),
    'allowedHeaders' => array(),
    'allowedMethods' => array(),
    'exposedHeaders' => array(),
    'maxAge' => 0,
    'hosts' => array(),
),

'paths' => array(
    'api*' => array(
        'allowedOrigins' => array('*'),
        'allowedHeaders' => array('*'),
        'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
        'maxAge' => 3600,
    )
),

[lgt]

firebug on 2nd example shows:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://lenovo-verkauf.de/api/products. This can be fixed by moving the resource to the same domain or enabling CORS.

[barryvdh]

What is the request you are making? I'll try to recreate it.

[barryvdh]

Can you see if the request actually reaches the index.php file? Or these all OPTIONS requests? Does the server accept OPTIONS requests?

[lgt]

let me put some var_dumps()

[lgt]

this are the headera on http://lenovo-verkauf.de/api/products request

Access-Control-Allow-Head... origin, content-type
Access-Control-Allow-Meth... PUT, GET, POST, DELETE, OPTIONS
Access-Control-Allow-Orig... *, http://localhost:8000, *
Cache-Control no-cache
Connection Keep-Alive
Content-Type application/json
Date Fri, 27 Jun 2014 05:13:52 GMT
Keep-Alive timeout=5, max=100
Server Apache/2.2.22 (Debian)
Set-Cookie laravel_session=eyJpdiI6Im9FTHdSaVlZakVrQVVSV2Jrc0pBbUdCWTlwUlVidjg0aklJZWYyMjNTUGc9IiwidmFsdWUiOiJTeXl5RmZkbFhSeW43QmthMmw5Z0lETTNXUW96aFdXY2FKV0hTWWNtb3NWNXUzZnN0S2FrTVhKOWQ0NTZNR3FwWHR1QXlKem1DK3VGSnpldmY2bXBmdz09IiwibWFjIjoiMDljYjRhYzMyODg5NmVjMzAyZWFmYTgzZjgyNTEyZDg4NWY0ZmQwNjYwY2U2ZjgyNDcxZTBiNjk4YTJiZDBkMCJ9; expires=Fri, 27-Jun-2014 07:13:52 GMT; path=/; httponly
Transfer-Encoding chunked
Vary Origin
X-Frame-Options SAMEORIGIN
X-Powered-By PHP/5.4.4-14+deb7u11

than I put a var_dump in my pulic index.php

if($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
var_dump($_SERVER['REQUEST_METHOD']);
} else{
var_dump('NO OPTIONS');
}

I got NO OPTIONS
so it seems like my apache won't accept options

[barryvdh]

Okay, I get this error here (http://jsfiddle.net/f4D2j/):
The 'Access-Control-Allow-Origin' header contains multiple values '*, http://fiddle.jshell.net', but only one is allowed. Origin 'http://fiddle.jshell.net' is therefore not allowed access.

Are you modifying the headers with htaccess or other filters?

[lgt]

Okay thanks is working now I have been placing some filters and those made some problems

[davidnknight]

I have the same issue. Installed per the instructions on the readme of the repo and using the following config.

<?php

return array(

    /*
     |--------------------------------------------------------------------------
     | Laravel CORS Defaults
     |--------------------------------------------------------------------------
     |
     | The defaults are the default values applied to all the paths that match,
     | unless overridden in a specific URL configuration.
     | If you want them to apply to everything, you must define a path with ^/.
     |
     | allow_origin and allow_headers can be set to * to accept any value,
     | the allowed methods however have to be explicitly listed.
     |
     */
    'defaults' => array(
        'supportsCredentials' => false,
        'allowedOrigins' => array(),
        'allowedHeaders' => array(),
        'allowedMethods' => array(),
        'exposedHeaders' => array(),
        'maxAge' => 0,
        'hosts' => array()
    ),

    'paths' => array(
        '*' => array(
            'allowedOrigins' => array('*'),
            'allowedHeaders' => array('Content-Type', 'X-Requested-With'),
            'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
            'maxAge' => 3600,
            'hosts' => array('api.*')
        ),
    ),

);

The error in Chrome console is:
XMLHttpRequest cannot load http://api.something.dev/2014-08-31/2/inventory.json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.something.dev' is therefore not allowed access.

Not using any filters.

[barryvdh]

Can you try with setting the defaults instead of the path, and allow all headers?

'defaults' => array(
    'supportsCredentials' => false,
    'allowedOrigins' => array('*'),
    'allowedHeaders' => array('*'),
    'allowedMethods' => array('*'),
    'maxAge' => 3600,
    'hosts' => array()
),
'paths' => array(),

Does that work?
If it does, can you try at what step it goes wrong (when moving to paths, specifying the methods/headers etc)
If it doesn't, could you debug and see if the middleware is called, the CORS detected etc.

[davidnknight]

Hi Barry,

That did work, after which I started adding in the paths config one line at a time and then set my defaults config back to what they were to begin with, removing wildcards etc.

Anyway, I can't explain why but it now seems to be working with exactly the same code as I originally posted above, that didn't work yesterday, bizarre!

I'll report back if there are further related issues. Thanks for your response!

By the way, the comments/references within the config file are out of date, referencing 'allow_origin' and 'allow_headers' which are now 'allowedOrigins' and 'allowedHeaders', also stating that the allowed methods however have to be explicitly listed but that seems to no longer be the case.

[barryvdh]

You are right, that's fixed in master, but not yet tagged. I've pushed a new tag with the new default config/comments.

[TimothyLoyer]

Thanks barryvdh, I was just searching for a solution to the same issue. Great package! :)

[kristophbarbour]

I get the same issue, however if I put header('Access-Control-Allow-Origin: https://my.domain.here'); above my Route like so:

header('Access-Control-Allow-Origin: https://my.domain.here');
Route::get('usage', array('as'=>'usage','uses'=>'UsageController@getUsage'));

It will work for the first call but not all subsequent calls. My website has a dropdown box that when a date range is selected (3 hour, 12 hours, 1 week, 1 month) my ajax requests post to my other server to get the json data for the graph range selected. When the page loads it automatically requests the 1 week data range, it works and so does every other data range other then the 3 hour range. The weird this is there is no difference in what happens, just the start time value changes (unix time stamp). This is the error that shows when I select 3 hours:

XMLHttpRequest cannot load https://sub.domain.here/usage?ip=192.168.1.35&start=1409180282. The 'Access-Control-Allow-Origin' header contains multiple values 'https://ums.unifone.net.nz, https://my.domain.here', but only one is allowed. Origin 'https://my.domain.here' is therefore not allowed access.

If I remove the header('Access-Control-Allow-Origin: https://my.domain.here'); the 3 hour range works but none of the others.

Here is my config:

    'defaults' => array(
        'supportsCredentials' => false,
        'allowedOrigins' => array('*'),
        'allowedHeaders' => array('*'),
        'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE','OPTIONS'),
        'exposedHeaders' => array(),
        'maxAge' => 3600,
        'hosts' => array(),
    ),

    'paths' => array(
        '*' => array(
            'allowedOrigins' => array('*'),
            'allowedHeaders' => array('*'),
            'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE','OPTIONS'),
            'maxAge' => 3600,
            'hosts' => array('*'),
        ),
    ),

[gregorskii]

Hi there,

I am having issues as well. I am unable to AJAX from my front end API to the backend when it is deployed to my staging server. It does work on my local machine.

I have tried using a very basic config such:

'defaults' => array(
        'supportsCredentials' => false,
        'allowedOrigins' => array('http://staging.canvis.tv'),
        'allowedHeaders' => array('Accept', 'Content-Type', 'X-Auth-Token', 'X-Requested-With'),
        'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE', 'OPTIONS'),
        'exposedHeaders' => array(),
        'maxAge' => 3600,
        'hosts' => array(),
    ),

    'paths' => array()

The API is at http://service.staging.canvis.tv.

I am using this AJAX call:

if (/staging/.test(window.location.href)) {
        serviceBaseURL = '//service.staging.canvis.tv';
}

$('.register').click(function() {
        $.ajax({
            method: 'POST',
            url: serviceBaseURL + '/auth/register',
            data: {
                '_token': FB.getAuthResponse().accessToken || null
            },
            headers: {
                'X-Requested-With': 'XMLHttpRequest'
            }
        }).success(function(result) {
            console.log(result);
        }).error(function(result) {
            console.log(result);
        });
    });

What is the correct way to have environment based configurations. I have tried a single config under /app/config/packages/barryvdh/laravel-cors/config.php and separate configs under each environment key "/app/config/packages/barryvdh/laravel-cors/stage/config.php".

When I try adding a error_log call on the index.php the OPTIONS calls never make it to the index on staging, but do on local:

if ($_SERVER['REQUEST_METHOD'] == "OPTIONS") {
    error_log('OPTIONS');
} else {
    error_log('NOT OPTIONS');
}

Thanks for any help you could provide.

[jeroennoten]

@gregorskii I have the same problem: my front-end app calls the api (on a subdomain), which works locally but not on the remote server.

When it makes an OPTIONS request, the error is: XMLHttpRequest cannot load http://api.example.com/sessions. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://frontend.example.com' is therefore not allowed access. (replaced my domain with example.com).

Applying this config does not help:

    'defaults' => array(
        'supportsCredentials' => false,
        'allowedOrigins' => array('*'),
        'allowedHeaders' => array('*'),
        'allowedMethods' => array('*'),
        'maxAge' => 3600,
        'hosts' => array()
    ),
    'paths' => array(),

Do you already have a solution?

Thanks.

[jeroennoten]

@davidnknight You're completely right, the problem was some configuration issue in DNS for the api subdomain. Thank you for the explanation!

[gregorskii]

I did notice that it would fail with the same error regardless of whether it was an error with the package or CORS.

The issue I am having is that one my local dev box CORS is working great, pushing to stage on DigitalOcean reports this error, with the same code base/build.

It is possible there is an error with the staging configuration. But I have tried creating environment based package configs and using the single config set up for staging.

This is more of a general question, but when making environment based configs for packages do you create sub folders within the config/packages/NAMESPACE/ folder, or do they go directly in config.

Example:

app/config/packages/barryvdh/laravel-cors/stage

versus

app/config/stage/cors.php

Thanks

[barryvdh]

The first example should work.
The errors are supposed to also have the headers added, but it could be that the middleware ignores those responses. I'll have to check, but be sure to check your logs and make your config as least restrictive as possible. For testing you could also just force the headers manually on all (or some) requests.

[karunkshrestha]

Hi,
The problem has resurfaced again. This is on a fresh installation of Laravel 4.2.9 with laravel-cors 0.2.3 installed. The OPTIONS call gets aborted (canceled) for some reason.

I can use Postman to perform an OPTIONS call to the service and get back the desired access control headers.

The following is the laravel-cors config I am using.

<?php

return array(

    'defaults' => array(
        'supportsCredentials' => false,
        'allowedOrigins' => array(),
        'allowedHeaders' => array(),
        'allowedMethods' => array(),
        'exposedHeaders' => array(),
        'maxAge' => 0,
        'hosts' => array(),
    ),

    'paths' => array(
        'rpc' => array(
            'allowedOrigins' => array('*'),
            'allowedHeaders' => array('authorization','x-requested-with','apiKey','content-type'),
            'allowedMethods' => array('POST', 'PUT', 'GET', 'DELETE'),
            'maxAge' => 3600,
        ),
    ),

);

The server is running IIS 7.5 and has URL rewrite. This was imported from the htaccess file included in the laravel installation.

[barryvdh]

And no errors in the logs?

Seeing this problem with 0.2.3, have tried downgrading to 0.2.1 and 0.2.2 and still see the issue. No errors in the log, using the default config you provided previously.

Works on one domain, but not on another, both using the same config.

array( 'supportsCredentials' => false, 'allowedOrigins' => array('*'), 'allowedHeaders' => array('*'), 'allowedMethods' => array('POST', 'GET'), 'maxAge' => 3600, 'exposedHeaders' => array(), 'hosts' => array(), ), ``` );

[johnrcui]

I'm having the same issue. I have a dev environment that's working well but when i clone or even just copy directly to another directory and use a different server name (ie. dev.domain.com and api.domain.com), only the dev environment works. Both installs are running on the same amazon linux machine with nginx web server and my config files for each is identical except for the root directory and server name.

After trying out whatever I can figure out and reading other people's comments here, I had a hunch it might have something to do with the domain name. So I changed my clone environment's server name to the same as the dev's and just changed the port number to distinguish it from each other and lo and behold everything now works on the clone.

I'm not sure if it's something cached on the browser (I didn't try clearing cache during the failures) or maybe related to cookies or maybe the middleware is storing something globally that's tied to the first installation's server name that's overriding the settings on the second installation, but putting the two environments under the same server name worked.

[rohan-deshpande]

Hi guys, I was getting this error constantly as well, then I disabled the CSRF middleware and it worked. The error I kept getting was a token mismatch exception, keep in mind that I was using the csrf-token meta tag with the $.ajaxSetup solution and all ajax calls were working fine before I went API based and split my app up into two domains. Not sure if this is the cause of everyone else's issues but it was definitely the cause of mine.

FYI I'm developing locally with homestead.

[FoxxMD]

👍 This error only occurs for me when a client is making pre-flight requests. The response header for the OPTIONS request does not include access-control-allow-origin. Making requests without pre-flight works fine. Using the default config.

[eporral1]

Hi @barryvdh this is the issue I'm experiencing:

if my routes have an internal error, I receive:

XMLHttpRequest cannot load http://localhost:8000/signin. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8001' is therefore not allowed access. The response had HTTP status code 500.

For instance: If I turn off my MySql DB, I receive that error, instead of "invalid connection to db" or something like that, when trying to login.

I'm using version "0.4.x@dev" and my settings are:

'defaults' => array(
'supportsCredentials' => false,
'allowedOrigins' => array(''),// default ()
'allowedHeaders' => array(''),// default ()
'allowedMethods' => array(''),// default ()
'exposedHeaders' => array(''),// default ()
'maxAge' => 0,
'hosts' => array(),
),

Any Idea?
thanks!

[behzadsh]

I didn't read comments, but I had exact problem, and fix it by running composer update and then running
php artisan vendor:publish --provider="Barryvdh\Cors\ServiceProvider"

[djoks]

I had the same issue and you know what was even stranger? It just happened like that all of a sudden, still have no idea what caused it and the even weirder thing was that it worked on some devices and didn't work on other devices, so i installed cors, but that didn't do anything, so i removed it and just addd the necessary code to my .htaccess file now it works just fine. :)

[mtpultz]

@eporral1 did you ever get this resolved? I'm having the same issue for this config:

'supportsCredentials' => false,
'allowedOrigins' => ['*'],
'allowedHeaders' => ['*'],
'allowedMethods' => ['*'],
'exposedHeaders' => [],
'maxAge' => 3600,
'hosts' => [],

On top of that I'm getting this in my log file:

[2016-02-24 07:57:53] local.ERROR: Symfony\Component\Debug\Exception\FatalThrowableError: Type error: Argument 1 passed to Barryvdh\Cors\Stack\CorsService::addActualRequestHeaders() must be an instance of Symfony\Component\HttpFoundation\Response, array given, called in /home/vagrant/app/vendor/barryvdh/laravel-cors/src/HandleCors.php on line 44 in /home/vagrant/app/vendor/barryvdh/laravel-cors/src/Stack/CorsService.php:69
Stack trace:
#0 /home/vagrant/app/vendor/barryvdh/laravel-cors/src/HandleCors.php(44): Barryvdh\Cors\Stack\CorsService->addActualRequestHeaders(Array, Object(Illuminate\Http\Request))
#1 [internal function]: Barryvdh\Cors\HandleCors->handle(Object(Illuminate\Http\Request), Object(Closure))
#2 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(124): call_user_func_array(Array, Array)
#3 [internal function]: Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#4 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(32): call_user_func(Object(Closure), Object(Illuminate\Http\Request))
#5 [internal function]: Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#6 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(102): call_user_func(Object(Closure), Object(Illuminate\Http\Request))
#7 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(726): Illuminate\Pipeline\Pipeline->then(Object(Closure))
#8 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(699): Illuminate\Routing\Router->runRouteWithinStack(Object(Illuminate\Routing\Route), Object(Illuminate\Http\Request))
#9 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Routing/Router.php(675): Illuminate\Routing\Router->dispatchToRoute(Object(Illuminate\Http\Request))
#10 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(246): Illuminate\Routing\Router->dispatch(Object(Illuminate\Http\Request))
#11 [internal function]: Illuminate\Foundation\Http\Kernel->Illuminate\Foundation\Http\{closure}(Object(Illuminate\Http\Request))
#12 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(52): call_user_func(Object(Closure), Object(Illuminate\Http\Request))
#13 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/CheckForMaintenanceMode.php(44): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#14 [internal function]: Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode->handle(Object(Illuminate\Http\Request), Object(Closure))
#15 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(124): call_user_func_array(Array, Array)
#16 [internal function]: Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#17 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php(32): call_user_func(Object(Closure), Object(Illuminate\Http\Request))
#18 [internal function]: Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#19 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(102): call_user_func(Object(Closure), Object(Illuminate\Http\Request))
#20 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(132): Illuminate\Pipeline\Pipeline->then(Object(Closure))
#21 /home/vagrant/app/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(99): Illuminate\Foundation\Http\Kernel->sendRequestThroughRouter(Object(Illuminate\Http\Request))
#22 /home/vagrant/app/public/index.php(53): Illuminate\Foundation\Http\Kernel->handle(Object(Illuminate\Http\Request))
#23 {main}  

[rochapablo]

+1

[ganpat-tekhne]

@barryvdh I am using laravel 5.3 with cors it was working good for me up till now but now i tried creating some more apis and those are not working and are giving cors error
should not it be the case tht if the cors works for one should work for all if its set globally in the kernal file?

[tangrianand]

Hi Guys,

I am facing similar error. I am using Amazon AWS and route 53. I changed my domain name from 'api.temphawk.com' to 'api.temphawk.com/core' and now every api works fine except one 'api.temphawk.com/core/alert/history'.
It gives the following error in chrome.

And this error in mozilla.

Could anyone please help. This api works fine when I open it on Postman though.

[sharadjaiswal1411]

Check this Tutorial for Laravel
http://www.laravelinterviewquestions.com/2017/12/cross-origin-request-blocked-error-laravel.html

[gregorskii]

Can this ticket be closed out? :) Been open a LOOONNGGG time.

This library works, it just needs to be configured correctly, and the user has to understand that any error in the backend will stop the middleware from responding with a CORS token, which will cause the browser to indicate that there is an error with CORS, when there is actually not.

There are two things that can be done to mitigate this:

• Documentation
• Returning a CORS token even on 500 errors from the API, which the user could technically do in a error middleware, or as a PR to this package

😸