WebSockets are great. We can start a persistent connection from our browser to our server and use this connection to send real time notifications to our users. Normally when we integrate WebSockets with an existing Web application, we need to face with one slight problem. Our Web application runs on a Web server (imagine, for example one Silex application). We can use a login form and ensure all requests are authorized (using a security layer). This problem is solved years ago. We can use Basic HTTP authentification, Digtest authentification, a session based authentication, token based authentificatio, OAuth, … The problem arrives when we add WebSocket server. WebSocket server is another serve. We can use node.js, ruby, or even PHP with Rachet. But how we can ensure that WebSocket server’s requests are also authenticated? We can try to share our authentification provider between both servers, but this solution is quite “exotic”. That was the idea behind my blog post: post some time ago. I’ve been thinkin a lot about it, and also read posts and speak with colleages about this subject. Finally I’m using the following solution. Let me explain it.
Websockets are bi-directional. We can get messages in the browser and send them from browser to server. Basically the solution is to disable the messages from the browser to the server via WebSockets. In fact HTML5 provides another tool to do that called Server Side Events (aka SSE), but SSE aren’t as widely used as WebSockets. Because of that I preffer to use WebSockets (without using the browser-to-server chanel) instead of SSE.
Let’s create a simple Silex application:
class Application extends Silex\Application
{
use Silex\Application\TwigTrait;
}
$app = new Application();
$app->register(new Silex\Provider\TwigServiceProvider(), array(
'twig.path' => __DIR__ . '/../views',
));
$app->get('/', function () use ($app) {
return $app->render('home.twig');
});
$app->run();
And our main template with html file
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<script src="//localhost:8080/socket.io/socket.io.js"></script>
<script>
var socket = io.connect('//localhost:8080');
socket.on('id1', function (data) {
console.log("mensage from websocket: " + data);
});
</script>
</body>
</html>
Now we have Silex application that connects to a WebSockets server. I will use socket.io to build the WebSocket server:
var CONF = {
IO: {HOST: '0.0.0.0', PORT: 8080}
},
io = require('socket.io').listen(CONF.IO.PORT, CONF.IO.HOST);
Whit this ultra minimal configuration we can connect from Silex application to WebSocket server and our web application will listen to messages marked as’id1′ from the WebSocket server but, how can we do to send messages? As I said before we only rely on Silex application (in this example there isn’t any security layer, but we can use our custom login). The trick is to create a new server within our node.js server. Start this server at localhost and perform a curl request from our Silex Application to our node.js server to send the WebSockets push notifications. The idea is:
- User clicks a link in our html (generated by our Silex application)
- This request is a standard Silex request (using our security layer)
- Then Silex performs a curl request to node.js server.
- If our Silex application and node.js application are in the same server we will create a new server at localhost. In this example we are going to use Express to do that.
- Express server will handle requests from our Silex application (not from any other host) and will send WebSocket messages
Now our node.js application will change to
var CONF = {
IO: {HOST: '0.0.0.0', PORT: 8080},
EXPRESS: {HOST: 'localhost', PORT: 26300}
},
io = require('socket.io').listen(CONF.IO.PORT, CONF.IO.HOST),
app = require('express')();
app.get('/emit/:id/:message', function (req, res) {
io.sockets.emit(req.params.id, req.params.message);
res.json('OK');
});
app.listen(CONF.EXPRESS.PORT, CONF.EXPRESS.HOST);
And our html template will change to (I will use Zepto to perform AJAX requests):
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<ul>
<li><a href="#" onclick="emit('id1', 'hello')">emit('id1', 'hello')</a></li>
<li><a href="#" onclick="emit('id1', 'bye')">emit('id1', 'bye')</a></li>
</ul>
<script src="//localhost:8080/socket.io/socket.io.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/zepto/1.1.1/zepto.min.js"></script>
<script>
var socket = io.connect('//localhost:8080');
socket.on('id1', function (data) {
console.log("mensage from websocket: " + data);
});
function emit(id, message) {
$.get('/emit/' + id + '/' + message);
}
</script>
</body>
</html>
Now we need to add another route to our Silex application
use Symfony\Component\HttpFoundation\Response;
$app->get('/emit/{id}/{message}', function ($id, $message) use ($app) {
$s = curl_init();
curl_setopt($s, CURLOPT_URL, "http://localhost:26300/emit/{$id}/{$message}");
curl_setopt($s, CURLOPT_RETURNTRANSFER, true);
$content = curl_exec($s);
$status = curl_getinfo($s, CURLINFO_HTTP_CODE);
curl_close($s);
return new Response($content, $status);
});
And that’s all. Our Request from Silex arrives to WebSocket emmiter using a “secure” layer. OK, now you can said: yes, but anybody can connect to the WebSocket server and listen to ‘id1’ chanel, without any restriction. Yes, it’s true. But here you can use different solutions to ensure privacy. For example you can use a “non-obvious” chanel name based on cryptografic funcions. It’s not 100% secure, but it’s the same security layer than the standard session based security mechanism. If we know the cookie name we can perform a session hijacking attack and gain access to secure areas (without knowing the login credentials). We can generate chanel names like this: 7265cfe8fe3daa4c5069d609a0312dd2 with our Silex Application and send to the browser with an AJAX request.
I’ve created an small screencast to see the prototype in action. (source code in my github account)
In the screencast we can see how to install the prototype from github, install PHP’s vendors and the node js modules. We also can see how websocket works with two browser instances, and how to send messages directly accesing to Express application using localhost interface (and an error when I try to reach to Express server using a different network interface)
What do you think? Do you have another solution?
Gonzalo Ayuso - Web Architect 
Hmm. In my case, we had API application and for realtime tasks we used node.js. Client authorized via OAuth portocol. For connection with node.js client sent the API token. We validated the token and if it invalid we closed connect with client
The idea is the same. In my example, instead of validate the token in the node.js application, I force to send requests througt the API server (with my auth system) and then the API server sends the request to the node.js server (and node.js relies on this connections). I use this system because my auth system is slightly complicated (not OAuth) and I don’t want to implement it again in node.js
I think what he’s saying is to do the authentication in the PHP Application and generate an API token. Store that token in your database or wherever. Then when the websocket server fires up, give it that token and have it send the token to the socket server. The socket server checks the DB for that token and if they match, it allows traffic. If they don’t it disallows it. Then you’ve only done your auth once in the PHP application but both servers use the result.
Am I crazy?
If you’re using Silex and Websocket, now there is Sandstone: https://eole-io.github.io/sandstone/
Sounds good. I’ll check it. I also need to play with http://wamp-proto.org/