I've created a tiny droplet as a staging system for my project. It's Laravel 9 + inertiajs all using vite.
I've encountered this weird issue where I get the following CORS errors:
test-123:1 Access to script at 'http://[::1]:5173/#vite/client' from origin 'http://xxx' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
test-123:18 GET http://[::1]:5173/#vite/client net::ERR_FAILED
test-123:1 Access to script at 'http://[::1]:5173/resources/js/app.js' from origin 'http://xxx' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
test-123:18 GET http://[::1]:5173/resources/js/app.js net::ERR_FAILED
test-123:1 Access to script at 'http://[::1]:5173/resources/js/Pages/GoalNotAvailable.vue' from origin 'http://xxx' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
test-123:18 GET http://[::1]:5173/resources/js/Pages/GoalNotAvailable.vue net::ERR_FAILED
Locally for development, I am using Laravel sail however here I just installed it directly on the server.
I have default CORS settings in Laravel seeing as this is testing. I also tried to do reverse proxy thinking that this might help but of course, it did not.
Does anyone have any idea what I need to do to essentially run a dev version of my app on droplet?
I understand why I am getting CORS issues but I can't see why if that makes sense as the settings seem to be correct.
Related
I am working on a project in Laravel 8 which I am now testing the deployment on production servers. I have set up 2 Digital Ocean Droplets that are behind a load balancer with Sticky Sessions enabled. I am attempting to login via a SPA app with a separate Laravel API so the middleware is configured for the api routes to be stateful API and perform CSRF validation. This works perfectly fine when I just hit a single droplet and bypass the load balancer but as soon as the load balancer is in use, I always receive a 419 CSRF Token mismatch.
Everything I found on Google says that the session needs to be shared between servers, but I don't believe this is the case in this scenario. I have turned on sticky session with a cookie called DO-LB in the load balancer so all requests from the same session go to the same server, and I am tailing the Apache access log on both servers, and I can see all requests such as the get-csrf and the auth route (using Sanctum) both hit the same server so would I would still be getting a token mismatch.
I am also using the cookie session driver.
UPDATE
I've found something a little strange, if I point my DNS to a singled droplet I see the X-XSRF-TOKEN is sent as a request header, but if I change DNS to point to the load balancer then X-xSRF-TOKEN is not sent as a request header. I am using Axios to send the request but I can't see how a load balancer can affect Axios
UPDATE 2
It looks like when I run it locally XSRF-TOKEN is not an HttpOnly cookie but when running it on production the XSRF-TOKEN is flagged as HttpOnly which from what I've read means its inaccessible from Javascript hence why Axios isn't sending it. I seem to have confirmed this by doing Cookies.get("XSRF-TOKEN") and printing the result, locally it prints the token to the console, but in production its undefined.
UPDATE 3
I updated my Apache configuration to override the headers as a test to remove the HttpOnly flag which seems to have done the trick, and I can now see when I log in, Chrome sends an X-XSRF-TOKEN in the request even though I still get a CSRF Token Mismatch.
I've compared the string in the chrome cookie store with what is being sent in the X-XSRF-TOKEN and they both match so I don't understand why Laravel keeps returning me a mismatch and I am at a complete loss.
I think I've figured this out, if it can be migrated to server fault then please do but I thought as figured out it makes to say what it was instead of just deleting.
I was using cloudflare and made the error of using self signed certificate between DO droplet and cloudflare and gave this cert to the load balancer. Although no errors were thrown by DO, in the Apache log I noticed that although the web site load, when an API request was made I noticed the apache error log Server name not provided via TLS extension (using default/first virtual host). Not sure if this is the actual cause but made me think if the issue was caused by the self signed certificate.
I generated a new origin server from Cloudflare which means it has a trusted CA and then gave that to DO load balancer and the problem went away.
I am working locally on a project where my Laravel backend is running by Laravel Valet on the url https://backend.app and my frontend is a Vue project running on http://localhost:8080.
When I do the call from my frontend to my backend to generate the CSRF token I get a 200 response but I get a warning next to the Set-Cookie header that says:
This Set-Cookie was blocked because it has the "SameSite=Lax"
attribute but came from a cross-site response which was not the
response to a top-level navigation.
I can imagine that it can't work when my backend runs on backend.app and my frontend runs on localhost. Any tips or ideas how to get this to work on my local environment?
does this API just not work via cross origin resource? My CORS headers are set in .htaccess and verified working, because I do get a response from the API, but it's an unknown error.
I set everything up and tested on a single test server and it all works. But my prod environment requires two separate domains, one which is a CMS where the pages are hosted, and then a separate PHP server where I'm hosting the PHP side of the app that makes the CURL requests. When I try to make a CORS request, I get
{"error":{"code":500000,"message":"An unexpected error occurred. If the error persists, report it with date/time of error, request identifier from response header X-RequestId, and client identifier from request header X-ClientTraceId."}}
I get the same thing when I mimic a CORS scenario locally by using a XAMPP PHP server and a Gulp HTTP server.
My setup currently builds the JSON from body copy on a page, then sends that via AJAX POST to the PHP file, which then processes it, encodes, makes Curl requests to the API, then outputs the response. I then handle the data from the response again in the JS file.
I created API with PHP and am testing it now.
It goes success with chrome and firefox, but safari gets error, "NSPOSIXErrorDomain:100."
This error sometime happens and sometime I can get a correct response from API.
Does anyone know anything about this kind of error?
I still don't understand even which part is causing this error...Is this because of server, AWS, SSL, PHP, or client browser?
Here is some info of my API.
allowing https access only (ex https://xxxdomain/xxx?id=000)
using php (Lumen)
deployed on AWS
receiving GET request with some params
I had the same problem calling PHP APIs deployed behind an AWS Load Balancer (I don't know if Load Balancer is present in your settings). I have solved the issue by disabling the use of HTTP 2.0 in the load balancer. In order to disable HTTP 2.0, select your Load Balancer in the AWS console then select Action -> Edit Attributes and disable HTTP/2
If you're not using a Load Balancer you have to check your webserver settings in order to figure out which HTTP version is enabled.
I fixed this problem by inserting the following as the very first line of the .htaccess file:
Header unset Upgrade
I am working on a web project, I just started using a JavaScript based video player in Wordpress. The video player works fine when using videos on the same server but when requesting videos from other servers it throws the error in browser console:
Failed to load http://techslides.com/demos/sample-videos/small.mp4: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.gozo.kitchen' is therefore not allowed access
I am trying to access the video on a different server.
I have tried locating the server configuration file but I cannot find it here's a summary of what I have done till now :
Server is running the linux operating system. I can find the nginx.config but its empty and enabling it to use CORS does not seem to solve the problem. The video still does not run.
There is no config file under the etc directory.
I need to enable CORS to access videos on other servers.
You're requesting a resource from another server so the other server must allow you to retrieve it with an Access-Control-Allow-Origin header that matches your site details. You can disable this when you start chrome with the --disable-web-security flag but that should only be used for testing.