Can somebody give working example how to solve

Access to XMLHttpRequest at 'localhost:8000/index.php/api/companies/1/logo' from origin 'http://localhost:8080' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.

this error is talked so much but no working solution I can find. Maybe it is somewhere but cannot find so far in the internet trash.

Nginx server.

Not by installing chrome plugin, because other people would also need to install it. Thats not a solution.

CORS is a topic of its own. This is not a simple error, it's the fail path of a complex validation process with a great deal of importance in security.

https://devrant.com/rants/4636771/...

We had this before.

Learn the basics. Then start asking the right questions.

your server at http://localhost:8000 needs to return "http://localhost:8080" in it's Allowed-Origins header.

you could also use Allowed-Origins: *, but sometimes clients and servers have issue with that for security reasons. Better to just setup it correctly.

You can either set nginx to respond with that header to all OPTION requests (though I never used nginx, not sure if and how that's possible)

or you need to configure your actual backend server at localhost:8000 for CORS and return proper responses to OPTION requests with allowed origins containing localhost:8080 or *

@lbfalvy thats weird. It looks like it simple- it does not allow request from other domains. We add to allow all domains , or some domains and it should work. So thats why it does not look complex. But for some reason it does not work.

It looks like it should be 5 minutes of work to configure. But it causes lot of stress when it becomes endless hours.

@24th-Dragon ins't there missing server block? I think for me when I added it , the nginx server did not even start

@IntrusionCM can you give link where to learn from those basics fastest way?

@Angry-dev you need Access-Control-Allow-Origin, but you also need to explicitly allow any nonstandard headers and those deemed dangerous by the standard, and you need to allow request methods. Also I believe Http 5XX responses are represented as a network problem to cross-origin clients, and there's a number of other subtle tricks and unexpected restrictions.
And yeah, you need to support OPTIONS requests, which must receive all Access-Control-* response headers and should receive all response headers, however the action itself (in case of a POST endpoint) must not be executed.

@Angry-dev https://developer.mozilla.org/en-US...

@lbfalvy I now do not care about security, first thing I care that at least it would work. Later after it works, security can be improved, maybe that is not even difficult thing - change * to domain.

But need to somehow make it work. And finnaly things moved a little bit. When sending file upload post request it works, but when sending non file upload, it returns allow origin header twice and fails

@Angry-dev Just getting it to work still requires a fair bit of understanding. I actually like to use ACAO: * in production APIs too, where Authorization is a JWT that the API server can validate with minimal computing power. I'm planning a DDOS protection system specifically on the Origin header to make using the API as convenient as possible while still effectively avoiding in-browser DDOS.

@Angry-dev XSRF can be avoided simply by not relying on browser identity services like Cookies. The only remaining risk then becomes DDOS, and perhaps the possibility of executing requests with an already stolen token from unsuspecting clients, but it's ultimately more flexible to verify Origin on the server than it is to get the browser to do it.

Duplicate headers
The CORS Middleware should be the only place you add these headers. If you also add headers in .htaccess, nginx or your index.php file, you will get duplicate headers and unexpected results.

https://github.com/fruitcake/...

looks like it should not be nginx config. Thats why I was getting those duplicate headers.

So without nginx headers it works, except post request for file uplaod. weird.

Finnally solved the cors problem, not in a secure way but at least it works. Here is the nginx config:

https://pastebin.com/ZY5D29r2

So in nginx some headers are commented, laravel handles them.

And upload probably was not working becuase I had die() code in the function and so it did not send headers.

Thats insanity, probalby spent more than a day for cors.

again. Testing fresh installation of same project which worked and again getting cors errors. All the time cors. How could it work then and not work when I just clone in different folder?

and fixed not knowing how. WHen runing same request in browser instead from vue app, it gave log permission error. Gave permissions to the laravel storage folder, and also cleared cache again - it started working. wtf.

and again cors does not work for single entpoint out of nowhere. wtf. Just done styling adjustments and cors stopped working. Probalby doing something else made it stop workking . bUt it is so crap taht its stops working so easily. I do not touch laravel cors config - it should not stop workign but it does. What a bullshit.

bullshit happens- I added to index.php

die('ble');

and when calls that endpoint it does not print this text!!!! WTF

And it aggain started to work when nothing related to cors change. Did they add random generator to decide when it should go to index.php and when not?

And I noticed it does not work when I upload file with big size. wtf.
btw this video beggining clearly shows that I am not alone having such problem: https://youtube.com/watch/...

idiots nginx creators - really probably there was default max size 1 MB. And it does not give any error, it just gives no response. And no cors header !!!! After increased nginx file max size, this problem has gone, because simply frontend validates also file size and user will never be able to reach that limit.
Again wasted so much time for such stupid thing.