I have an app which needs to query an API which blocks cross-origin requests. Right now, my approach is to query my own API, which then queries the 3rd party API, and then relay the results to frontend. So basically I have set-up proxy endpoints.
This results in extra load on my server which I want to avoid. Is there a way I could do this directly from my frontend code and not have proxy endpoints in backend?
For example, say the following endpoint:
https://fantasy.premierleague.com/drf/bootstrap-dynamic
If you go directly hit the browser with it, it runs fine. But when I use say Angular 2 http to fetch response from it, it is blocked.
Is there a way I could do this directly from my frontend code and not have proxy endpoints in backend?
No. That is the point of CORS being disabled. If you cannot control the server to either disable CORS or allow it for the origin server where your app is running, then you must use a proxy, either by setting up a proxy when serving vi node or by configuring apache/nginx accordingly.
Related
I have 2 services - Ingress (input node) and Storage.
Client send requests on Ingress to get some data (large files).
Ingress send request to Storage to get data that Client needs.
Maybe, somebody can tell what I can use to restream response from Storage to Client without OutOfMemory issues.
Now I've implemented it as saving result in file on Ingress, rereading it and sending as response to Client. But it works really slow, of course.
Thank you.
Spring Cloud Gateway (more documentation here) can help. It's primary purpose seems to be as a configuration-driven gateway, but it can be embedded into an application to serve just certain endpoints; so you may be able to configure it in your "Ingress" service to route certain requests to your Storage service.
If that doesn't work (or, as was in my case, it's too much work), you can use some specific classes from Spring Cloud Gateway in your own service. Specifically, I've used the ProxyExchange class to proxy calls to another service and stream the results back to the original caller.
I am working on a web application, which is deployed to weblogic cluster. Upon user invoking an action in jsp, at the server side we make an outbouond call (with 2-way ssl) to an external service. This service returns me some data, which we send to the client side for rendering on UI. This flow is working as fine.
Outbound request for 2-way SSL are made from a utility class within the application, using java.net.URLConnection. However, upon checking the access.log for weblogic, I don't see these outbounds call logs in the access logs.
Now, business has Access log monitoring software in place, to monitor specific urls/reponse code and alert IT team if the number of non-200 responses crosses some threshold.
So, the challenge I am having currently is, how to log the outbound request's url & response status to the access log of weblogic server. I have been googling over the net, but couldn't find anything so far which can suggest how to go about it. I am new to weblogic, so not sure if this is possible OOTB or I need to write some custom code for this.
Need advice from weblogic experts out there. Thanks in advance!
Weblogic only traces incoming http/s requests in its access logs. Your application is responsible for logging its own outbound requests in its own logs. Do not log your entries in weblogic's logs.
The scenario is this: I'm developing a Java EE application with an Angular 2 frontend. The client has an Apache server which is usually used to serve static resources and an Oracle Weblogic for the dynamic part. The problem is that by default the Angular 2 App and the Weblogic server will not be able to talk each other due to the Same Origin Policy.
So far I have 3 possible deployment approaches in mind:
Set up a Reverse Proxy in Apache to point the REST endpoints to Weblogic
Package the Angular App in a WAR/EAR and deploy it to Weblogic. So I would end up with something like: myserver/myapp for the UI and myserver/myapp-rest for the Backend.
Package the Angular App in the same WAR as the Java backend. So I would end up with myserver/myapp for the UI and myserver/myapp/api for the REST endpoints.
There is a 4th option which would be setting up CORS, but I'm worried about the security using that approach.
Which is the right approach?
If you are allowed to make infra decisions , change apache webserver to nginx , we switched to nginx and got lot of added values in terms of concurrent processing.
In our project the angular client is served by nginx webserver which talks to java backend hosted on tomcat 8.x(our app server) , also there are couple of tiers after app-server a separate DB server and an elastic search server.
Don't feel intimidated to set up CORS, you will eventually need to allow some origins requests which don't originate on your domain and port.
If your java tech stack has spring mvc , then setting up CORS is just a matter of adding few lines of configuration. You can even hardcode your angular url to allow backend server to serve requests only from your angular URL.
In normal JavaEE world, CORS is just another filter or interceptor where you can set response headers with all the allowed origins, http methods etc. It's very simple you can look it up.
For your given choices
seems plausible and a value addition that you get is you can
delegate SSL encryption to proxy server .
seems rather odd, you would want to separate the static content server from dynamic contents server, your angular js bundles, assets
etc are mostly static, if you keep your static server separate then
you can configure cookie-less domains down the line that would make
serving a lot faster.
3 same as 2.
I would strongly suggest the CORS option , from my past experiences.
I have separate application for client side which is in ReactJs and NodeJS (Express server) and Web Services in Java application running in tomcat.
My query is which is better approach in terms of making web service call.
One is making direct web service call from ReactJS and get the data.
Other one is calling web service in Express server. Request from client browser will go to Express and Express will make all web services call.
I know one issue in making direct call to web service will be cross domain policy which can be handle by setting configuration in Java server.
Apart from it what should be better approach.
From my experience it ended up better using direct calls from UI application and avoiding intermediate server.
Reason for doing this directly is that our servers ended up with a lot of restrictions based on IP addresses, and all requests have been coming from intermediate server (nodeJS server), so DDOS protection of end server had to have some exceptions (our node server which could be on ACS with dynamic IP addresses so it might be hard to manage).
Also If you want to pass and track end users IP addresses, you need to manage headers on Node server (to be sure you are passing it as it was in original request).
It is way simpler to manage this kind of situation if calls are comming from React app and simply set up CORS on java server.
Also its way easier to debug it on UI app directly, so you will be watching response logs on one place only. Other way around you could end up debugging your node server and UI app.
Hope this helps a bit.
Best way IMO is to create a router in Node js specifically for all your Java webservices and act as a proxy.
Suppose if your url pattern is like http://domain/java-ws/api then all these requests will be routed to your Java service.
If you have an Apache server directing requests to your node JS then configure url pattern proxy using proxy module.
Browsers are blocking CORS requests for a reason. You may get away by setting things on your server.
Is it possible to prevent requests that are not using https from calling a get/post in code.
For example I am implementing a rest api with java and spring, and I would like to return a http status to the caller if they were not using https.
/api/getBlah using https would return the item, however using just http would not work and return the appropriate http status.
For an API server, I strongly encourage you to don't answer a redirect
If you do answer a redirect, if a developer make the mistake to use the http version of your API he will not see immediately that he used an insecure connexion
If you answer a "400 Bad Request", "401 Unauthorized" or a "405 Method Not Allowed" with a body explaining that only https is allowed, then the developer will immediately see the problem.
In short, answering a redirect http=>https in an API encourage bad practices.
There are a few different ways of handling this. Web Server Handling in my opinion, is the most common and makes the best use of the strengths of web servers and application serves.
Web Server Handling
As mentioned in the comments above, a common method of deploying Java web applications is to place a web server (such as apache or nginx) in front of a Java Application Server (tomcat, wildfly, jetty, etc.). The web server then proxies requests to the application server.
In a setup like this you can simply return a static response or redirect the user.. In this way, you don't need to return anything special from your own Java application. The web server does the lifting for you.
It should be noted (as in the answer from #Tom), that in the API use-case, an HTTP to HTTPS redirect is not best approach. This is more commonly
Application Server Separate Servlets
On the Java side, you could essentially create two separate web applications. The first would be configured to receive requests from the HTTP listener and would provide proper error messages or redirects. The other would be your main application and would be configured to only receive requests from the HTTPS listener.
Again responding with a static error would be best for an API.
Application Server Single Application
When a servlet handles requests, it will populate information in the ServletRequest, including information about if the requests was secure (used HTTPS). See the [ServletRequest documentation][2] and specifically the isSecure() method. You can inspect the ServletReuest within your application to determine the appropriate way of responding to the request.
Don't Answer
You can also simply configure your webserver/app server to not listen for HTTP requests. You'll miss the change to provide a sensible error to the user, but you'll achieve the affect of not allowing any requests over HTTP.