In a new post to his site Freek Van der Herten shares some code he's worked up to validate SSL certificates in PHP to ensure they're correct when accessing a remote site.

With vanilla PHP it’s possible to check of if the SSL certificate of a given site is valid. But it’s kinda madness to do it.

He starts with the code required to do it including:

• using stream_socket_client to connect to the remote server
• getting the connection parameters with stream_context_get_params
• using openssl_x509_parse

..then on to parsing the certificate and its "valid time" timestamps. He stops it with the above steps, however, and advocates that you instead try out this package (one developed by him) to make the validation a two-line process. He also describes some of the other methods the package includes to get things like the issuer, domain and any additional domains it covers. Be aware that if you're planning on using it you'll need OpenSSL support in your PHP installation as it's required for the connection and validation.

In this post to his site Joe Ferguson takes a look at the recently announced Producer package that helps with ensuring your packages are "high quality" and makes the release process easier.

Producer is a pretty neat project that wants you to release higher quality packages. Well, actually (sorry) it’s “a command-line tool to validate, and then release, your PHP library package. It supports Git and Mercurial for version control, as well as Github, Gitlab, and Bitbucket for remote origins.”

[...] I was immediately interested in this tool because the Phergie project I manage (with other awesome developers) contains a number of individual packages. [...] Phergie packages are pretty solid. We have Travis CI running our tests across multiple PHP versions, we have hours and hours into these packages. But I wanted to take it to the next level, step up our game so to speak. In order to help raise our quality control on our packages I needed a producer.

He uses a Phergie plugin he developed as an example to try out Producer. He shows the results of the validate call with Producer and the few issues it reports. He shares the updates he made to the code (documentation) and the addition of a CHANGES.md file to the repository.He then uses Producer to push out a new version of the package using the release command (v3.0.1) and the resulting output of the command.

In this post to his site Paul Jones introduces a tool that aims to help you and your Composer-centric workflow, making it easier to validate and release packages for your projects: Producer.

Back when I was working on Solar, we needed a process to package up each release of the entire framework and make sure I hadn’t forgotten anything. [...] After Solar was done, we began extracting its individual components as 30 or so separate packages in Aura.

[...] But now I have started some non-Aura projects: Relay, Radar, Arbiter, Bookdown, and most recently Atlas. These projects do not have the benefit of the automated release process, with all of its checks and validation, that Aura does.

With that in mind, then, I have extracted a substantial amount of the Aura package release process into a new project, Producer, so that I can use it with any non-Aura library package. That means you can use it with your library package, too.

He goes on to talk about why you might want to use Producer in your workflow and its functionality for validating and releasing packages. He also answers some of the common questions he's gotten about the tool, mostly around the steps it takes during the validation/release process.

The Ibuildings blog has posted the latest part of their series looking at some general programming guidelines and principles that can help you in your own development work. In this latest article Matthias Noback talks about the "life and death of objects" in more detail including creating, updating and how they "die".

In the first part of this series we looked at ways to reduce the complexity of function bodies. The second part covered several strategies for reducing complexity even more, by getting rid of null in our code. In this article we'll zoom out a bit and look at how to properly organize the lifecycle of our objects, from creating them to changing them, letting them pass away and bringing them back from the dead.

He starts with a brief list of things that are true about objects (they live in memory, they hide implementation, etc) and some of the issues with poor object handling. He then gets into some of the basics: creating objects (meaningful & different ways), validating the input to constructors and methods and changing them to update properties and related objects. He also suggests preferring immutable objects and talks about value objects to help towards this goal. Finally he talks about the death of objects and some of the ways you can possibly "bring them back to life".

Joshua Thjissen has a post on his site that wants to help you understand the basics of Symfony2 forms including how to build them, extend them and the modules they're made up of.

To actually use Symfony2 forms, all you need to do is read some documentation, a few blog posts and you’ll be up and running in a couple of minutes. Understanding Symfony2 forms however, is a whole different ballgame. In order to understand a seemingly simple process of “adding fields to a form”, we must understand a lot of the basic foundation of the Symfony2 Form component. In these blog posts, I’ll try and give some more insights on this foundation.

