The TutsPlus.com site has a new tutorial posted showing you how to create an OAuth2 server with Laravel and the help of the Passport library.

In this article, we’re going to explore how you could set up a fully fledged OAuth2 server in Laravel using the Laravel Passport library. We’ll go through the necessary server configurations along with a real-world example to demonstrate how you could consume OAuth2 APIs.

I assume that you’re familiar with the basic OAuth2 concepts and flow as we’re going to discuss them in the context of Laravel. In fact, the Laravel Passport library makes it pretty easy to quickly set up an OAuth2 server in your application. Thus, other third-party applications are able to consume APIs provided by your application.

The article is then divided up into the steps (code, configuration changes, and commands) required to get the system up and running:

• Installation of Passport (requires a Laravel app already installed)
• Changing the User model to add the "remember_token" field
• Setting up some demo resources
• Adding the middleware and routes to handle the requests

The tutorial then spends some time showing how to consume OAuth2 APIs and makes use of the Passport "client" to make some sample requests. Finally, it walks you through the whole process of the OAuth2 experience from a user perspective, including some code to manually make the connection from plain PHP.

Sergey Zhuk has posted the second part of his "fast web scraping" series that makes use of the ReactPHP package to perform the requests. In part one he laid some of the groundwork for the scraper and made a few requests. In this second part he improves on this basic script and how to throttle the requests so as to not overload the end server.

t is very convenient to have a single HTTP client which can be used to send as many HTTP requests as you want concurrently. But at the same time, a bad scraper which performs hundreds of concurrent requests per second can impact the performance of the site being scraped. Since the scrapers don’t drive any human traffic on the site and just affect the performance, some sites don’t like them and try to block their access. The easiest way to prevent being blocked is to crawl nicely with auto throttling the scraping speed (limiting the number of concurrent requests). The faster you scrap, the worse it is for everybody. The scraper should look like a human and perform requests accordingly. A good solution for throttling requests is a simple queue.

He shows how to integrate the clue/mq-react package into the current scraper to interface with a RabbitMQ instance and handle the reading of and writing to the queue. He includes the code needed to update the ReactPHP client. The mq-react package makes the update simple with the HTTP client reading from the queue instance rather than the array of URLs. One the queue is integrated, he then shows how to create a "parser" that can read in the HTML and extract only the wanted data using the DomCrawler component.

Cees-Jan Kiewiet has continued his series covering the use of RecoilPHP and ReactPHP with the second tutorial focusing on the creation of a Munin Node client.

In the previous post we've covered the basics of coroutines. In this post we're going to build a munin-node client specifically to fetch switch port traffic counters. During this post we not just write an munin-node client, we also deal with some domain logic. All code examples contain comments about what is going on and why. There is a lot of knowledge in those as well so be sure to read the comments.

He starts off by talking about his own use of the Munin system to consolidate and manage data from network switches. He then gets to the code, showing the installation of the required packages and some initial Promise setup. He then creates the basic skeleton of the Munin class and adds in the functionality to connect to the node, gather the details and fetching the list of open ports and values. Finally he puts it all together and includes a screencast of the resulting execution.

Sergey Zhuk has posted the latest part of his "Building a ReactPHP Memcache client" series to his site today. In this latest article, part four of the series, he focuses on unit testing the client as he's developed it so far.

This is the last article from the series about building from scratch a streaming Memcached PHP client for ReactPHP ecosystem. The library is already released and published, you can find it on GitHub. In the previous article, we have completely finished with the source code for async Memcached ReactPHP client. And now it’s time to start testing it.

He then walks through some of the steps to create the tests for the client, made a little more difficult by its asynchronous handling. He shows how to use Mockery to create tests that evaluate the results of the promises from the client, starting with a simple check on the return of a version call. The post goes on to show testing for other parts of the client and includes all of the code and commands you'll need to execute them in your own environment.

On the AWS Developer blog they've posted a new tutorial showing you how to use client-side encryption in the AWS PHP SDK for interactions with the AWS S3 service.

