Michael Dyrynda has a post to his site sharing a method he's worked up for customizing the URL signing key that the Laravel framework uses to sign URLs to ensure the integrity of the URL's contents.

Since 5.6, Laravel has shipped with functionality to sign URLs. These URLs append a "signature" to the query string, so that Laravel can verify that the link has not been tampered with since it was created. This also allows you to generate temporary signed routes that expire after a configured period of time.

This is useful for things like verifying account emails, or enabling passwordless logins.

Passwordless logins is something that is quite useful for an application, but what if you wanted to be able to generate a signed URL in one application that would allow you to log in to a second application?

He starts by defining the use case, requiring multiple signing keys to be used, one for customer URLs and another for admin URLs accessing the same content. He makes this work through the use of a custom key resolver, pulling the key for the signing dynamically. He also shows how to update the passthrough authentication handling, allowing the administrators (staff) of the system to bypass normal authentication handling and more directly view the user's information.

The Laravel News site has published the latest part in a series covering the creation of a translation package for use in a Laravel-based application. In this new post they focus on how the package will handle missing translation keys.

In the last installment of this series, we talked about building the frontend translation management tool. In this article, we are going to move away from the frontend and follow the process of building another backend feature.

One of the most frustrating things about translation management in a Laravel application is forgetting to add translations to the corresponding language file. This has the undesirable result of either the translation key or the default language being rendered on the page rather than the translation for the current language.

To remediate this issue, they design the package so that it will search the whole project and return the keys that don't have translations currently defined. They walk you through the creation of this functionality complete with the configuration and code required to locate the missing translations and update the configuration to add them.

On the Laravel News site they've shown a spotlight on a new feature that's coming with the next major release of the PHP language (v7.3): outer array functions.

PHP 7.3 introduces two new array functions for working with the “outer” keys of an array. The RFC proposal included four new functions for both keys and values, but only the array key functions were accepted: array_key_first() and array_key_last().

[...] Although the outer array value functions were declined, at least new functions will be available for getting the outer keys of an array.

They then provide some code examples of this new functionality, showing how use these new functions to extract values. It also includes examples of the two functions - array_value_first and array_value_last - that were rejected from the RFC when voting happened.

On the Scotch.io site they've posted a new Laravel-related tutorial covering the use of the keygen package to generate random keys via four generator types. These keys can be used for just about anything in your application and can be customized to fit your length and complexity requirements. One thing to note, however, is that the strings it generates are random but should not be considered strong enough to use for actual encryption purposes.

When developing applications, it is usually common to see randomness come into play - and as a result, many programming languages have built-in random generation mechanisms.

[...] When your application is required to generate very simple random character sequences like those enumerated above, then the Keygen package is a good option to go for. Keygen is a PHP package for generating simple random character sequences of any desired length and it ships with four generators, namely: numeric, alphanumeric, token and bytes.

For their example they chose to create a simple REST API service that allows for user creation, viewing users and generating a random (temporary) password using the Keygen package. They start by helping you get the package installed (via Composer) and adding an alias to your Laravel config for "Keygen" to make it easier to access. They then create the user model and add in a "setEmailAttribute" method to verify the email value submitted (for format and uniqueness). Next up is the route definition for the "user" endpoints, creation of the API controller and implementing the Keygen tool to create a random eight digit code for the user. They also include a few strategies to ensure the code generated (and the resulting hash) is unique across all users. The reminder of the post shows the full user creation, and implementing the remaining methods required to view the user's details.

Adam Wathan has a new post to his site talking about mapping with collections and customizing the keys when injecting new data into your Laravel collections.

People often ask me, “how do I specify keys when I’m mapping a collection?”

It actually ends up being a pretty interesting topic, so I decided to cover it in a short screencast, as well as in written format below.

