I'm keeping the backend API as a separate project from the frontend HTML5 app consuming it. I'm using Yeoman for the frontend development. Yeoman runs on localhost:3501 and the backend on localhost:3000. When I make the API request from the browser (using AngularJS's $http), I hit the same origin policy:
XMLHttpRequest cannot load http://localhost:3000/venues. Origin http://localhost:3501 is not allowed by Access-Control-Allow-Origin.
AFAIK, same origin policy should kick in only when making request across different domains. Why is it whining when we do a request from localhost to localhost (albeit to different port)?
How can I make this work and will this cause problems in production?
The ports also count for cross domain requests, therefore http://localhost:3000 and http://localhost:3501 are 2 different domains (from browser's point of view).
If you need both applications (client and backend) to run on different ports, consider using http://enable-cors.org/
According to W3C, "An origin is defined by the scheme, host, and port of a URL", so the different port is causing your problems.
Two possible solutions:
CORS (Cross Origin Resource Sharing)
Using JSONP requests
Both would require changes to your backend (I'm not familiar enough wo. CORS would probably mean the least changes to your frontend (I think AngularJS supports it out-of-the-box).
Related
I have a project which I have dockerised here: https://github.com/redis-projects/redis-movies/tree/gitpod
I am in the process of trying to get it to work correctly on GitPod, however I am having issues with the frontend react app hitting the backend java service. The react app is running in my local browser so I am confused by which network settings I should use and how to correctly configure.
The docker-compose file when used locally can simply use localhost:8080 to interact with the backend services, but GitPod generates a unique domain over HTTPS. Currently this causes the issues:
Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint '<URL>'. This request has been blocked; the content must be served over HTTPS.
This is self-explanatory, I cant make HTTP requests when the site is loaded via HTTPS. & even if I could, its pointing # localhost so the service wont resolve.
How can I setup my docker-compose + gitpod configuration to correctly configure the React URL
Currently use env vars:
REACT_APP_MOVIE_SERVICE_HOST=localhost
REACT_APP_MOVIE_SERVICE_PORT=8080
and this simply builds a url like so (apiConfig.js): http://${process.env.REACT_APP_MOVIE_SERVICE_HOST}:${process.env.REACT_APP_MOVIE_SERVICE_PORT}
Assuming that the backend services are exposed via a public endpoint, I will need to handle any CORs issues since these services are no longer 'local'?
I need to understand how exactly works the bot-detection works on axs.com as I'm accessing many times this website and after a short while the login does not work any more and website is basically blocked.
By analyzing the network request and console I can see the following after clicking the login button:
Access to XMLHttpRequest at 'https://api.axs.com/proxy/v3/flash/migrate/authenticate?access_token=4f2be33d835e7197e245c54ff00e5fb4®ion=1&locale=en-US' from origin 'https://www.axs.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
WHAT I HAVE TRIED SO FAR:
Using multiple VPNs to change IP address (Failed)
Using an EC2 instance (failed)
Using Extension called "Trace" to completely delete all my trackable data and delete cookies (Failed)
Incognito window (Failed)
Proxy Server Paid and Free (Failed)
What else can I try?
I finally found the solution, it was needed only a better quality proxy. My steps:
At the beginning we used rotating proxy with brightdata from many different countries, but no luck with it.
Then we tried different proxy providers but always rotating, residential and mobile were tested. Again no luck.
We purchased US proxy from https://www.proxyrack.com/ and finally it worked. I guess the proxy quality is of vital importance. AXS security must have a pretty long blacklist for IP addresses.
I have two cloud services up and running.
frontend (URL: https://frontend-abc-ez.a.run.app/)
backend (URL: http://backend-abc-ez.a.run.app/)
Frontend is calling the backend through a nuxt.js server middleware proxy to dodge the CORS problematics.
The call is coming through - I can see that in the backend log files. However the response is not really coming back through because of CORS. I see this error in the console:
Mixed Content: The page at 'https://frontend-abc-ez.a.run.app/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://backend-abc-ez.a.run.app/login'. This request has been blocked; the content must be served over HTTPS.
What I find weird is that I configured the backend url with https but it is enforced as http - at least that is what the error is telling me. Also I see a /login path segment in the unsecure URL. Why is that? I never explicitly defined that endpoint. Is it the security layer proxy of the run service itself?
Anyway - I need to get through this properly and am having a hard time to understand the source of the problem.
For some reason as I rechecked the applications today in the morning everything went fine. I have really no idea why it is working now. I did not change a thing - I waited for the answers here before I'd continue.
Very weird. But the solution so far seems to be waiting. Maybe Cloud Run had some troubles.
Problem: Safari is doing a request with the pushed path but to the site host, resulting in 404s.
Scenario: Cross origin asset that is server pushed. Asset's host and site's host are different domains.
Browser: Safari v12+ (also v13) in both MacOS and iOS.
It is worth noting that the server push feature it self works, but Safari makes this extra request to the host. Also this doesn't happen on Safary v10 or v11.
I ran into this too, and confirmed (by re-writing with Charles Proxy) that Safari does load resources in a link header from the cross-origin domain if the link header uses an absolute path that includes a domain.
This type of HTTP response will not work in Safari:
HTTP/2 200
content-type: application/javascript; charset=utf-8
... other headers
link: </script.js>; rel=preload; as=script; crossorigin
Instead, you need to include the full domain and protocol, like so:
HTTP/2 200
content-type: application/javascript; charset=utf-8
... other headers
link: <https://www.example.com/script.js>; rel=preload; as=script; crossorigin
This is different from most server push tutorials which have a path that's absolute from the root of the domain (e.g. /script.js), but I've confirmed that it works correctly in Safari even when the server-push response is for a JavaScript resource on a different domain than the one that the HTML page lives on.
Scenario: Cross origin asset that is server pushed. Asset's host and site's host are different domains.
You cannot push a resource for another domain except in for very limited circumstances. The server has to be authorative for this server. Basically that means it goes to same IP address and is covered by same certificate. So if you are on www.example.com and have a separate sharded domain on static.example.com on the same server you can in theory push from that. However browser support is really poor for this and I really wouldn't recommend it. You can use the preload resource hint for that instead which is much better understood and supported.
Problem: Safari is doing a request with the pushed path but to the site host
As per above link, Safari does not support cross domain pushing. And neither do lots of other browsers.
resulting in 404s.
That would make sense since the resource you are requesting to push does not exist on that domain
It is worth noting that the server push feature it self works, but Safari makes this extra request to the host.
Then why do you think it is working?
Also this doesn't happen on Safary v10 or v11.
What doesn’t happen? The push? The double download? Both?
Using Angular-CLI as a frontend. 4200 port
Using Express as a backend. 8080 port
Directories look like:
Application
- backend
- ...Express architecture
- frontend
-...Angular2 architecture
So I'm running two projects, two commanders, one for frontent, second one for backend. node app.js for backend (8080), ng serve for frontent (4200).
Let's assume that I have a layer in backend which returns some string.
app.get('/hello', function(req, res) {
res.send("Hello!");
}
How can I make a request from frontend to backend and get that string? I don't want to know how exactly should I use Angular2 because that's not the point. I'm asking, what technology should I use to be able connect these two (frontent and backend) sides on different ports. If I just run them and make a request from frontend, I'll get an error because it can't find /hello url.
Your request to /hello means an absolute path inside the application running the angular application, so the request goes to http://localhost:4200/hello. Your angular application just doesn't know about the express application you want to target.
absolute urls
If you want to access the hello route on the other (express) application, you need to explicitly specify this by referencing http://localhost:8080/hello.
cors
Doing it this way, the correct application is targeted, but you will likely run into CORS issues, because the browser will prevent the javascript code obtained from localhost:4200 to access a server at localhost:8080. This is a security feature of your browser. So if you want to allow the code at 4200 to access the backend at 8080 your backend can whitelist this so called origin. For details see http://enable-cors.org/ and a corresponding express middleware you could use to support cors in your backend (https://www.npmjs.com/package/cors).
Using this approach has two downsides in my opinion. First, you need a way to tell your frontend under which absolute url it can reach the backend. This must be configurable because you need different urls for dev, staging and production. You then also need a way to manage all your whitelisted urls because the frontend in production will have a different url than when running the frontend in development. This can get pretty cumbersome to handle.
proxying your backend
A better approach in my opinion is to handle this in your infrastructure by proxying the backend in your frontend application. With proxying you basically tell your frontend server that all requests to some url should be passed through to another application. In your case this could probably mean, that for example you configure a proxy for the path /api/ to proxy the application on localhost:8080. The server then doesn't try to find a url like /api/hello on your frontend application but forwards your request to localhost:8080/hello. In your angular application you then don't need to care about the url of your backend and you can then always do a request to a url like /api/some-express-route.
For this to work you need to configure your angular dev server to proxy the requests. For details on how to do this, please see the docs at https://angular.io/guide/build#proxying-to-a-backend-server. When going to production, you can do this by configuring your web server, e.g. nginx to proxy the requests.