Cross-Origin Request Blocked

[wontone18]

Hi

I tried all the way but its blocking. I am using a laravel 7.2 version. And my front end is react. I tested this with fetch and axios but it is not working.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost/smarttalkonlineedu/webapps/api/public/api/loginin. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

[wontone18]

My error now is CORS multiple origin not allowd.

[wontone18]

thanks its fix for my side. if any body facing the issue then use header pattern. This resolve my issue

<?php

return [

    /*
    |--------------------------------------------------------------------------
    | Cross-Origin Resource Sharing (CORS) Configuration
    |--------------------------------------------------------------------------
    |
    | Here you may configure your settings for cross-origin resource sharing
    | or "CORS". This determines what cross-origin operations may execute
    | in web browsers. You are free to adjust these settings as needed.
    |
    | To learn more: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
    |
    */

    'paths' => ['api/*'],

    'allowed_methods' => ['GET, POST, PUT, PATCH, DELETE, OPTIONS'],

    'allowed_origins' => ['*'],

    'allowed_origins_patterns' => [],

    'allowed_headers' => ['Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range'],

    'exposed_headers' => [],

    'max_age' => 0,

    'supports_credentials' => false,

];

[barryvdh]

Did wildcard for allowed_headers not work?

[wontone18]

no barry it was not working with "wildcard for allowed_headers".

'allowed_headers' => ['Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range'],

After adding those line it is now working from your package.

[barryvdh]

Which browser were you using?

[wontone18]

Which browser were you using?

i had tested this in firefox and chrome both.

[wontone18]

one more thing i will also share here for people. Request and Response should always be in json.For instance if its like somebody sending a json value to back end but in return response is without json then browser will also block the url.

we must ensure about this request and response should be in json.

[thalesbarbosab]

Hello guys.

I was have a same issue when i deploy to production. Just solve for me when i run that comand:

php artisan config:clear

Good luck.

[iBotPeaches]

I'm confused how I've been breaking this for years, but it appears the spec has caught with browsers in the enforcement. Probably happened around when Chrome started enforcing cookie lax/none.

It appears if you run credentials (whether cookie) or a Authorization header. You can no longer use the wildcard for allowed_headers.

I found this in the spec.

For Access-Control-Expose-Headers, Access-Control-Allow-Methods, and Access-Control-Allow-Headers response headers the value * counts as a wildcard for requests without credentials.

https://fetch.spec.whatwg.org/#http-access-control-expose-headers

---

Or if you prefer MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers

The value "" only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name "" without special semantics.

So my config dropped all wildcards.

---

    'supports_credentials' => true,
    'allowed_headers' => [
        'Accept',
        'Authorization',
        'Content-Type',
        'Cookie',
        'DNT',
        'Origin',
        'User-Agent',
        'X-Requested-With',
    ],
    'exposed_headers' => [
        'Accept',
        'Authorization',
        'Origin',
        'Content-Type',
        'X-Requested-With',
    ],

---

Now everything I've tested is now working again. Hope that helps someone. I might try and push some doc updates when I grab a moment. Hope that helps someone for now.

[barryvdh]

Hmm but we should transform the headers to just return the requested value: https://github.com/asm89/stack-cors/blob/88aaf08c68a66647309b7535f55591dc785b29ed/src/CorsService.php#L178-L187 Will see if I can reproduce

[barryvdh]

Are you using 2.0.1 of stack-cors?

[iBotPeaches]

Hmm but we should transform the headers to just return the requested value: https://github.com/asm89/stack-cors/blob/88aaf08c68a66647309b7535f55591dc785b29ed/src/CorsService.php#L178-L187 Will see if I can reproduce

I see, so the array with asterik gets to stack-cors package, which is normalized to true. Stack-cors then detects that true value and pulls the header value from the request - Access-Control-Request-Headers back into the response. If you don't use asterik/true, it just implodes into comma delimited.

So my preflight on app is

Access-Control-Request-Headers: content-type

