Sergey Zhuk has a new post to his site showing how you can use ReactPHP's socket component to build a simple chat service as a server runing on a remote port.

In this article, we are going to build a simple chat server based on ReactPHP Socket Component. With this component, we can build simple async, streaming plaintext TCP/IP or a secure TLS socket server.

There are client and server sockets. The server is bound to a specific port number and just waits listening on this port. The client knows the host of the server and the port on which the server is listening. When the connection between server and client is established, the data exchange begins.

He then gets into the code required to make the server and add in some additional functionality. He starts by creating the server to listen for incoming connections and has it write back a simple message to prove it's working correctly. He then moves on to the code required for sending and receiving data. This initial version just echoes back what the user submits. He takes this an expands it out to start on the intiial steps of the chat system - creating the connection pool for multiple clients, storing usernames of those connected and using that information when transmitting a message to all clients connected.

Matt Stauffer has posted the eleventh part in his series looking at new features of the latest release of the Laravel framework (well, version 5.1). In this tutorial he shows you how to setup and configure the login throttling for your Laravel-based application with the help of the Laravel Throttle package.

Whether or not you know it, any login forms are likely to get a lot of automated login attempts. Most login forms don't stop an automated attack trying email after email, password after password, and since those aren't being logged, you might not even know it's happening.

The best solution to something like this is to halt a user from attempting logins after a certain number of failed attempts. This is called login throttling, or rate limiting. Graham Campbell wrote a great package called Laravel Throttle to address this in previous versions of Laravel, but in Laravel 5.1 Login throttling comes right out of the box.

He shows how to use the ThrottleTrait in your AuthController to have some of the "behind the scenes" work done for you. He shows you how to update your view to relay the possible error message back to the user (and includes a quick screencast of the result). He ends the post with a quick look at what the throttling functionality is doing under the covers: creating a temporary cache item based on username+IP address as a "lock" indicator. Finally, he points out two properties you can find on the auth controller to give a bit more detail on the current configuration: lockout time and max login attempts.

Jordi Boggiano has posted about a new feature in Composer, the popular dependency manager for PHP, around the handling of authentication information.

Up until today if you run a home-grown package repository serving private packages it was quite a pain to use with Composer. You did not have efficient way to password-protect the repository except by inlining the password in the composer.json or by typing the username/password every single time. With the merge of PR#1862 and some further improvements you can now remove credentials from your composer.json!

The new functionality allows for the external storage of the credentials in a file, either globally of in one relative to the repository. He also includes the command you can use to configure and set these username/password combinations and have them stored in the "auth.json" file.

Stephan Hochdörfer has shared a handy tip for the Composers users out there that may have to deal with username/password protected repositories as a part of your package install process. In his post he shows how to use a simple "expect" script to automatic the HTTP Basic Auth login.

A couple of months ago when we set-up our own internal Satis repository to host our custom Composer packages. We ran into an "unpleasant" issue with Composer that had this PR as an result. To sum things up: We are using HTTP Basic Auth to password-project our Satis repository. There was no way we could switch to an SSL client certificate to allow Composer to authenticate itself automatically without asking for a password. Asking for the password on a developer`s machine is no big thing, but it since we need an automated Composer run in our Jenkins environment, there was no way to set things up.

As Composer doesn't currently support this functionality, they had to find a way around it. They went with an expect script that is used to work with the prompts and send the username/password information when expected. He also points out that this could be useful for other situations and tools - like a Bower build.

Mike Purcell has a handy new post for the Symfony users out there wanting more flexibility with their sfGuardPlugin use in their application. He describes how you can use email instead of a username for working with the user information.

sfGuardPlugin is pretty awesome. It allows a symfony developer the ability to quickly implement a user login and access control system. However, there is an issue with respect to telling the plugin whether to use the username or the email column for validating user submitted input. After some Googling I found a few sites which forced sfGuardPlugin to use email rather than username, but only after quite a bit of work. What I am going to show will accomplish the same end goal, but with minor changes.

He starts with a look at the validator class, showing how the values are going to be passed to the backend. The plugin makes a call to a "retrieveByUsername" method to get the user's information, but his method overrides this...sort of. His method actually contains the query to fetch the user information by email instead. This is useful if you want to use the email address as a username for the site but still want to maintain data integrity on the user records (valid emails can then be used for auth and for sending messages).

On PHPBuilder.com there's a new article showing you how to create a dynamic username validator with the combination of PHP, MySQL and jQuery to do some of the front end work.

One of the easiest ways to streamline the registration process is by providing the user with real-time feedback regarding username availability. This is accomplished by monitoring the registration form's username field and immediately following the user's completion of this field, rather than waiting for the user to complete all fields and submit the form. Although a seemingly complex feature, it's actually easily accomplished thanks to the powerful jQuery library.

His scripts bases its checking on an "accounts" table that holds the username and password. The javascript (jQuery) handles the "blur" event on the username text field in the form and runs a check against a backend script to see if that username exists in the database (bound parameters used for helping to prevent SQL injections).

Adam Jensen has written up a new article today on how you can use the Zend_Auth component of the Zend Framework to authenticate your users in a few different ways based on a strategy selected.

For this example, we’re going to allow our users to authenticate in one of multiple ways: e.g., against a database table, against an LDAP server, or by OpenID [1]. Zend_Auth already provides the necessary authentication adapters, so what we’ll be concerned with here is how to implement all three systems without ending up in an FSUC situation.

He defines the code for the basic controller and a simple view that allows the user to select how they want to log in - email/password, username/password or OpenID. The model does all of the heavy lifting by letting the controller set the authentication type (strategy) and pulling in the correct Zend_Form instance along with its validation rules. Code is also included for the model and each of these.

Several sites have areas that have content protected behind a login making them difficult to pull into a script. Juozas Kaziukenas has created an option to help you past this hurdle - a PHP class (that uses cURL) that can POST the login data to the script and pull back the session ID.

But how you are going to do all this work with cookies and session id? Luckily, PHP has cURL extension which simplifies connecting to remote addresses, using cookies, staying in one session, POSTing data, etc. It’s really powerful library, which basically allows you to use all HTTP headers functionality. For secure pages crawling, I’ve created very simple Secure_Crawler class.

The class uses the built-in cURL functionality to send the POST information (in this case the username and password, but it can be easily changed for whatever the form requires) and provides a get() method to use for fetching other pages once you're connected.

On his web development blog, Joey has posted a new list of eight handy regular expressions you can use in your code for common validations.

Here are eight examples of practical PHP regular expressions and techniques that I've used over the past few years using Perl Compatible Regular Expressions. This guide goes over the eight different validation techniques and describes briefly how they work. Usernames, telephone numbers, email addresses, and more.

Each of the regular expressions comes complete with an explanation of what it is and the kinds of strings it's looking for. Comments on the post have helped even more, finding places where they might break or not catch all possibilities.

On his web development blog, Joey has posted a new list of eight handy regular expressions you can use in your code for common validations.

Here are eight examples of practical PHP regular expressions and techniques that I've used over the past few years using Perl Compatible Regular Expressions. This guide goes over the eight different validation techniques and describes briefly how they work. Usernames, telephone numbers, email addresses, and more.

Each of the regular expressions comes complete with an explanation of what it is and the kinds of strings it's looking for. Comments on the post have helped even more, finding places where they might break or not catch all possibilities.