There are many sites (such as microleaves.com) that allow you to change your external IP address by connecting to a master proxy. You connect to a master proxy and the master proxy routes your IP to an external proxy. The external IP can change at any time (for example, if one of the external proxies stop working it is automatically replaced by a different proxy by the master proxy/IP).
I'm using this type of service to navigate to different websites via the Selenium framework - is it possible to prevent a request from executing if the external proxy changes?
For example, suppose at the present moment my external IP is 1.1.1.1.1 and suddenly the IP changes to 2.2.2.2.2 - is there a way to programmatically instruct program to execute request or navigate to a site only if my external IP is still equal to 1.1.1.1.1?
The purpose of this is that I would like to retrieve certain characteristics of the new proxy (such as the city, state or ISP) before actually executing a request with the proxy.
Someone might suggest simply making a request to an external server to get my external IP before executing each request - however it is possible that the external IP will change immediately after I do this - how can I guarantee consistency of external IP?
Related
When I use a Spring Boot app in local it uses, localhost:8080. When it is pushed to Pivotal Cloud Foundry, it has some route https://my-app.xyz-domain.com and we can access the URL without a port, what is happening behind the scene?
Please help me understand.
There is a default port number for each protocol which is used by the browser if none is specified. For https it is 443, for http 80 and for telnet 23.
On Unix and similar systems like Linux, those are often not available to a developer so other ports are used but then they have to be specified. 8080 is often available and looks like 80.
On CloudFoundry, your application is actually still running on localhost:8080. The reason that you can access your application through https://my-app.xyz-domain.com is that the platform handles routing the traffic from that URL to your application.
The way this works is as follows:
You deploy your application. It's run by the foundation in a container. The container is assigned a port, which it provides to the application through the $PORT env variable (this can technically change, but it's been 8080 for a long time). Your application then listens on localhost:$PORT or effectively localhost:8080.
The platform also runs Envoy in your container. It's configured to listen for incoming HTTP and HTTPS requests, and it will proxy that traffic to your application on localhost:$PORT.
Using the cf cli, you map a route to your application. This is a logical rule that tells the platform what external traffic should go to your application. A route can consist of a hostname, domain, and/or path. For example, my-cool-app.example.com or my-cool-app.example.com/foo. For a route to work, the domain must have its DNS directed to the platform.
When an end-user accesses the route that you mapped, the DNS resolves to the platform and the traffic is directed to the external load balancers (sometimes TCP/layer4, sometimes HTTPS/layer7) that sit in front of the platform. These proxies do not have knowledge of CF, they just proxy incoming traffic.
Traffic from the external load balancers is spread across the set of the platform Gorouters. The Gorouter is a second layer of proxies, but these proxies have knowledge of the platform, specifically, all of the routes that have been mapped on the platform and where those applications actually live.
When a request comes to Gorouter, it will recognize the route like my-cool-app.example.com and look up the location of the container where that app is running. Traffic from Gorouter is then proxied to the Envoy which is running in the app container. This ties into step two as the Envoy will route that traffic to your application.
All in total, incoming requests are routed like this:
Client/Browser -> External LBs -> Gorouters -> Envoy -> Application
First, you should change the port to 80 or 443, because HTTP corresponds to 80, and HTTPS corresponds to 443. Then, you should set the domain name to resolve to the current host, so that you can access the current application through the domain name. In addition, if you want to set the local domain name, then The hosts file should be modified.
I am testing and debugging a system where application A submits a POST request to a URL when some event occurs. One of my programs, application B, must react to this event.
Application A requires that the URL uses HTTPS. I don't want to use a self-signed certificate because it may cause problems (curl complains about the self-signed certificate when I test it locally).
Letsencrypt can create a SSL certificate for free, but requires a domain. This is a problem for me because application B runs on a virtual machine. Whenever the machine is restarted, it gets a different IP address. Currently, there is no domain associated with that machine (i. e. you can only access it via a URL like http://aaa.bbb.ccc.ddd/).
Is there a way to use a non-self-signed certificate for an application without domain (i. e. one that runs on a URL like http://aaa.bbb.ccc.ddd/)? If not, what is the easiest way to make a Spring boot application (application B) support a non-self-signed SSL certificate?
There is one answer suggesting to create one's own certificate authority and installing it on all machines that access the URL. This is not an option for me because I have no control over application A.
Update 1: Application B runs on an EC2 instance in AWS.
Letsencrypt can create a SSL certificate for free, but requires a domain. This is a problem for me because application B runs on a virtual machine. Whenever the machine is restarted, it gets a different IP address.
It does not matter if the IP changes since all what is checked is the domain name. Thus, if the machine gets a new IP address you need to update the DNS to point to this new domain name.
In general the client will check if the subject/SAN of the certificate matches the domain in the URL. It is not possible to get a certificate which is generic enough to cover all the IP addresses you could get. Thus, having your own fixed domain name with a dynamic IP address behind it is the way to go if you want to use normal clients to access the site.
I'm developing a Java application (launched by Tomee) which needs to call, using JaxRS, an HTTPS server with its hostname, but the hostname is not resolved by the DNS.
In practice, my application creates a VM using Openstack API, so the IP address has been dynamically allocated during the lifetime of the application (which is why it's not solved by the DNS).
But I have to call an HTTPS server running on that VM, for which the certificate was signed using a given hostname, so I MUST call it with https://hostname, and not with https://ip_address...
I am not allowed to "play" with TLS configuration, by (for example) disabling Common Name check, so the only solution I see is to be able to "intercept" a DNS resolution request, to provide the good IP address to use.
The How to override DNS in HTTP connections in Java page shows a solution using Apache HttpClient - however, our microservice was entirely built on JaxRS, and I failed to find a way to do the same thing with it.
The client used is the v3.2.2 version of org.apache.cxf:cxf-rt-rs-client, provided by the Tomee we are based on.
Thanks for your attention!
I've deployed one application developed using Java-Struts on one of my client's office. Application is web-based - So we hosted it on one the machine available in client's office - using static ip. The application runs fine(well I had couple of issues to deal with honestly). But when we were testing the application within client's environment - we came across odd issue.
If client needs to access the application inside their network - they need to use local ip address, something like this -
http://192.168.1.12:8080/CTS
Outside the network - they need to use following url -
http://99.99.999.999:8080/CTS
How I can make sure client does not have to use 2 different urls to access this application?
I went through few forums and got to know about host mapping and NAT forwarding, etc. I'm not a networking expert, So I really need some guidance of how to achieve this with right method.
Thank you very much in advance.
For security reason the intranet IP(http://192.168.1.12:8080/CTS) is not exposed publicly.Have to check with the network team of Client whether the IP is publicly exposed if not then map local IP with domain/Static IP and that should be exposed publicly.If it is publicly exposed then within the network too the client can access intranet IP/domain.
I am working on a java project where we have a server and a client application. The server accepts a connection and sends requested data to a client through socket programming.
Everything works fine but when uploaded and working on server I get connections from unknown ip's. And this application will be used from many countries so there wont be specific ip's to whitelist.
Is there a way to ban / reject these ip's so that only connections from my application should be accepted by the server using sockets. Is it possible to send custom data when requesting connections to the server so that it will tell the server to accept only these connections.
The selective acceptance you describe falls within the scope of authentication and authorization. You will want connecting clients to:
Identify themselves to you, so you can determine wether they are allowed access to the server. This can be accomplished by many means, ie IP or MAC address whitelisting, client side certificates, basic/digest authentication, or some other custom a uthentication scheme.
Once allowed access, you can further scope down what the connecting client can do in the system via authorization rules.
I recommend taking a look at libraries like Apache Shiro, that will do some of the heavy lifting for you.
After accepting the inbound connection you can use Socket.getInetAddress() on the returned Socket to retrieve and subsequently validate the IP.
If the IP is not allowed, then use Socket.close() to close the unwanted connection.
Edit:
Validation can of course be based on things beyond just IP. Once the connection is open you can use its streams to transfer arbitrary data to identify the client for instance closing the connection following an authentication failure.
Doing this you should, however, consider the possibility of someone being able to intercept your communications. In other words using a secure connection would make sense.
I'm not aware of a way in which you can authenticate clients in Java prior to opening (accepting) the connection.
If your server and client should be validated, you should think about using certificates also.
Here are some more information :
the java class
another SO question