He starts by explaining the three main steps in the typical form lifecycle: building the form itself, populating and validating data and rendering the form to the waiting user. He then gets into some of the basics of using forms and the types of objects that make them up. He includes examples of creating a simple form, the YAML configuration it compiles to and the functions used to build, render and set options on the form. He finishes up the post looking at form inheritance, extending the form types and where the "ResolvedFormType" comes in to play.

In a post to his site Rob Allen shows you how to help secure your Slim 3-based applications with the help of the slim3-csrf package. A CSRF (cross-site request forgery) attack happens when another site requests a page in your application, possibly performing an action.

In addition to the core Slim framework, we also ship a number of add-ons that are useful for specific types of problems. One of these is Slim-Csrf which provides CSRF protection. This is middleware that sets a token in the session for every request that you can then set as an hidden input field on a form. When the form is submitted, the middleware checks that the value in the form field matches the value stored in the session. If they match, then the all is okay, but if they don't then an error is raised.

He shows how to add the middleware to your Slim 3 application and how to add the token to each form. The library generates random values for both the name of the token and the value making it compatible with applications that may involve multiple browser windows. He also shows you how to validate the token, either using the built-in "Guard" handling or manually by deferring the check to the route.

Marc Aube has a new post to his site that introduces you to the specification design pattern, a technique that's useful for ensuing the current state of an object is valid.

The specification pattern is a software design pattern used to codify business rules that state something about an object. These simple predicates determine if an object's state satisfies a certain business criteria. They can then be combined to form composite specifications using logical operators. Use a specification to encapsulate a business rule which does not belong inside entities or value objects, but is applied to them.

He suggests a few things the pattern could be useful for like validating the current state or define how an object should be created. He gives a few more "real world" examples and then gets into the code to create a custom specification. In his "CustomerIsPremium" spec he defines a single method on an interface to determine if the Customer given is correct. He then creates a class instance and encapsulates the logic inside its "isSatisfiedBy" method. He also includes a bit more complex example, showing how to create a composite specification for handling grouping like "and", "or" and "not" assertions. Finally he looks at how to build specifications that can be passed in and used as selection criteria. He does point out that this can leak database handling into the specification layer, however, and should really be avoided without a inversion of control method in place.

Eric Barnes has a new post to his site showing you how to validate form input in a Laravel application using the form requests feature.

If you’ve used Laravel’s form validation for any length of time, then you know it’s a powerful system. It makes the tedious task of validation very simple while still keeping the door open for complex rules. In this tutorial, I want to show you a simple and easy way of validating forms that contain dynamic fields. A common use case for these types of forms is when you would like to allow a user to add more fields to a form.

His example uses a form with a handful of text fields rendered with a simple "for" loop in the template. He then helps you make a new Request instance (OrderRequest) and adding custom validation rules into its "rules" method. In this case, he sets a rule that the content is required and can be no longer than 255 characters. He also shows how to use the custom messages functionality, defining custom values for each of the form's fields.

Joshua Thijssen has a new post today with a "neat trick" that the Symfony Security component allows - switching (impersonating) another user programatically.

This allows you to login as another user, without supplying their password. Suppose a client of your application has a problem at a certain page which you want to investigate. Sometimes this is not possible under your own account, as you don’t have the same data as the user, so the issue might not even occur in your account. Instead of asking the password from the user itself, which is cumbersome, and not a very safe thing to begin with, you can use the switch-user feature.

He talks about how to enable it, how to use it to switch to another user and, most important, how to restrict its use. He points out that there's no way to define who a user can switch to built-in, so he's come up with a custom "switch listener" to help add in this protection. His "SwitchUserListener" class replicates some of the code in the original handling (well, the whole class) and updates the "attemptSwitchUser" method to check the user they're trying to switch to and see if they have the right role. Finally he shows how to add it to the services configuration and how it overrides the default listener.

Rob Allen has a quick post today showing how to use the ZendValidator component from Zend Framework 2 to handle JSON validation.

Let's say that you have an admin form where the user can enter JSON and you'd like to validate that the JSON parses before allowing the user to submit. To do this, you can use the rather excellent jsonlint project by Jordi Boggiano. Obviously, add it via Compser.

He starts with a quick example of using the "JsonParser" in isolation to validate a JSON string. Then he integrates it into the framework as a custom validator class (extending the AbstractValidator) and enabling the "isValid" call to be made and return a pass/fail result. You can find out more about the ZendValidator component in this page of the Zend Framework manual.