Rob Allen has posted a new tutorial to his site sharing how you can set up route specific configurations in Slim by setting it as a part of the route definition.

A friend emailed me recently asking about route specific configuration in Slim. He wants to be able to set properties when creating the route that he can pick up when the route is matched. The way to do this is using route arguments. I’ve written about route arguments before in the context of setting default values for a route parameter, but you can also use them to set new data for use later.

In this post, I’m going to look at how to use them for configuration data, such as setting required ACL permissions for routes.

He includes code snippets showing how to set the per-route data and how to access it from inside of the request handling via the Request instance. He shows an example of this both in the basic route definition and in middleware.

In a new post to his site Cees-Jan Kiewiet shares details about the latest version of the React/Cache component for the ReactPHP library. In the tutorial he covers the library, what this update brings with it and how he's making use of it.

Recently we, ReactPHP, released 0.5 of our cache package with TTL and other PSR-16 similarities. In this post we'll go over which packages I recently updated and how I am using them in my sites.

He breaks the post up into a few different sections showing the caching in use:

• JSON and msgpack
• Redis
• Fallback
• react/http session middleware
• react/http webroot preload middleware

For each item in the list there's a bit of code showing it in action and some explanation as to what it's doing and how it helps.

Dieter Stinglhamber has a new tutorial posted to his site showing you how to build a Laravel application that doesn't use cookies...well, any cookies that could be used for tracking.

Since May 25th you have been harassed by "We have updated our privacy policy" emails but also websites started to great you with "Please, let us and our 256 partners track you".

In response to these abusive practices, some developers have decided to follow a better path, removing every cookie that is not needed. For example, my website doesn't have a single cookie, Spatie new website won't have any either. [...] I encourage every developer to do the same and if you are using Laravel, here's how you can (very) easily get rid of the default cookies set by the framework.

