Node.js socket hang up when agent is present - node.js

I have the following setup:
Client => Proxy server => Origin Server
I'm using the following Node.js libraries for each of these pieces, respectively:
isomorphic-fetch => http-proxy => http
Here's a gist of the setup in two files, one for each of the servers and one for the client: https://gist.github.com/headquarters/850cbb199ff397c6da56fb8d86113a7e
To run this locally, run node server.js in one shell and node fetch.js in another shell.
With the servers running, if I go to http://localhost:8818 in a browser, I get the sample response {"a":"b"}, so that's working. If I go to http://localhost:9818, I also get that response, so the proxying appears to be working fine. However, if I run DEBUG=* node fetch.js, which includes the HTTP proxy agent, the request fails (see output at https://gist.github.com/headquarters/850cbb199ff397c6da56fb8d86113a7e#file-failure-txt).
Without the agent property, the fetch command works fine on the command line. How do I go about debugging this socket hang up error?

Turns out I didn't read the https-proxy-agent docs closely enough. This line was a bit confusing: An HTTP(s) proxy http.Agent implementation for HTTPS--the PROXY itself can be either HTTP or HTTPS, but the origin server has to be HTTPS for this flavor of proxy-agent. For an HTTP origin server, I had to use http-proxy-agent. Thus, the socket hang up was probably coming from https.Agent trying to access an HTTP endpoint. It worked when I switched to http-proxy-agent.

Related

Run nodejs app through HTTPS

I have a node app that is setup on SSH by running node osjs run --hostname=dc-619670cb94e6.vtxfactory.org --port=4100.
It starts at http://dc-619670cb94e6.vtxfactory.org:4100/ without problems, but instead I want to serve it through HTTPS https://dc-619670cb94e6.vtxfactory.org:4100/ , where I receive an error ERR_CONNECTION_CLOSED.
If I use the port I'm unable to reach it with https, but https://dc-619670cb94e6.vtxfactory.org/ is accessible.
How can I serve the port 4100 through htttps?
Thanks.
This is an implementation detail of OS.js. Their docs recommend setting up a reverse proxy for servers. Doing this will give you more control over SSL and ports, like you want
https://manual.os-js.org/installation/

Mask remote request to Tornado server as local

I have a Tornado server running on some port
And if I make a request via browser to non existing url, Tornado prints:
WARNING:tornado.access:404 POST /some_url/ (MY.REAL.IP) 0.64ms python
But I noticed another 404 error done via localhost:
WARNING:tornado.access:404 POST /some_url/ (127.0.0.1) 0.64ms python
Is it possible in theory, that this request was done by some "cool hacker" from remote server using curl --resolve or something?
The only way this address should be spoofable would be if you set xheaders=True in your HTTPServer constructor. If you use xheaders=True, you should also be using a frontend proxy that sanitizes headers appropriately so it will not allow X-Real-IP headers from outside sources.

Get error when i try to test Multi-Room Chat Application sample code

i found this sample code from github as chat-nodejs named and i want to test it how is it work, after installing socket.io and expressjs and running server and click to connect to server i get this error on firebug:
GET https://apis.google.com/_/scs/apps-static/_/js/k=...TcCOZ5yY8jtGvNKVwrKHFFcvb9eCe_w/cb=gapi.loaded_1
GET http://localhost/socket.io/?EIO=3&transport=polling&t=LbtPp7S
"NetworkError:404 Not Found -
http://localhost/socket.io/?EIO=3&transport=polling&t=LbtPp7S"?EIO=3&...LbtPp7S
Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at
http://localhost/socket.io/?EIO=3&transport=polling&t=LbtPp7S.
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
You're getting a NetworkError:404 Not Found because the serverAddress in Line 15 of chat.io.js doesn't have the server port 8080 in it. Add port number to it.
serverAddress = 'http://localhost:8080',
Additionally, socket.io might not work well if the client and server installation of it, are of different version.
index.html doesn't use a local one. The recent version of socket.io dint work for this repo. I had to install 0.9.13 on the server side for it to work.

Why does swapping between container IP and alias cause difference in AJAX request?

I have a small sample project located here that illustrates the problem I am seeing when working with a nginx + node + host docker stack.
I have 2 containers:
A node (express) application that simply returns a json object. It is CORs enabled based on this website. It has it's port published to host via 3000:80
An nginx server that is also CORs enabled based on this website. It only serves static content (index.html and main.js files) from the default location (/usr/shared/nginx/html). Its port is published via 8080:80.
When running the containers individually from host I can access the node server and see the JSON object being returned. When I access the nginx server, I see my index.html and the javascript code from main.js runs.
Now I have the node app container linked to the nginx server container. From inside my main.js file of the nginx container, I attempt to access the server at http://nodeapp/api. I am seeing a CORs error
XMLHttpRequest cannot load http://nodeapp/api. No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:8080' is therefore not allowed
access.
The strange thing is, the response header indicates it is coming from nginx and not my express application as I would expect. The nginx container is also not logging anything.
Things that worked
If I change the url for the XMLHttpRequest to the node container's IP (say 172.17.0.2) it works as expected and the response header indicates it is coming from the express server. In my /etc/hosts file there is an entry:
172.17.0.2 nodeapp abc123ContainerId quickserve_nodeapp_run_1
When I curl the node container from an interactive tty container it also works as expected.
If I load the node container and use http-server (server on host) it works as expected and the response header indicates it is coming from the express server.
Just in case it has an incluence, that old thread (2013) mentioned a cor option on the docker daemon.
Nowadays (Q4 2015), the docker daemon includes:
--api-cors-header="" Set CORS headers in the remote API
To set cross origin requests to the remote api please give values to --api-cors-header when running Docker in daemon mode. Set * (asterisk) allows all, default or blank means CORS disabled
$ docker -d -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
That might be a setting to use in your case.

Node.js request SSL error: SSL23_GET_SERVER_HELLO:tlsv1

I am making a request to a remote server using https and request, and getting a new error after updating node and request:
nes.get err: [Error: 140735207432576:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:../deps/openssl/openssl/ssl/s23_clnt.c:741:
I already have the protocol set to SSLv3, so I'm wondering why it appears to be using tlsv1.
https.globalAgent.options.secureProtocol = 'SSLv3_method';
I've also tried adding this to request's options:
secureProtocol: 'SSLv3_method'
This error did not occur with earlier versions of Node.js and request, but now with node v0.10.15 and request 2.26.0, it has surfaced. Any ideas? Thanks!
Update -- narrowed this down to something that changes between request 2.14.0 and 2.16.0. 2.14.0 works and 2.16.0 does not work.
Make sure you are making a secure request to the correct port.
I've received this error when attempting to make a secure request to port 80 instead of port 443.
I would fire up Wireshark to verify that the bits on the wire are what you think they should be.

Resources