He shows how to translate a simple set of data into a much more slimmed down version. He points out that the "map" function could be used but it doesn't allow for setting keys. Instead he talks briefly about how the problem could be solved in Javascript (returning an object instead of an array) and how to use the "reduce" method to filter and reset the data as it goes through the array. He finishes out the post talking about learning from other languages, the "toAssoc" macro on Laravel collections and mapping the data back to an array with a custom macro.

On the SitePoint PHP blog today David Brumbaugh shows you how to encrypt large messages with phpseclib and asymmetric keys. phpseclib is a PHP library specifically designed to handle encryption and decryption in an easy-to-use way.

Most of us understand the need to encrypt sensitive data before transmitting it. Encryption is the process of translating plaintext (i.e. normal data) into ciphertext (i.e. secret data). During encryption, plaintext information is translated to ciphertext using a key and an algorithm. To read the data, the ciphertext must be decrypted (i.e. translated back to plaintext) using a key and an algorithm. [...] A core problem to be solved with any encryption algorithm is key distribution. How do you transmit keys to those who need them in order to establish secure communication? The solution to the problem depends on the nature of the keys and algorithms.

He talks some about the difference between symmetric and asymmetric algorithms and some advice about the selection of the right one (or ones) to use in your app. He also talks briefly about the problem with RSA keys, mostly that it has limits on the amount of text it can encrypt. His solution is to "encrypt the message with a symmetric key, then asymmetrically encrypt the key and attach it to the message". He explains the encryption/decryption process step by step and starts in showing the code to make phpseclib do the work. He shows how to generate the keys, build the encrypt function and the decrypt function with about 30 lines of code each.

In his latest post Stanislav Malyshev looks at a RFC he's proposed to allow array keys to be objects including some of his thoughts behind the proposal and how he sees it being helpful to the language.

I’m going to put to vote soon another of my RFCs, namely one about “objects as keys“. So, I want to outline the case for it here and address some criticisms and questions raised while discussing it.

He starts off by answering the "why" question, mentioning specially the introduction of things like GMP numbers and how, despite them seeming to work like numbers, other things can be done with them. He talks about how you'd use this functionality "the right way" and how that'd relate back to value objects. He answers a few other questions about the proposal including why it's better than just using __toString or spl_object_hash instead. He spends the rest of the post looking at some of the implementation problems, disadvantages and some of the possible names (function names) for the handling.

The WebLessons.info site has a new tutorial posted showing you how to use the LinkedIn authentication handling to allow your users to log in with their own account information.

LinkedIn is a business-oriented social networking service. It is mainly used for professional networking. So if you are having an application or website that serves working professionals then its very important for you to implement login with LinkedIn in your application. By this way you can able to access the data of your users like email, work history, education etc. So now let’s dive into the coding part.

They walk you through the various steps, providing screenshots or code where applicable:

• Creating a LinkedIn Application
• Get the API Key and Secret Key
• Create the database and set up the PHP configuration to connect
• finally, the PHP code for the login form and making the request to LinkedIn

A live demo can be found here (but if you're paranoid about your credentials, I wouldn't use it) and you can download all files included in the tutorial.

In a new post to his site Ulf Wendel shows an alternative use for the PHP Memcache functions - using them to query MySQL tables (InnoDB) in much the same way. He also tosses in Redis as another version to compare the performance against (for fetching key/value pairs).

PHP users can use two client protocols to query MySQL 5.6 and later. Not only standard SQL access but also faster key-value access to InnoDB tables is possible using the Memcache protocol. The MySQL benchmark team reports crazy figures. Of course, on hardware that makes the average PHP meetup visitor roll his eyes and say “yeah, Oracle, *yawn*…”. I’ve repeated my plain PHP benchmarks on an i3 desktop. And, I’ve added Redis to the game.

He goes through and compares a few different things with some simple benchmarks around operations per second:

• MySQL 5.6 Memcache vs. MySQL 5.7 Memcache vs. Memcache vs. SQL
• MySQL vs. Memcache vs. Redis

For each he's graphed out the results of the benchmarking with some surprising results for those that may thing MySQL isn't as suited as Redis for something like this.

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.