In a new post to his Medium.com site Adnan Sabanovic shows you how to combine Laravel and Socket.io to create in-application messaging.

Websockets are cool. They are really helpful if you want to show real time activities from your users (or perhaps some queue jobs). Now, if you are afraid of the word “Websockets”, don’t be. I will lay down the instructions on how you can use it and will be around to answer your questions if you need to.

I had this challenge where I needed it to show a list of people who are currently viewing a specific URL in Laravel. So I started thinking. Part of me wanted to do a quick hack (luckily that’s not the strongest side of mine), whilst the other wanted to build something cool, reusable and long-lasting.

While many recommend using the Pusher service, there's a way to replicate it locally using Socket.io and the Laravel Echo Server. He walks you through the process of getting a new Homestead box up and running, installing Redis and installing the Echo Server. After some configuration changes he shows the installation of the Socket.io client and laravel-echo interface. Example code is included showing how to send the broadcast messages and to listen for broadcasted messages.

In a follow up to his previous post about sharing authentication information between socket.io and PHP, Gonzalo Ayuso has posted an updated method using JSON Web Tokens instead.

I’ve written a previous post about Sharing authentication between socket.io and a PHP frontend but after publish the post a colleague (hi @mariotux) told me that I can use JSON Web Tokens (jwt) to do this. I had never used jwt before so I decided to study a little bit.

JWT are pretty straightforward. You only need to create the token and send it to the client. You don’t need to store this token within a database. Client can decode and validate it on its own.

He updates the code from the previous post, showing how to replace the HTTP basic authentication with the JWT functionality. He makes use of some simple JWT library handling to encode/decode the claims when the token is made a part of the request.

In a post to his site Gonzalo Ayuso shows you how to combine authentication between Socket.io and a PHP frontend running a simple Silex-based application.

Normally, when I work with websockets, my stack is a socket.io server and a Silex frontend. Protect a PHP frontend with one kind of authentication of another is pretty straightforward. But if we want to use websockets, we need to set up another server and if we protect our frontend we need to protect our websocket server too.

If our frontend is node too (express for example), sharing authentication is more easy but at this time we we want to use two different servers (a node server and a PHP server). I’ve written about it too but today we`ll see another solution.

He sets up a simple Silex application with three routes - the root (/), a login route and a "private" one requiring a user to be logged in. This last route makes the connection to the websocket server in the template. This connection sends the current session ID to the backend where it's verified with a simple Socket.io middleware. Sometimes the session ID cookie will be set as HttpOnly so he provides an alternative for that: a new endpoint just for getting the current session ID for the websocket request.

Gonzalo Ayuso has a new post today showing you how you can integrate websockets with a PHP application using a combination of Silex and socket.io, a javascript library specifically made to work with them.

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.

On VilkomenJuist.nl there's a recent post showing you how to create a real-time notification system with PHP using Laravel, NodeJs and Redis.

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.

Anthony Wlodarski has put together a new post to his blog talking about authenticating a Zend Framework app against Node.js with the help of the Socket.io component for handling credentials.

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.