I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).
My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo.
I'm using Chrome 12.0 on Windows7.
I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.
However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.
Any ideas as to why this might be happening?
Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?
Many thanks,
-Dave
Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.
There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.
It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.
Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.
It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.
Related
I'm using HAProxy as reverse-proxy for https connections. I have some rules like this:
use_backend server2 if { req_ssl_sni -i test.domain.com }
yesterday i changed a backend for one acl, but somehow some (!!) clients still get the content of the old backend (which is still active for other acls). I can see two different result on the same machine in chrome if one chrome runs in privacy mode.
Restart and reload didn't help.
It looks that I solved it. I think the Problem was the passthrough via TCP. I change the config to do the SSL Termination by HAProxy and handle it via http. Seems like the rules for TCP / req_ssl_sni were only used for the first connection and bypassed for the following connections even if the hostname changed.
I am writing an action script 3.0 client that has to communicate with a remote server. In localhost environment everything works fine, but if I test the client in the real internet environment there is no connection.
My guess is that it has to do with the cross domain policy file, but calling
Security.loadPolicyFile("xmlsocket://"+targetIP);
does not send the <policy file request\> message to the server on the default 843 port, or any port for that matter. I think it might be because flash recognises that the address is local and omits the request. But I need to receive it to be able to implement the answer on the server. Otherwise I'd be coding blindly.
Is there a way to force the flash client to behave as if it was in a different domain while still being in localhost so I can troubleshoot this issue without involving a remote host? I don't have many resources in that regard.
Try running the client on 'localhost', and load the policy file from '127.0.0.1'.
They should be seen as different 'domains'.
I want to hotlink an image from a remote website. This works when I test in my local PC (Apache server), but doesn't work when I try from my website.
I am not an expert in this subject, but as I understand if hot-linking was blocked in the remote site, it should not work in my local server as well, right? In that case what might be the issue (my hosting provider is saying they don't have any issue)?
Let's play this through.
On your local server:
You make a request to 127.0.0.1 (or localhost) that returns some HTML with a hotlinked image to example.com.
The browser makes a subsequent request to example.com and sets the referer header to 127.0.0.1.
Now example.com has to determine whether the referrer is allowed to hotlink or not.
Since, for that server, example.com and 127.0.0.1 both refer to the same thing, namely the server itself, this looks like a valid request.
On your remote server:
Same as above, but replace 127.0.0.1 with your.favourite.url.
This time when the server validates the referrer, it will come to the conclusion that your.favourite.url and example.com do not refer to the same thing, and therefore block the image request.
This could be seen as a misconfiguration of example.com, since the referrer might not resolve to the same point from both client and server context.
If you access your local server via your local network IP (e.g. 192.168.1.42), then hotlinking should no longer work, unless example.com has a really graceful referrer policy, or happens to use exactly the same local IP as you.
It could also be possible to expose example.com's local IP by brute-forcing all local network IPs, though while that technically is an information leak, there's not much you can do with it.
I have this project for my classes i'm currently workin' on. here it is:
WebPage client for Telnet not on standard ports, with ability to choose a port and connect
I have machines with telnet servers on them, just waiting for connection.
So my idea was to set up a nodeJS with express server on a dedicated machine. This would handle connections through telnet and host a page for clients, that would use socket.io to exchange information with server side.
But as i'm new to such technologies (telecommunications student) i wonder if it is possible. I spotted something like this - jsterm.com by Peter Nitsch, but i see there are some massive gaps in code and the demo does not really work so i don't know if it actually works. Did anyone try this?
My other problem is - when i send information to nodeJS server through websockets, which seems achievable for me, what do i do with this information? Do i just set up another websocket to pass the same data i got from client websocket directly to the telnet port?
Can sockets connect directly to specific port, without any websocket waiting on the other side?
If my idea is wrong, could anyone help me - maybe there exists some nice solution - i was thinking about Anyterm for example but i see that it requires an apache server and runs completely different technologies...
Just to be clear, WebSocket connections are not raw TCP socket connections. They have extra header information in each packet, browser to server data is masked using a running XOR, etc.
In order for the browser to communicate with a normal TCP server (e.g. a telnet server) you will need some sort of bridge service. It just so happens that such a thing already exists. websockify is a server that accepts WebSocket connections and bridges them to a raw TCP server.
In fact, the websockify project already includes a working telnet client as an example application. However, note that one limitation of websockify (for security reasons) is that the client cannot pick an arbitrary server address/port to connect to. The target address(es) must be predefined, either as a single target specified on the command line for websockify, or as multiple targets specified in a configuration file (and selected via a token in the WebSocket connect string).
There are multiple implementations of websockify in different languages (python, C, node, ruby, Clojure) however, only the python version currently supports multiple targets via a configuration file.
Disclaimer: I created websockify.
I already have a server with port and want to write a web app to get the information form the port. Will this be possible with WebPorts?
The Client doesn't even need to talk back to the server, which is the whole point of websockets I would imagine, but since I already have the ports setup, I might be easier and cleaner to just connect and get the info without having to refresh.
WebSockets are not intended as clear TCP channels over which other existing protocols can be implemented.
WebSockets are designed to allow messages to be sent between a client and server, where an event is raised each time a message is received.
Hence a WebSocket client cannot simply connect to an existing TCP server - that server also has to speak the WebSocket protocol.
You could of course write a WebSocket-based server that does nothing but act as a proxy to existing network services.
I think you want websockify which is a WebSocket to plain TCP socket bridge/proxy. It also allows sending and receiving of binary data with the older version of the WebSocket protocol which hadn't yet added direct binary data support.
Disclaimer: I created websockify.