He talks about the two cookies that are used by default in Laravel applications: the CSRF token and the session ID. He shares ways to remove each of these cookies (if you're not using them) and, for a final "trick", removing other cookie-related middleware from the "web" group that interact with cookies.

Christoph Rumpel has posted a guide for the Laravel users out there that have wanted to implement a Content Security Policy (CSP) in their application. A CSP helps to prevent cross-site scripting issues by locking down the images, scripts, resources, etc. that can be used in your application.

Caching is lovely, and the Content Security Policy is incredible. But when you put them together... Let me show you the problems I encountered, and how I fixed them.

He starts by describing the setup he was working with and improvements he was making (using the Spatie Laravel ResponseCache package to improve the performance of his site). As a part of the refactor he decided to implement a CSP but had an issue where the nonces on the included scripts didn't change like they did in development. To resolve the issue he created a middleware that takes the response and, after calling the other middleware, append the header to the response instance. Full code for the solution is included in the post.

On the Pineco.de site there's a new post that answers some of the frequently asked questions they've heard about APIs in Laravel-based applications.

Developing APIs are getting more and more popular, but still, it’s a bit blurry field for many developers. We collected some common questions and tried to answer them in one place.

Their list of questions includes:

• "What does RESTful mean?"
• "How does API authentication work?"
• "Why Laravel has a “web” and an “api ” middleware group?"
• "How can I test my APIs?"

For each there's a brief summary of the issue and links to other sources (documentation and packages) to help answer or fix the issue.

In a new post to his site Christoph Rumpel shares an introduction to the use of Content Security policies to prevent client-side security issues in your applications. While his examples are more Laravel-specific, the concepts can be applied to just about any framework or home-grown solution.

As more and more services get digital these days, security has become a significant aspect of every application. Especially when it comes to third-party code, it is tough to guarantee safety. But in general, XSS and Code Injection is a big problem these days. Content Security Policy provides another layer of security that helps to detect and protect different attacks. Today, I will introduce this concept and its main features, as well as show real-world examples.

He starts with a general look at web application security vulnerabilities and, more specifically, cross-site scripting issues. These are the ones that a Content Security Policy (CSP) can help prevent. He then covers the basics of the CSP header and gets into the implementation. In his example he sets up the addition of the CSP header as a middleware so that it's included on every request. With the default header all resources are blocked so he walks through the process of restoring access to the scripts, fonts and styles his blog needs to work correctly.

With the basics covered he then gets into a few more advanced features of CSP policies such as nonces for resource identification, iframe handling and the submission of forms. The post ends with a recommendation of the Laravel CSP package for use in Laravel applications. If you're looking for something more framework agnostic you might want to look into ParagonIE's CSP Builder library.

Cees-Jan Kiewiet is back with the latest tutorial in his series covering ReactPHP and RecoilPHP. In the previous parts he introduced some of the basic concepts and set up the first bits of code combining ReactPHP and RecoilPHP. In this latest tutorial (part three) he shows how to integrate this with a PSR-15 compliant middleware to evaluate response time.

There are more uses for coroutines than just making working with promises easier. In this post we're diving into the details on how they are used by the Friends of ReactPHP in the PSR-15 Middleware adapter for react/http.

When we started discussing how middleware for react/http should work we also look at the state of PSR-15 at the time. We decided against implementing it directly because of the fully blocking nature of PSR-15, in favour of callable. Which turned into an even better decision when return type hints where added to it to PSR-15. Now I love PSR-15, and middleware in general, which is why I created for/http-middleware-psr15-adapter to bridge the gap.

He starts with the code required to create a normal PSR-15 middleware and recreating the same functionality in a ReactPHP middleware. The article then shows how to use the package he developed to transform the middleware "on the fly" to enable it to be used both as a normal PSR-15 middleware and as a ReactPHP middleware. He ends the post with a word of caution and a bit of advice about using this method of rewriting - basically that just because you can doesn't mean you should.

On the Zend Framework blog today project lead Matthew Weier O'Phinney has posted an announcement about the latest (alpha) release of the Zend Expressive framework: Zend Expressive 3 Alpha 3.

Today, we pushed the final changes and fixes that culminated in the Expressive Installer and Skeleton 3.0.0alpha3 release!

The alpha releases have a ton of great features; keep reading to find out more!

The post then walks you through the installation process (slightly different since it's an alpha) and shows the creation of a sample middleware via the command line tooling. The tutorial then shows the creation of a request handler and how to configure it in the router. The post ends with a look ahead it what's next for the framework on its roadmap including several features that need completion before v3 of Zend Expressive can be called complete.

In a new post to his site Matthew Weier O'Phinney, lead developer on Zend Framework and representative in the PHP-FIG, covers the acceptance of PSR-15 by the group. PSR-15 relates to the creation of server request handlers and middleware that can use PSR-7 formatted messages.

Yesterday, following a unanimous vote from its Core Committee, PHP-FIG formally accepted the proposed PSR-15, HTTP Server Handlers standard.

This new standard defines interfaces for request handlers and middleware. These have enormous potential impact on the PHP ecosystem, as they provide standard mechanisms for writing HTTP-facing, server-side applications. Essentially, they pave the way for developers to create re-usable web components that will work in any application that works with PSR-15 middleware or request handlers!

He starts with a bit of background around the initial idea of the standard and some of the discussions that came up around it. The initial draft of the standard was modified to more correctly handle issues around response modification and the use of "handlers" for request/response manipulation. He then covers the final version of the standard, defined in the standard's documentation and enforceable via the psr/server-handler interface. Finally he covers how to use this to create re-usable middleware and an example using Expressive.

Sergey Zhuk has a new post to his site showing how to define and use middleware in your ReactPHP application.

What exactly is middleware? In real application when the request comes to the server it has to go through the different request handlers. For example, it could be authentication, validation, ACL, logger, caching and so on. Consider the request-response circle as an onion and when a request comes in, it has to go through the different layers of this onion, to get to the core. And every middleware is a layer of the onion.

He starts off with a simple example of a ReactPHP-based server that just responds to all requests with a "Hello world" message. I includes some logging functionality that he then refactors out into middleware. This logging records the HTTP method used, time of the request and the URL requested - all things the code can get from the request object. Code is included showing the refactoring out to the middleware and injecting it into the ReactPHP application. He then updates it to check for the existence of a file and, if so, returns the results as a stream. Finally he covers updates to the response inside the middleware, changing the HTTP status code and content returned based on the results of various checks.