I have a custom websockets server (non-secure) implemented with of libuv. Same server also supports some HTTP requests (source).
Everything works just fine if I listen on 127.0.0.1, except some users are reporting that they can't connect from remote systems. HTTP requests work fine if I listen on 0.0.0.0 but browsers and VS Code do not seem to even try to send Upgrade request. What could be the reason? Could it be my workstation setup (e.g. some sort of a firewall)?
Something wrong with my corp network settings - works just fine in other networks...
Related
I made a proxy server in python 3. It listens on the port 4444. It basically receives the request from clients and sends it to the server. I want to use it as a firewall to my Dvwa server. So added another functionality to the proxy. What it does is, before sending the request to the DVWA server, it validates the input.
But the problem is, the clients have to configure their proxy settings in the browser to use my proxy server. Is there any way to access the proxy without configuring the browser settings. Basically I want to host the proxy server instead of the original web server. So that all the traffic goes through the proxy before going to the webserver.
Thanks in advance...
You don't say whether your Python3 proxy is hosted on the same machine as the DVWA.
Assuming it is, the solution is simple: a reverse-proxy configuration. Your proxy transparently accepts and forwards requests to your server who then processes them and sends them back via the proxy to the client.
Have your proxy listen on port 80
Have the DVWA listen on a port other than 80 so it's not clashing (e.g. 8080)
Your proxy, which is now receiving requests for the IP/hostname which would otherwise go to the DVWA, then forwards them as usual.
The client/web browser is none the wiser that anything has changed. No settings need changing.
That's the best case scenario, given the information provided in your question. Unfortunately, I can't give any alternative solutions without knowing the network layout, where the machines reside, and the intent of the project. Some things to consider:
do you have a proper separation of concerns for this middleware you're building?
what is the purpose of the proxy?
is it for debugging/observing traffic?
are you actually trying to build a Web Application Firewall?
My clients are using a proxy server on their corporation,and I want to set up dev environment for testing development related to proxy issues.
So, I want to set up a proxy server which blocks all port 80 requests, unless the request is requested by the proxy server.
This is what I tried:
Installing fiddler2 on port 8888.
Setting up two rules on windows firewall:
Block all port 80 requests.
Allow all requests from fiddler exe.
Then, I opened FF and changed the proxy server to be 127.0.0.1:8888.
Unfortunately, the requests from the fiddler are still blocked.
What am I doing wrong?
Is there other program which do that easier? (Tried also with CCProxy without success).
Found the answer this great post:
Block all the outbound connections on the firewall.
Allow request from fiddler.exe
I am working a project that involves a java client interacting with a socket.io based server over websockets. In order to test fallback from websockets to xhr-polling i need to simulate a websocket blocking on my windows host.
How can this be done ?
It is not trivial to disable websocket in Windows firewall. Disabling this protocol in browser is not a way - in case you want to test fallback when websocket supported by browser but blocked by firewall, antivirus, domain policy rules, ...
I've simulated this behaviour by running nodejs server with grunt-connect-proxy. By default it blocks ws:// protocol but you can easy enable it using
option.ws = true
I'm having a bizarre issue. I'm running Sails 0.9.7 and locally everything works great. Deployed on Heroku, everything works great except while I'm at work. At work, the pages work fine, but Sockets is getting 503ed:
WebSocket connection to 'ws://gameshowhub.herokuapp.com/socket.io/1/websocket/usGTFi4hOfyza-B4LN8d' failed: Error during WebSocket handshake: Unexpected response code: 503
Everywhere else I go (geographically) the page seems to work, so I think my work network is blocking the Sockets port. Does that sound right? Where can I change the socket's port in Sails - I can't seem to find it anywhere...
sails sockets will use the default port: sails.config.port this will be 1337 if you didn't change it.
Heroku doesn't support websockets out of the box. You'll need to enable them via:
heroku labs:enable websockets
More info at devcenter.heroku.com/articles/node-websockets.
If websockets will get blocked via firewall they should switch to
htmlfile
xhr-polling
jsonp-polling
you may also enable flashsockets in the config/sockets.js-file.
I wanna create a connection between my mobile Safari and nodejs + socket.io on my Macbook.
When i call localhost:8080 from my laptop, everything works fine. The console says that the client is connected and my little website is displayed.
When i call it over my mobile browser with 10.0.1.5:8080, the website is displayed as well, but my socket.io don't identify the mobile browser (iPhone) as client and nothing happens on the console board.
Does anybody where the problem is?
I found this post on SO, probably can help you out. why does my nodejs socket.io app not work on ios6
Localhost is local to the machine. You're IP should use a ip address
or domain name:
something like: io.connect('192.168.1.110'); or
io.connect('test.myapp.com');
WebSockets do not work over cellular network as they are not forwarded by the http proxy.
A possible workaround it to set the WebSocket server port to 443 (https) which forwards everything (as https is encrypted the proxy has to forward it in order to support https).
To see a real world example which solves this problem this way checkout nearby.
Remember this requires using two http servers:
Serving you mobile application (on port 80)
Serving the web sockets on (port 443)
Else you always have to use the specific ports in your urls which is mostly not preferred in production.