I am working on a pyramid realtime app that would benefit from utilizing websockets. I found that the gevent-socketio library would probably be best for my purposes.
When testing locally on my PC, the websocket transport is used and runs just fine. However, when testing on a server, the handshake fails reporting a 401 response. It then falls back to a long polling transport, which works, but I would really benefit from the speed of websocket.
This makes me believe that there is some kind of authorization issue happening since I am not connecting to the local machine anymore, but I am at a complete loss as to where to look for help.
EDIT:
Now the issue was narrowed down to the fact that we were using mod_proxy, a lighttpd module, to instance the server for development and production. Is there any work around for proxying or do we have to a abandon the idea of server instancing? Ideally we would like to have some way of authorizing users to access our development server, which is how we had it set up with mod_proxy.
Related
I was experimenting hashicorp/yamux over gorilla/websocket, and got stuck.
I started with vanilla WebSocket using the echo example from Gorilla WebSocket project. It was very a straight forward client-server setup. Then image that the server is now behind a firewall, thus the client cannot make a direct connection to it. So I introduced a hub and an agent. The hub is supposed to be publicly visible and connectable for the client. The agent would run alongside the server, who would first make a WebSocket connection to the hub and then multiplex the connection using Yamux so that the hub can then initiate requests to the server. In this way, I effectively "exposed" the server beyond the firewall.
For normal HTTP endpoints, things are good. The client can make requests to the hub, who would proxy these requests to the agent using the WebSocket connection initiated by the hub, and then the hub would further proxy these requests to the server.
However, this trick failed to work with WebSocket endpoints. For the echo example, the client can access the HTML on / through the hub-agent-server chain, but would fail on the /echo path, which is a WebSocket endpoint.
My question is, is this WebSocker over Yamux over WebSocket fundamentally impossible, or do I just need some extra lines to get things work? Here's the code I've been experimenting with. Really appreciate your helps!
I have an https site that needs data from an API that is only available in http.
To get around the mixed content warning, I changed it so the JS requests a path on the server, which then makes the http request and returns the data.
Is this bad? If it is bad, why?
My understanding of what you're doing :
You are providing a HTTPS url on your server which is essentially acting as a proxy, making a backend connection between your server and the API provider over HTTP.
If my understanding of what you're doing is correct, then what you're doing is better than just serving everything over HTTP...
You are providing security between the client and your server. Most security threats that would take advantage of a plain HTTP connection are in the local environment of the client - such as on a shared local network. Dodgy wifi in a cafe. School lans. etc.
The connection between your server and the API provider is unencrypted but apparently they only provide that unencrypted anyway. This is really the best you can do unless your API provider starts providing an HTTPS interface.
It's more secure than doing nothing and should eliminate the browser errors.
If there is a real need for security (PCI compliance, HIPAA etc) however, you should stop using that API. However it seems unlikely considering the circumstantial evidence in your question.
I have a server that uses websockets. It is written in Go. For testing, I have another application written in Go. To test, I start the server, then run the test client. The test client creates websocket connections to the server and does things (basically impersonating user activity). Both the client and the server are using the gorilla/websockets library, and standard browsers also work fine with the server.
This was all working beautifully.
To support non-compliant browsers, I was asked to start using the SockJS Go server library. I did this and the new version works just fine when used from a browser by clients using the SockJS library.
Now for the problem. SockJS does not accept incoming websocket connections. Only connections from the SockJS client. So my testing application doesn't work, and I'm unable to test.
I could recover the old version of my connection code from git and make a separate connection type that uses gorilla/websockets and have my server listen on an additional port that only listens on localhost. This would allow me to test the functionality. The downside is that I have to maintain two versions of essentially the same code, and I wouldn't be testing the real user experience and possibly not find bugs until production.
Ideally the SockJS server, considering it still uses gorilla/websockets as a dependency would automatically accept proper websocket connections, but barring that it seems I'd need a SockJS client library in Go which, as far as I can tell, doesn't exist.
Does anyone have a solution for this? Thanks!
I'm starting with Websockets and I have a problem.
I have a sails.js application that uses sockets to update the client side.
On the client side it makes an API call using socket.get("/api/v1/actor...") to bring all the items of the database. When I see what the WebSocket's traffic on the Chrome console:
As you can see, the connection has been established and the API call has been correctly done through the socket.
The problem is, there is no answer from the server, not even an error.
If I make the same API call using ajax, I get response, but it doesn't work using WebSockets.
Any idea what might be producing this behavior?
EDIT: I add here the code here that processes the request and this one here that sends the request, but the problem is that it never execute this code. I think we we are closer to the find the cause, since we think it has to do with a network problem. We figured there is an F5 reverse-proxy which is not properly set up to handle websockets
The answer didn't make any sense now that I've seen the code that's why I've edited it. I only answered because I could't comment on your question and ask you for the code.
Your calling code seems correct and the server side of things the process of response should be handled automatically by the framework, you only need to return some JSON in the controller method.
I instantiated a copy of the server (just changed the adapters to run it locally) and the server replied to the web socket requests (although I only tested the route '/index').
Normally when the problems are caused by a reverse proxy the socket simply refuses to connect and you can't even send data to server. Does the property "socket.socket.connected" returns true?
The best way to test is to write a small node application with socket.io client and test it in the same machine that the application server is running, then you can exclude network problems.
I use IE 10 to run Meteor project with IP Address but it error in console log
"SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 403, Forbidden"
I test uncheck "Use a proxy server" in Internet Option it work, but my office must use proxy server.
How i cant fix this problem ?
Thank you every much
Your web proxy must support websockets to use them. Meteor will automatically fall back to long polling over http for cases like this. You can still use everything as normal but it'll take a bit longer to load (its very slight).
This error comes about because meteor is trying to use websockets and if it fails it falls back to long polling.
If you know you always want to use XHR/Longpolling without trying websockets start meteor with DISABLE_WEBSOCKETS as an environment variable