On the Laravel News site there's a tutorial showing you how to use a feature that's been added in the latest release of the Laravel framework: signed routes. These signed routes allow you to create routes that work with signatures and help with their validation.

In the latest Laravel 5.6.12 Release a new signed URLs feature was introduced. In this article, we’ll work on enabling signed URLs in an application and look at a few options of how to use them.

The tutorial starts by helping you update your installation to the latest version and change the configuration to add the new ValidateSignature middleware to the route middleware list. They also provide an example of a route definition that contains several "id" type of values that could potentially be modified by an attacker. It then shows how to use the Url helper to generate a new signed route that includes a signature based on the URL contents. The tutorial also provides an example of temporary URL signatures that will include a timeout value as a part of the hash so it will expire after a certain amount of time.

Rob Allen has a new post to his site sharing the work he's done to get PHPUnit managed with Phive, an "installation and verification environment" that is used in the installation of Phar archives.

I recently came across the Phive project and have had a play with it. Phive is part of phar.io and is intended to manage development tools such as PHPUnit in preference to using Composer's dev dependencies. The main advantages of Phive are that it uses the phar file of the tool and only keeps one copy of each version rather than downloading a new copy into each project.

He starts off talking briefly about how the tool works and what it's doing behind the scenes to download the phar archives requested. He shows how to define a target directory, install for global use and explains how GPG signatures work into the installation process.

On the Paragon Initiative site they've posted a new tutorial sharing a method for creating "one login to rule them all" for your PHP-based applications. The goal is to make one system that can provides a single authentication point and secure credential storage.

Problem: You want to create a system whereby when a user authenticates to example.com, they're also automatically logged in at foo.com, bar.com, baz.com, and any other domains that you decide to add to the list at a later date. Okay, great, that seems straightforward, except there's a complication: The Same Origin Policy prevents you from getting/setting cookies on domains other than the one you control.

[...] Let's narrow it down a little bit further: Unlike a situation where e.g. "Login with Facebook" would be appropriate, you control all of the domains. They just happen to be different, so the Same Origin Policy kicks in. For simplicity, feel free to assume they're on the same server and application codebase, but you have a multi-site architecture in place where some of the sites have a different domain name.

Let's work around this limitation with as few moving parts as possible.

He then shoes how to use libsodium (via the Halite wrapper) to secure your credentials (passwords) and hooking it into a custom API endpoint that takes in a hex-encoded JSON string and a signature for the payload. He then expands this to provide "automatic login" handling making use of another endpoint to fetch an image to and log in the user by passing it the payload and signature values. He ends the post with a few security concerns around using this method and some things that it assumes are correct (and robust enough).

Pádraic Brady has a new post sharing some of his ideas around PHP package signing and a few possible ways to approach (and possibly solve) the problem.

We figured out how to write good code. We figured out how to write good code in a reusable way...for the most part. We figured out how to distribute and mix all that good reusable code in a sensible fashion. Can we now figure out how to do it all securely? [...] The problem with package signing from my perspective is tied up in a phrase most of you would know: The needs of the many outweigh the needs of the few. Thank you, Spock.

He compares two different alternatives, Public-key infrastructure (PKI) vs (Pretty Good Privacy) GPG, and how the idea of trust fits into the picture. He also points out an unfortunate fact when it comes to the initial adoption of package signing methods - people are lazy (and cheap). They want to get things done and not have extra steps. Signing their packages would be one of these steps. He suggests an alternative, though, using double signatures to verify the integrity and validity of its contents. He also talks about the role that metadata plays in the overall package ecosystem and how signing it as well could be part of the solution.

Jerermy Kendall has written up a post for his site showing the use of his QueryAuth library for API authentication, complete with plenty of examples. The library makes it simple to sign and verify requests based on a key, secret and parameters given.

Most APIs require some sort of query authentication: a method of signing API requests with an API key and signature. The signature is usually generated using a shared secret. When you’re consuming an API, there are (hopefully) easy to follow steps to create signatures. When you’re writing your own API, you have to whip up both server-side signature validation and a client-side signature creation strategy. Query Auth endeavors to handle both of those tasks; signature creation and signature validation.

He includes code examples showing how to create a signed request, validate the signature from an incoming request and generate randomized keys and secrets. He's also created a sample implementation as a Vagrant box that sets up a Slim framework based application and uses Guzzle to make requests. He briefly looks at some of the code that makes it work and what the raw HTTP request and response look like for the result.

In this recent post to his blog Mike Purcell shares a method he found to discover the parameters required by a method in a class' parent via reflection.

According to PHP docs regarding the Memcached::get() method, there are three arguments which which must be added to my extended signature, which I added, but kept getting “...should be compatible with that of Memcached::get()” errors. I tried looking for the method signature via source code but didn’t glean anything useful from the PECL documentation, so I turned to PHP's RelectionClass.

He includes a quick snippet of code showing how the check works and the handy output it produces - a set containing the parameter name, if it's require or optional and it's definition.

In this new post to his blog Sameer Borate applies an interesting method of discovery of structure in unfamiliar code - generating code signatures.

One method [Ward Cunningham] suggests is that of summarizing on a single line select punctuation characters from each source file. He calls this the file’s "signature". This will help the developer gauge the complexity of the code base.

He includes a few examples from files in WordPress - looking for the structure of curly braces and semicolons as delimiters for chunks of functionality. Included are a few lines of code to help you generate a signature from any file and an example of a result. It's an interesting idea, but I'm not sure how practical it is. It could be a helpful reference for how complicated the file is, though.

DevShed has posted the third part of their series looking at the creation of dynamic twitter signatures. These signatures are the sort of badges you'd see on a site with the user's latest tweet and their photo.

In the third installment in this series, I will be demonstrating how to add proper object-oriented error handling to the SignatureImage class.

They've built up the class to take in a twitter username and, via a cURL request pull in both the account's avatar and latest tweets. If something goes wrong, though, the class needs to be modified to handle it. They show how to add in try/catch handling with an error handler method in the class to work with the error's result.

In this second part of their "dynamic twitter signature" series DevShed expands on the previous part and adds in code to work with the GD libraries to make the image.

In my last article we began putting together a solution that will allow us to display dynamic Twitter signature images in forum posts and emails. In this article we’ll continue where we left off by adding the functions that will harness the power of GD to create the actual image.

They review the previous code - a simple class that makes a request to the twitter servers for the latest statuses from the user - and adds on the fetching of the user's avatar and to push the text content into the generated image.

This new tutorial from the PHPFreaks.com website shows how to add text into a custom created image (they go with an Arial font in a PNG image).

One of the standard features of a message board is allowing members to have a signature, which is appended to the bottom of each post they make. Posters can put whatever they want into the signature (within forum settings). Putting quotes in one's signature is one of the more popular things to do. [...] Soon afterwards, I started receiving messages on a fairly regular basis asking me "What kind of sorcery is this?? How do I do that??" You know, I think it's kind of funny people should ask, because this is really nothing new.

His code (the full script is here) sets up the font size, the font face (Arial) and the quotes to be randomly pulled from first. The image manipulation comes next - making a PNG resource, adding a few colors and shapes, and dropping in the text.

Each line of the code is covered in detail so you'll understand exactly what's going on. The end result is a script that makes a simple image and can be easily expanded to work with other sources (like databases or flat text files).