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.
Related
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.
I'm using Axis2-1.6.2 in a highly modified Tomcat6 environment hosting a web service and need to log every incoming Axis2 web service request.
This is for a production environment and I want all requests (SOAP messages) to be logged into a log file.
For valid requests (valid request structure conform with the WSDL), this works fine, because I can log the request body after it has been parsed by Axis2. The problem is with malformed requests, which are declined by Axis2 and don't come through to my code.
I've tried a lot so far to log these wrong requests as well, but none of the proposed (easy) solutions worked. I basically just want to set a logback appender (SLF4J) or add some -Dparameter to the Java process to motivate Axis2 to log every incoming message into a file and couldn't believe that apparently there is no easy way to do that.
I can't really use some proxy like Fiddler to do the logging either (environment restrictions).
<handler type="java:org.apache.axis.handlers.LogHandler"/> didn't work either, because it's not Axis1.
The Dparameter described here didn't do anything either.
It seems to me that the only solution is to write a custom handler, which does the logging. However, this seems to be too much effort and customization for an established technology and an obvious use case. I do have guides how to do that like axis2 Log Response with Request and Java Example - Loghandler.java.
Isn't there an easier (more native) way?
For valid requests (valid request structure conform with the WSDL),
this works fine, because I can log the request body after it has been
parsed by Axis2. The problem is with malformed requests, which are
declined by Axis2 and don't come through to my code.
This is because, after the request is dispatched to service, it will fail because it is not following the service definition..
AFAIK, only solution is, keep a custom handler before dispatching phase, to capture and log the requests. Whatever the logging mechanism will work after passing axis2 layer..But in your case, it will fail before that..So, try to keep a simple handler to log messages..
We are trying to figure out if we can copy each http request coming in to our tomcat production server and send it to a development test server to get a real simulation of the production traffic.
The original request handling should not have any impact. The production server need not wait for a response for the copied request from the development server.
Is there a simple way to do this?
If you really want to do it live, what I'd recommend is to put a Http Servlet Filter in front of your production webapp. In this filter, copy the request data into a new request and send it (asynchronously) to your development server. This way, at least you don't have to modify your application code.
But it think you should try to avoid doing that in a production environment. Instead, you could dump the request data (see Istvan answer) and do the request from a development machine.
Not that I know of. Maybe you can setup http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Request_Dumper_Filter in a way that it sends the logs to a remote server that has some small app playing back the requests based on what's received.
"sends the logs" = configure log4j so that it stores the log on a network share or use socketappender