Is it possible to proxy websocket connections within the webpack dev server? I know how to proxy regular HTTP requests to another backend but it's not working for websockets, presumably because the target in the proxy configuration starts with http://...
Version 1.15.0 of the webpack-dev-server supports proxying websocket connections. Add the following to your configuration:
devServer: {
proxy: {
'/api': {
target: 'ws://[address]:[port]',
ws: true
},
},
}
Webpack dev server does not support proxying ws connections yet.
Until then, you can implement proxying manually, by adding additional http-proxy to webpack server:
Add new dependency to package.json:
"http-proxy": "^1.11.2"
Proxy websocket connections manually by listening to upgrade events
// existing webpack-dev-server setup
// ...
var server = new WebpackDevServer(...);
proxy = require('http-proxy').createProxyServer();
server.listeningApp.on('upgrade', function(req, socket) {
if (req.url.match('/socket_url_to_match')) {
console.log('proxying ws', req.url);
proxy.ws(req, socket, {'target': 'ws://localhost:4000/'});
}
});
//start listening
server.listen(...)
NOTE (after using this for some time)
There is an issue with proxying websockets as socket.io is used by WebpackDevServer to notify browser of code changes. socket.io may conflict with proxying websockets; in my case, connections were being dropped before handshake was returned from my server unless it responded very quickly.
At that point, I just ditched WebpackDevServer and used custom implementation based on react-hot-boilerplate
#Mr. Spice's answer is correct. But it can be further simplified, check http-proxy-middleware, it can be set as following, i.e. just add ws: true and keep other settings as usual.
// proxy middleware options
var options = {
target: 'http://www.example.org', // target host
changeOrigin: true, // needed for virtual hosted sites
ws: true, // proxy websockets
...
Related
I'm a beginner in Rust and WebSockets and I'm trying to deploy on Heroku a little chat backend I wrote (everything works on localhost). The build went well and I can see the app is running, and I'm now trying to connect to the WebSocket from a local HTML/Javascript frontend, but it is not working.
Here is my code creating the WebSocket on my rust server on Heroku (using the tungstenite WebSocket crate):
async fn main() -> Result<(), IoError> {
let port = env::var("PORT").unwrap_or_else(|_| "8080".to_string());
let addr = format!("0.0.0.0:{}", port);
// Create the event loop and TCP listener we'll accept connections on.
let try_socket = TcpListener::bind(&addr).await;
let listener = try_socket.expect("Failed to bind");
println!("Listening on: {}", addr);
and here is the code in my Javascript file that tries to connect to that WebSocket:
var ws = new WebSocket("wss://https://myappname.herokuapp.com/");
My web client gets the following error in the console:
WebSocket connection to 'wss://https//rocky-wave-51234.herokuapp.com/' failed
I searched to find the answer to my issue but unfortunately didn't find a fix so far. I've found hints that I might have to create an HTTP server first in my backend and then upgrade it to a WebSocket, but I can't find a resource on how to do that and don't even know if this is in fact the answer to my problem. Help would be greatly appreciated, thanks!
I think your mistake is the URL you use:
"wss://https://myappname.herokuapp.com/"
A URL usually starts with <protocol>://. The relevant protocols here are:
http - unencrypted hypertext
https - encrypted hypertext
ws - unencrypted websocket
wss - encrypted websocket
So if your URL is an encrypted websocket, it should start only with wss://, a connection cannot have multiple protocols at once:
"wss://myappname.herokuapp.com/"
I developed a video chatting application using simple peer and socket.io . But when I tried hosting the application the peers could not be connected because of the firewall issue . I am aware that STUN and TURN servers are to be used for this purpose . Is it possible to connect to those servers using simple peer ?
If so how?
Any explanation or reference articles will be helpful
You can add the iceServer configuration like in original webrtc in the simple-peer config like so:
{
initiator: false,
config: { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }, { urls: 'stun:global.stun.twilio.com:3478?transport=udp' }] },
}
You can add stun servers and/or turn servers.
If you read the source code of the simple-peer npm package you will realize that it currently uses
URLs: [
'stun:stun.l.google.com:19302',
'stun:global.stun.twilio.com:3478'
]
for its public IP discovery needs.
Your app fails to work in case of firewall because just stun server is insufficient in case of firewall.
Besides a STUN server, you need a TURN server is this case.
TURN is the fallback is case STUN fails to deliver.
I am trying to configure Traefik for a WebSocket app, I just try with a simple WS app on docker: https://hub.docker.com/r/jmalloc/echo-server/
To test it I use Chrome SimpleWebSocketClient, so if I use the IP:Port of the app it works fine. If I add the Traefik DNS it fails, I just try with other WS server and clients and fails too, so it would be something of Traefik.
I just try with Traefik versions:
-v1.3.0/raclette
-v1.2.3/morbier
Those are my Traefik rules:
[backends.ws-test-backend]
[backends.ws-test-backend.LoadBalancer]
method = "drr"
[backends.ws-test-backend.servers.server1]
url = "ws://172.16.8.231:3000"
[frontends.ws-test-frontend]
backend = "ws-test-backend"
passHostHeader = true
entrypoints = ["http","https","ws", "wss"]
[frontends.ws-test-frontend.routes.manager]
rule = "Host:ws-test.ikcloud.ikerlan.es"
What could it be wrong?
Any recommended reverse proxy for doing this?
You need to enable sticky session for your ws connections, otherwise it will be reconnecting all the time.
[backends]
[backends.backend1]
# Enable sticky session
[backends.backend1.loadbalancer.stickiness]
I have an application that connects to a web page that sends and receives text strings over a websocket on port 1234. I do not have access to the front end code, so I cannot change the HTML front end code.
I created an autobahn server with a class derived from WebSocketServer protocol that communicates with the web page over port 1234. This works and I am able to send and receive text to the front end.
However, I need to process incoming data and would like to publish the received data to a crossbar.io container through the router on port 8080 (or any other port). The port to the web browser is fixed at 1234.
It there a way for me to "plug in " the autobahn websocket server into the crossbar router or is there an alternative way to create a websocket server that will allow me to to send and receive the text on port 1234 and at the same time participate in pub/sub and RPC with the crossbar router?
I am assuming you are using Python. If you are not, the answer should still be the same, but depending on the language/library and its implementation the answer can change.
From what you are saying, it does not sound like you really need a "plug in". Crossbar does have these under the description of router components. But unless you really need to attach a Python instance directly to the router either for performance or otherwise, I would recommend keeping your application off the router. It would work perfectly fine as a stand alone instance especially if it is on the same machine where the WAMP router is located where the packets would only require to communicate over loopback (which is VERY fast).
Given that you are using Python:
You can use your WebSocketServer and a WampApplicationServer together. The little hiccup you might run into is starting them up properly. In either scenario Python2.x with twisted or Python3.4 with Asyncio you can only start the reactor/event loop once or an error will ensue. (Both Twisted and Asyncio have the same basic concept) In Asyncio you will get RuntimeError: Event loop is running. if you attempt to start the event loop twice. Twisted has a similar error. Using the ApplicationRunner in twisted, there is an option (second argument in run) not to start up the reactor which you can use after the reactor is already running. In Asyncio, there is no such option, the only way I found out how to do it is to inherit the Application runner and overwrite the run method to start the session to be started as a task. Also, be warned that threads do not cooperate with either event loop unless properly wrapped.
Once you have the two connections set up in one instance you can do whatever you want with the data.
Thanks for the idea, and the problems you mention are exactly what I encountered. I did find a solution however, and thanks to the flexibility of crossbar, created a JavaScript guest that allows me to do exactly what I need. Here is the code:
// crossbar setup
var autobahn = require('autobahn');
var connection = new autobahn.Connection({
url: 'ws://127.0.0.1:8080/ws',
realm: 'realm1'
}
);
// Websocket to Scratch setup
// pull in the required node packages and assign variables for the entities
var WebSocketServer = require('websocket').server;
var http = require('http');
var ipPort = 1234; // ip port number for Scratch to use
// this connection is a crossbar connection
connection.onopen = function (session) {
// create an http server that will be used to contain a WebSocket server
var server = http.createServer(function (request, response) {
// We are not processing any HTTP, so this is an empty function. 'server' is a wrapper for the
// WebSocketServer we are going to create below.
});
// Create an IP listener using the http server
server.listen(ipPort, function () {
console.log('Webserver created and listening on port ' + ipPort);
});
// create the WebSocket Server and associate it with the httpServer
var wsServer = new WebSocketServer({
httpServer: server
});
// WebSocket server has been activated and a 'request' message has been received from client websocket
wsServer.on('request', function (request) {
// accept a connection request from Xi4S
//myconnection is the WS connection to Scratch
myconnection = request.accept(null, request.origin); // The server is now 'online'
// Process Xi4S messages
myconnection.on('message', function (message) {
console.log('message received: ' + message.utf8Data);
session.publish('com.serial.data', [message.utf8Data]);
// Process each message type received
myconnection.on('close', function (myconnection) {
console.log('Client closed connection');
boardReset();
});
});
});
};
connection.open();
I have the app running and it doesn't find socket.io and gives me 404.
this is the client:
<script src="http://game-test-1.herokuapp.com/socket.io/socket.io.js"></script>
<script>var socket = io.connect('http://game-test-1.herokuapp.com');</script>
and this is the server:
var express = require('express'),
routes = require('./routes'),
user = require('./routes/user'),
http = require('http'),
path = require('path'),
express = require("express"),
app = express(),
server = http.createServer(app),
io = require('socket.io').listen(server);
server.listen(80);
I tried changing the ports and doing http://game-test-1.herokuapp.com:81/... but that gave me an error
How do I link socket.io correctly?
Heroku requires that your application listens on a port of Heroku's choosing. Heroku will tell your application this port when it launches your application, via the PORT environment variable. If you listen on any other port, Heroku will ignore it and will terminate your application after 60 seconds.
Your users' browsers will still use ports 80 for HTTP traffic and 443 for HTTPS traffic. Heroku's routing layer, which is in-between the user's browser and your application, will send the HTTP traffic through to your application at the port Heroku designated for your application.
Heroku Dev Center has a guide on using socket.io on Heroku. In particular, you'll need this bit of config:
// assuming io is the Socket.IO server object
io.configure(function () {
io.set("transports", ["xhr-polling"]);
io.set("polling duration", 10);
});
This is because Heroku does not support Websockets at this time (to the best of my knowledge) In order to use socket.io you need to force it to fallback to an xhr long-polling approach.