I have an existing web application hosted in Tomcat which is listening for a HTTP POST.
However for security reasons requests to the web application have to be transported across the network as HTTPS.
I cannot change the web application.
So I want to receive a HTTPS POST, decrypt it and pass it on to the web application as a HTTP POST.
I also need to pass back to the sender response codes etc.
I have been told that I can do this using Apache configured as a "reverse proxy".
But I am not an expert at Apache or Tomcat and before I investigate this option I wanted to be sure I was going down the right path.
i.e.
Schematic
So to the Remote Server application everything looks like it happens over HTTPS.
And to my local Tomcat web application everything looks like it happens over HTTP.
Is this doable and correct ?
Do I need to use Apache or could I do it all in Tomcat ?
Is this what is called "url rewriting" ?
This is more than just "redirection" ?
Thanks,
Brett
Related
I want to create a blog website like blogger.com
I use ASP.NET Core 5 and visual studio 2019.
When I use kestrel everything is fine and this url test.localhost5001 is work correctly, but I want to use IIS and now this url test.localhost44324 doesn't work and I get error 400 (Bad Request - Invalid Hostname ). How can I work with dynamic subdomains in IIS express ?
I repeat I want to work with dynamic subdomains not limited number subdomains.
The reason it isn't working is because IIS Express doesn't accept connections to a host with a header other than localhost, as per the comments.
There is a way to do what you want, you can use our free VS Extension called Conveyor which proxies connections to IIS Express. That will mean that you can send requests to the Conveyor port and IIS Express will think that the request is to localhost.
For most users that is enough, but you want to send traffic to subdomains, to do that you can send traffic to the Conveyor Remote URL port, eg.
https://subdomain.localhost:45455
https://subdomain2.localhost:45455
When your code runs, you will see that the request's Location header is just "localhost", which is not that useful for you, but look at the Forwarded header and you will see "subdomain.localhost" in there, and from that you can do what you need.
I'm having an issue with a project I'm working on. I have a Vue client which does API calls to my backend which is written in .NET Core 3.1. Both these applications are deployed on diffent servers.
Now the problem is that my backend server does not allow me to do API calls straight from the browser. So I have to do some kind of 'redirect' on the client server to reach my API.
So for example:
If I call backend_server/api/values I get an error (Firewall).
I think I should make like a second API or something, but I'm not sure how to handle this issue.
Does anybody have any experience on this? Any help is welcome!
Kind regards
You can have multiple options here
Remove the firewall rule -
This will allow your API to get hit from browser. If firewall is not managed by you you can't do this
Add IP or Port exception rule in firewall -
Instead of deactivating the entire inbound rule on server, you can allow specific ports or IP on firewall. Again if you have control on firewall
Create Proxy API -
Another way is you can create a middleware API that forwards your request and acts as a proxy. This will suffice performance, resource, time and compromise security. I recommend not to do this, But it's easily possible in .NET Core
Specify CORS policy -
If your Vue.js and API originates from same origin (IP), You can configure CORS in server which will restrict access to API only from same origin. That means only www.google.com can access GoogleAPI, Likewise. This will protect the API from other origins
Tunnel via VPN -
If security is a concern, Use a VPN service to tunnel your API requests. This can't be possible for every client using your web service.
The best way is to open a specific rule on server for your application if possible. Writing a proxy in between will have lot of disadvantages although can be accomplished.
I have an application that sends a request to a web service. Unfortunately the application is compiled and the link to the web service is embedded in the application as http. (Yes I know how dumb that is, I didn't write it)
Recently, the 3rd party company is no longer allowing http requests, everything must be https.
The application runs as a webapp on Tomcat. The server is a windows server.
Is there a way to intercept the call to this web service and force it to use https?
As you can't change the application's source code (as it is compiled), and you can't change the web service (as it is 3rd party) either, the only way to solve this problem is making a proxy between the application and web service. To do that, you need to (assume the proxy is running in localhost):
As the web service URL is embedded into the compiled application, in order to let application send HTTP request to our proxy, hosts mapping need to change (e.g. /etc/hosts) to override DNS. For example, if the HTTP request in application is GET http://example.com/api/sample, in /etc/hosts, example.com need to be mapped to 127.0.0.1.
Make a proxy web server in localhost and open the same port as the web service. This proxy is a very simple web server (any backend programming tech can do it), it is only responsible for request-forwarding. In this way, when application send HTTP request to example.com, it sends the request to the proxy server.
After receiving HTTP request from application, the proxy server extract the request URL/header/body and send HTTPS request to example.com's real IP address. Please note: in this HTTPS request, a header host whose value is example.com should be added. 3rd party web service may check this header.
After the real response is returned from example.com, proxy will return it to the application.
Of course, you can also use reverse engineering (Java Decompiler) to get the application's "source code", change the web service URL and then compile again to a webapp. However, as the application may need to update/upgrade and it is may not under your control, this reverse engineering method is not recommended.
You could use a proxy script. Write it in any server-side language you want, for example PHP, set the API URL to this script, the script does the https request for you and pass the results back to your app.
You could also use Apache itself as the proxy and use something like: Apache config: how to proxypass http requests to https
I'm just starting to develop a SPA, with java(dropwizard) REST backend. I'm kinda new to 'web' development, but I did internal web apps before, so security was not a big concern before.
Right now I'm using nginx as my public facing web server, and I just discovered whole slew of complications that arise as we're splitting actual servers: static web server serving my SPA's files, and java microservices behind it.
I'm used to apache talking to tomcat with mod_jk, but now I had to implement CORS in dev because my SPA is deployed on a lite-server serving at different port than the REST Api served by dropwizard.
Now I got to my minimum viable product and wanted to deploy it on prod,
but I have no idea how do I do it.
Do I still need the CORS header? Dropwizard will be run separately on a different port only available to local processes, then I configure nginx to route incoming request from, e.g. /api/ to that port. Does that counts as cross-origin?
I'd like to serve full https. Dropwizard can serve to https, but I don't want to update SSL cert on multiple microservices. I read about nginx ssl termination, will this enable me to use plain http in local and https on nginx?
Any other caveats to watch out on deploying with this architecture?
Thank you!
Yes, you can certainly do it!
You can terminate https with nginx, and still have the backend operate on either plain http or even https still. The proxy_pass directive does support both access schemes for the upstream content. You can also use the newer TCP stream proxying, if necessary.
There are not that many caveats, really. It usually just works.
The question is as simple as the title. I have a webapp (I have no clue as to what technology it was built on or what appserver it is running on). However, I do know that this webapp is being served by an Apache Server/ IIS Server / IBM Http Server. Now, I would like to have a plugin/ module / add-on at the web-server end, which would parse/truncate/cut/regex the http response (based on the requested url's pattern), and mask(encrypt/shuffle/substitute) a set of fields in this response based on different parameters(user's LDAP permissions in the intranet / user's geo-location if on the internet, etc) and send the altered response back to the user.
So, Is there an easy answer to creating such plugins/modules/add-ons? How feasible is this approach of creating extra software at the webserver, when you want to mask sensitive information in a webapp without modfying the web-app code? Are there any tools that help you do this for Apache?
And, finally, is this just a really crazy thing to try?!
Each webserver will have its own way of doing so.
There is no universal plugin architecture for webservers.
In IIS you would write an HTTP Handler or HTTP Module, or possibly an ISAPI Filter. You can also directly interact with the http response using the Response object exposed by the HttpContext.
With apache, there are different modules that can do what you want (mod_headers, for example).
I don't know anything about WebSphere, but I am certain it also has similar mechanisms.
What you are asking is required by most web applications, so would be either built in or very easy to do.
The easiest way is to add a plug-in using the web application container. For example, if it's Tomcat, you can add a filter or valve.
If you want to plug-in to the web server, you'd need to write a custom module using the API of whichever web server is being used.
If all else fails, you could always wrap the entire server in a reverse proxy. All requests would go through your proxy and that would give you the opportunity to modify the requests and the responses.