For network gurus out there, I'll like to ask some questions regarding some unique setup where the server will be sending a request to a client on localhost on a certain port.
I have a cloudy understanding of some network fundamentals that I hope you'll be able to help me out.
Kindly check the image below:
Basically, there's a static website hosted in AWS s3 and at some point this website will send a request to https://localhost:8001.
I was expecting that it will connect to the nginx container listening on port 8001 in my local machine, but it results in 504 gateway error.
My questions are:
Is it possible for a remote server to directly send data to a client at a particular port by addressing it as localhost?
How is it possible for the static website to communicate to my local docker container?
Thanks in advance.
In the setup you show, in the context of a Web site, localhost isn't in your picture at all. It's the desktop machine running the end user's Web browser.
More generally, you show several boxes in your diagram – "local machine", "Docker VM", "individual container", "server in Amazon's data center" – and within each of these boxes, if they make an outbound request to localhost, it reaches back to itself.
You have two basic options here:
(1) Set up a separate (Route 53) DNS name for your back-end service, and use that https://backend.example.com/... host name in your front-end application.
(2) Set up an HTTP reverse proxy that forwards /, /assets, ... to S3, and /api to the back-end service. In your front-end application use only the HTTP path with no host name at all.
The second option is more work to set up, but once you've set it up, it's much easier to develop code for. Webpack has a similar "proxy the backend" option for day-to-day development. This setup means the front-end application itself doesn't care where it's running, and you don't need to rebuild the application if the URL changes (or an individual developer needs to run it on their local system).
Related
I'm quite new to AWS and I have been starting to work with EC2 instances. I have a web application that has a frontend and backend separately. So first I hosted the backend application on EC2 instance and it is a Symfony framework based REST API Application. So I have installed all dependencies and now the application is running. But to check the application I ran some API calls to the application using postman and seems application is not working as intended. I get following response from Postman. I have also provided security group configurations properly.
When I start sysmfony app it says [OK] Server listening on http://127.0.0.1:8000.
Can't figure out why this is happening. Can someone help me here?
You are running your application trough CLI (Symfony web server bundle) , by default this will bind to 127.0.0.1 which can't be accessed from outside. To fix this, you must bind to your server's public IP/hostname and port:
php bin/console server:start 192.168.1.1:8000 # replace with your ip
You can also bind to all your IP addresses using 0.0.0.0
But keep in mind, you should not use built in server for production, it's slow and less secure. Use a real web server instead, like Apache or Nginx.
I have a web application hosted on an external server. I would create a communication beetwen my home server and the web application.
I thought something like that:
my home server send its ip to the web application
the web application send data to the home server
my home server send back some data
I want to implemente a P2P communication between the WebApp and the home server
it would be bettere if the communication is encrypted
i dont want to use dynamic dns
Is there something to implement that?
There are several types of IP. It can be "grey" and "white".
"Grey" means that your computer can't be accesses through it.
"White" IP's can be accessed directly. Also there are dynamic IP's
that changes through the time. It all depends from the provider.
It's possible that you have "white dynamic" IP but it's pretty rare
for providers to do.
It's easier to connect to server because it
always have "white" permament IP.
TCP/IP already does most of the work. You just create tcp connection and it stays. You just think about sending data.
My suggestion for you is to create something like this:
Home server connects to WebApp
Home server requests some data and WebApp sends back data
Home server sends request containing data and server respondes that all is ok
So you have client-server model. And client always does only requests and server does only responses. And they do not switch. It's easier to maintain.
There is common technology of doing that and it includes encryption too.
You should use HTTPS protocol. Https will do all the encryption(and safely exchange keys too) you just worry about certificates(there are ways not to buy certificate but sign them by yourself. It's whole another topic)
So you will send https requests from your home server PC(client) and get responses from server(webApp).
As you write on Python you would find this answer helpful for you:
HTTPS request in Python
I'm trying to create a web app on AWS and I'm running into port issues. I would like to have multiple apps providing different services on different ports. I've created a website (on the same instance) to receive a text query and pass it to my app on port 3000. The app listening on 3000 is written in CherryPy.
We are using a VPN to provide security for the AWS instance. When logged into the VPN, everything works fine. The web page loads, the query returns the correct data. When I disconnect from the VPN, or someone else goes to the page, the page still loads, but queries to the service time out.
I've used netstat to make sure the service is listening but I'm not sure what could be blocking traffic. I've worked through the CORS issues as evident by the fact it works when I'm signed into the VPN.
What can I check now?
When I disconnect from the VPN, or someone else goes to the page, the page still loads, but queries to the service time out.
My assumption is that the web server and the app are on the same server.
It sounds very much like the connection from web server to app is happening via a routed IP address rather than localhost. In addition to being slower, it's also hitting your firewall rules.
Configure the web server to access your app on localhost:3000 and the issue should clear up.
I actually got it working. I have an AWS instance with nginix and CherryPy. When the user goes to a web address, the nginix page loads with a form for a query string. When they submit a string, the string is POSTed to a CherryPy service running on port 3000. The CherryPy service does some computations and returns a result via JSON.
I thought I had opened up everything completely for testing, but I was having so many issues. It turned out that having CherryPy set
"Access-Control-Allow-Origin" = "*"
wasn't working, instead I needed to specifically set the origin of the calling page.
I have a Javax web service deployed in a remote Linux machine within a JBoss ESB container. I am able to test the web service using soapUI on the same machine as where the service is deployed. The WDSL URI I used was something like http://127.0.0.1:8080/abcd/abcd?wsdl.
What I would like to do is to be able to test the same service from another machine using soapUI. I tried replacing 127.0.0.1 with the IP address of the machine where the service is deployed. This does not seem to work. Can someone tell me what I am missing here?
Thanks.
a sum of things could go wrong there - as already mentioned by the others the firewall is blocking access for the given (address, port) pair. Another thing that happened to me was that the WSDL was generated using the name of the machine it was deployed on and whenever I was trying to call the service from a different machine it was complaining that I cannot find the given machine.
You need to test network connectively. One tool you can use is plain old telnet. If you telnet to the ip/port combo of the web server, you will get a response (an HTTP error). For example:
$ telnet 192.168.0.10 8080
If you get nothing then there is almost certainly a firewall blocking access.
If you are convinced that no firewall is blocking you, the other possibility is that the web server is only bound to the local network adapter (127.0.0.1) and not the other network adapters (ethernet/wifi). This is very unlikely however.
I am trying to call a web service from a BizTalk (2006) orchestration.
Having got the hang of the basics, I have been following this tutorial (page 74 onwards) in which i have a web reference to an external web service (I am using this web service instead of the one in the tutorial), I have my web message in a Send component, and have set up the request / response ports for the web service call.
I'm fairly sure that eveything is set up correctly, but my orchestration fails to call the web service with the following error:
The adapter failed to transmit the message going to send port
"My_Order_Processor.Orchestration-CurrencyConvertPort-36c122f41c5596ae"
with URL "http://www.webservicex/net/CurrencyConvertor.asmx.
WebException: Unable to connect to the remote server.
SocketException: An existing connection was forcibly
closed by the remote host 209.162.186.60:80
The IP 209.162.186.60 is the address for the web service I am trying to connect to. I am trying to narrow down the reasons for the error, e.g.:
Firewall issues
Proxy server issues (I don't know how to configure BizTalk to use a proxy server)
Something else
The BizTalk server can ping the web service, I can access the internet (through IE), I can add the WebReference to the project successfully (meaning at least the orchestration designer can access the web service okay). I have also tried a different web service, with the same result.
Any ideas on finding out why this is happening or how to find out more info? (I'm new to BizTalk)
I've seen this veru vague error before for many different reasons. Two suggestions.
Download something like NetMon and watch what is going on on the wire.
Turn off chunked encoding. For some reason, many web services don't handle this well.
Let us know what you find out.
Could this not be an authentication issue? Check that you can connect to the webservice using the Bts credentials.
This turned out to be a proxy issue.
By navigating to Biz Talk Group -> Platform Settings -> Adapters -> SOAP, I was able to configure the BizTalk server host's SOAP adapter (which is what the web service call uses to make the call) to use our company proxy server correctly. Double click the 'send' SOAP adapter, go to Properties under adapter name.