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 athentification, token based authentificatio, OAuth, … The problem arrives when we add WebSocket server.

He mentions another solution - sharing an authentication mechanism between the frontend and backaned - but suggests something simpler using the bi-directional nature of websockets. To illustrate, he makes a simple Silex application and creates a basic template that makes the websocket request back to the localhost. He includes the simple code to make the socket.io server (node.js) and an example of using Express to handle the request and define the URL to call on the Silex application. He's also created a screencast showing the full process, start to finish.

Currently I am building an application where we can fill in live scores and I needed something to update all my visitors whenever a score has been updated by one of the admins. Whenever an admin updates the score via the Laravel 4 backend I fire an event and publish it to Redis. I’ve setup a simple NodeJS server which listens to Redis for incoming changes. NodeJS will redirect the message to all Socket.IO clients.

The post has all of the code and configuration you'll need to reproduce the setup. This includes the Laravel Redis config, code for the event handler and the Node server listening for the socket connection.

Zend Framework which is PHP based and Node.js which is JavaScript based don’t have a common connection to pass data in a bi-directional nature. I was tasked with building a bridge of sorts that would utilize existing information from Zend Framework with the latest release of Socket.io’s authorization mechanisms. (If you don’t do this then arbitrary connections can happen and will be authorized.)

He starts with the code (on the Node.js side) to create a simple HTTP server to listen for the requests from the Zend Framework application. He gets into the details of how that all works before moving to the other side - a simple update to the authentication to store a session cookie with the information that is passed, via Socket.io to the waiting Node.js server for handling.