React+Laravel 5.8.33 +Axios: errors when registering user with an axios.post request; clarififying the code problem

Preflight requests are an HTTP-OPTIONS request made by a client to the server to verify that it supports CORS protocol.

https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

The way to go is to register a route in your server that returns a response with necessary access control policy headers. For example:

Route::options('/{path}', function() {  return response('', 200)      ->header(        'Access-Control-Allow-Headers',         'Origin, Content-Type, Content-Range, Content-Disposition, Content-Description, X-Auth-Token, X-Requested-With')      ->header('Access-Control-Allow-Methods', 'POST, GET, PUT, OPTIONS, DELETE')      ->header('Access-Control-Allow-Origin','*')      ->header('Access-Control-Allow-Credentials',' true');})->where('path', '.*');

This is similar to the middleware approach in your question except that the middleware is attached to routes but provides no fallback for options request to those routes.

I will post here how I figured out what was happening with my Laravel-React-Axios simple-yet registration app. From the above posts that tried to tackle with the problem only some comments by ClueMediator were helpful on how to understand the issue behind the scenes and some informative-useful comments by Quentin on my post. I have to note here, that as far as I have seen, all the other posts and github discussion about axios and laravel and .js front-end didn't focus on this at all(or if they did, they did it without putting any serious attention to it).

First of all, one can see in my first post that changing the post request from localhost:8000 to just the name of the api/route seemed to have as an effect the removal of some of the cors; since I was running the project at one or two servers at a time, the cors could come back as a function of where artisan was serving the app.

Second of all, an internal 500 error was showing up even is the cases where the cors had been reduced; that was due to mistakes in the tutorial I was learning from and had to do with incomplete construction of the migrations.

To the point. It seems that axios is always trying to send, together with the request I was having in my code(a post request in this example) an options request. What I did to check out the problem was to change my host and port as artisan was serving and together my code to match the route correctly. Then, checking the network tab at console, I saw that although the post request was send fine, I still had cors because the axios.options request was going by default to the localhost:8000, but I wasn't serving my app from there. Specifying artisan to serve from there, and correcting the migrations construction, solved the problem.

It is important to underline something here: artisan serves at localhost:8000 the first time you open him/ but opening a second server, it goes on the next available port as normally would. Where not for the mistakes in the migrations code, I would have probably caught the problem originated from artisan and where it was serving. But, 'cause of a malfunctioning relation with my database, even then, I was getting a 500 error as internal server error, which had me opening another server, and then discovering that axios always sends an options request only to localhost:8000, even if my front-end and back end agreed on one another, having many changes to the code produced inconsistencies. So, in conclusion, after dealing with bad code(something I should have seen faster than I did), it was only a matter of correctly setting the axios and artisan to agreement.

Any observations on how the above logic could improve would be great.

Thanks to all.

have you tried using the csrf token as a post parameter? if not what you can do is, set the csrf token and token in post parameters of your axios request. It will solve your issue.