stack-cors detects my config as asterik, changes to true, copies that and returns it. Which is now invalid because it dropped Authorization (edit, prev Origin)`

Hardcode the array since credentials and I get back in response

Access-Control-Allow-Headers: accept, authorization, content-type, cookie, dnt, origin, user-agent, x-requested-with

No issue.

[iBotPeaches]

Are you using 2.0.1 of stack-cors?

        "name": "asm89/stack-cors",
        "version": "v2.0.1",

        "name": "fruitcake/laravel-cors",
        "version": "v2.0.1",

[barryvdh]

But it doesn't drop Authorization, that header is not requested by your Access-Control-Request-Headers?

[iBotPeaches]

But it doesn't drop Authorization, that header is not requested by your Access-Control-Request-Headers?

Correct, I'm not a true master at the understanding yet of all this CORS stuff. I wasn't aware till now that the asterisk is just converted behind scenes to whatever the request passed.

I am a bit confused though, if stack-cors just pulls Access-Control-Request-Headers if an asterisk is used. Am I expected to use that header in client side side code for all my allowed headers knowing that it needs to be expanded server side and returned?

Some of my legacy bad code is as ugly as

    $.ajax({
        type: 'POST',
        url: url
        data: JSON.stringify({}),
        headers: {
            'Accept': 'application/json',
            'Content-Type': 'application/json'
        },
        xhrFields: {withCredentials: true},
        success: function (response) {
          //
        },
    });

So I never set any headers outside of those.

[barryvdh]

I would expect that the browser would take care of the Request-Headers values, you wouldn't have to do that manually.

[iBotPeaches]

I would expect that the browser would take care of the Request-Headers values, you wouldn't have to do that manually.

I'll do some low level nginx logging to get everything to see if I can't get a better understanding around this and loop back. For now, my manual setting has resolved the issues that started cropping up for isolated users/environments.

[lvxianchao]

'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range'

it dosen't work for me.

[KieronWiltshire]

I'm pretty sure this is down to the failing check of the asterisk wildcard.

[ALuciferDK]

cors 2.0 The second request is intercepted when the Axios request is passed,It could be cross domain,And now it's impossible to make a cross domain request anyway,It has been modified in the above way, but it still doesn't work,this is my Chrome error

[ALuciferDK]

I found the reason, because I added a custom header remember token. I want to ask how to add this into the allowed scope of the header

[ALuciferDK]

Yes, because the configuration is too confusing, and then it's OK to just use CORS

[trainoasis]

For me, the issue was a changed path: was serving API directly from '/' without '/api' so I needed to change paths in cors.php:

'paths' => ['/*', 'sanctum/csrf-cookie'],

[oluudeh]

I am having the same issue on Laravel 8.

[wixys]

In my case, I'm using a multi-tenancy system, this package required some special settings in the RouteServiceProvider and actually I'm using a routes/tenant.php file to manage routes api, so I've changed in the config/cors.php this value: from: 'paths' => ['api/'] to
'paths' => ['/']

Working fine!

[vangelis183]

As long a wildcard is being used in paths, it doesn't work and returns CORS Errors.

[gniuslab]

Do not use this format in your routes https://www.domain.com/api/login/ The last slash returns CORS, remove it and it will work.

To make it clearer, don't use '/' last in the path, it just won't work for you, so check before ...

[blu-towers]

Same issue as @gniuslab

The default '/' route with a header of Content-Type: application/json caused CORS errors but only when I sent Content-Type.

If i change the route to '/search' it works.

[sergiogithub]

Yes, same as @gniuslab

The last '/' is generating CORS error.

Thanks man.

[mhnaufal]

In my case, I'm using a multi-tenancy system, this package required some special settings in the RouteServiceProvider and actually I'm using a routes/tenant.php file to manage routes api, so I've changed in the config/cors.php this value: from: 'paths' => ['api/'] to 'paths' => ['/']

Working fine!

yes, it's working on me