The AWS SDK for PHP released an S3EncryptionClient in version 3.38.0. With client-side encryption, data is encrypted and decrypted directly in your environment. This means that this data is encrypted before it’s transferred to Amazon S3, and you don’t rely on an external service to handle encryption for you.

The AWS SDK for PHP implements envelope encryption and uses OpenSSL for its encrypting and decrypting. The implementation is interoperable with other SDKs that match its feature support. It’s also compatible with the SDK’s promise-based asynchronous workflow.

The tutorial then walks you through the setup of a new S3EncryptionClient instance and how to use the putObject method to push the file contents up to S3 automagically using the encryption. It also includes a code example of pulling the file contents down and decrypting the contents via a getObject call.

Sergey Zhuk has posted the third part of his series covering the creation of a Memcached client using ReactPHP has the base and allowing for asynchronous operations. In this latest part of the series (part three) he focuses on emitting events for various actions/results in the client code.

In the previous article, we have faced with a problem: how to deal with a broken connection. Now, when the connection is closed all pending requests are rejected with the ConnectionClosedException. If we want to handle this situation we need to attach onRejected handlers to all promises because we can’t guess in advance which one will be the problem.

This [example] code already looks too complex, but also there is no way to find out if the connection was broken or we have manually close it. So, it becomes clear that we need a completely different approach.

He then shows how to make use of this event library to emit events at certain points in the client's state. He includes code examples showing how to use the emit method to throw the event focusing on handling when there's connection issues.

Sergey Zhuk has posted the second part of his series covering the creation of a ReactPHP-based memcached client for asynchronous cache handling. In part one he set up some of the basic structure of the client and got it to a working state. In this latest part he expands on that base and improved the error and connection handling to make it more robust.

In the previous article, we have created a simple streaming Memcached client for ReactPHP ecosystem. It can connect to Memcached server, execute commands and asynchronously return results. In this article we are going to implement some improvements: connection handling [and] errors handling.

He then goes through and makes changes to allow for correct handling of the connection closing where it can either be closed by an option you specify or a forced close from the server. On the error handling side he shows how to handle invalid commands (throwing a WrongCommandException) and a failed command, such as when the value couldn't be stored for one reason or another.

Sergey Zhuk has kicked off a series of posts to his site showing how to create a ReactPHP memcache client that can work as a streaming client for your PHP application rather than single get/set requests.

Before writing any code we should think about our future client’s API: how we are going to use it [and] what methods it is going to have.

The client is going to be used in ReactPHP asynchronous ecosystem, so I’m going to provide a promise-based interface for it (when methods return promises). Also, we are building a streaming client. Under the hood, we will open a socket connection and use it as a stream. The client itself will be a wrapper on this binary stream communication. That means that it is our job to manually parse Memcached protocol to write and read data with sockets. So, having all of this in mind, let’s start.

He then starts in on the development of the base for the client including the factor class that will create the client (connector) with the provided Loop instance. He includes an example of this in use to create the client and point it to a local memcache server. Next he creates the client class that will use the stream to send requests and a parser to work with the responses and resolve actions that need to be taken based on their contents.

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.

Phillip Shipley has written up a post for his site walking you through the process of using PHP to read from and write to Google Sheets via the Google Sheets API.

This past week I needed to be able to read some data from a Google Sheet and then update a column for each row after processing it. This sort of thing should be simple, Google is built on APIs and has client SDKs for just about every language. I’ve also integrated with several Google Admin APIs previously so I expected this to be a breeze. I was wrong.

I started out by reading the Quickstart for Sheets API with the PHP Client, but almost immediately I could tell it was not written for my use case. [...] My use case is to use a backend process to function as a service account and batch process data. So the whole API credentials process was wrong for me.

He tried a few different approaches and finally, after some guessing, discovered how to share a sheet with the email address for the application. He then includes the steps to follow to get this same setup configured for your application and the code (using the Google_Client) to read and write to the sheet.