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.

On the Pineco.de site they've posted a tutorial for the Laravel users out there showing how to use the framework's "signed URL" functionality to create invite links for your application.

We can handle user invitations easily with the old and good database way. We create an invitation, store it with a unique token, then email it to the user. If the user uses the link, we can delete it from the database and that’s all. Now let’s give a try to Laravel’s signed URLs to handle a database-less solution.

The article starts by explaining what the "signed route" functionality is and how to generate then using the URL helper. It also shows how to use the "signed" middleware to validate the signature provided on the request. Finally, it shows how to configure, send and use the hashes to handle user registration.

Junior Grossi has posted a tutorial that covers the idea of data filtering with Eloquent models. In this case, the filtering is based on user input from a URL with parameters matching the properties on the model.

Filtering models was, for a very long time, a hard task for me. I admit that I could not think in some easy way to do that. I tried, refactored some code, created custom classes for that, but I never thought how this could be easily implemented.

Watching a Laracast’s video from 2016 about the Laravel’s Eloquent ORM I faced of with a bunch of classes and a trait that removed a lot of trash from my controller actions. That was called by Jeffrey Way the QueryFilter.

He then gets into some of the goals behind the filtering and the expected input method (URL parameters). He then creates a simple Laravel application making use of Corcel to integrate with his current WordPress backend database. He includes code examples showing the creation of a Post model and controller and returning only the desired fields using a JSON response and a toArray method. He then moves on to the filtering, starting with a more hard-coded version of the search: adding a where statement to the query manually before the get.

To replace this with something more flexible, he implements the QueryFilter class that can be extended to match the requirements for the model type. He then implements the PostFilter class, adding methods for "status" and "title" fields. Finally he adds in a scopeFilter method that makes it simpler to call the filtering directly from the model instance.

The Laravel News site has a quick tutorial posted showing you how you can use Eloquent functionality to help prepare your URLs and make them easier to maintain across the application. The key is in the use of "presenters".

It’s not uncommon to have tens, if not hundreds of views in a Laravel application. Something that soon gets out of hand is the various references to routes. [...] If for whatever reason we have to make a change to either the route alias or default query string values you’ll soon find yourself doing mass string replacements across your entire application which brings the risk of breakage within many files.

What can we do to possibly better handle this? There are a couple of different approaches.

They provide two approaches, one being slightly more complex (but flexible) than the other. The first makes use of only Eloquent to define a getUrlAttributes method in the model. The second method abstracts this functionality out to a "URL Presenter", a class that defines methods for each of the CRUD actions and returns the correct route for each. The getUrlAttribute then returns an instance of this instead, making it easy to reference the method and route required in the Blade template.

Sameer Borate has a new post to his site showing you how to create custom stream filters for use with the streams functionality already included in the PHP language. The streams handling provides a resource instance (filesystem, network connection, etc) that can be interacted with in a more standardized way.

In this post we will see how to create a custom stream filter. Streams, first introduced in PHP 4.3, provide an abstraction layer for file access. A number of different resources besides files – like network connections, compression protocols etc. can be regarded as “streams” of data which can be serially read and written to.

He shows how to get the current list of streams available and includes an example of one in use, the "string.strip_tags" filter. From there he shows the creation of a custom filter, one that replaces any URLs detected in a string with a string of [--URL--]. He includes the code for the filter and shows how to register it using the stream_filter_register function. He also includes an example of it in use, grabbing the contents of the BBC site and having the filter automatically applied.

On his Medium blog Peter Lafferty has written up a post showing you a method for HTTP request validation in Silex, the microframework from the creators of Symfony.

This article covers three validation scenarios: routes, query strings [and] POST with a JSON body.

He starts with a simple Silex application that creates a "RESTful" API with endpoints providing emojis back when queried (three endpoints). He then uses this to show how to validate:

• routes for their expected values in the URL
• using a ValidatorService provider to build a set of assertions (GET request)
• using the same service to create assertions for the JSON content of a POST request

All code required is included in the post including the correct handling of the emoji output via a UTF-8 JSON response handler.

The TutsPlus.com site has posted the next article in their "Programming with Yii2" series, this time focusing on the routing and URL creation in the application and how the requests get to the intended functionality (in controllers).

In today's tutorial, I'll review routing and URL creation in Yii. When a browser request arrives at your Yii application's index.php file, it must be parsed to determine which controller and method to call. That's routing. The reverse process of linking to parts of your application is URL creation, which is best done programmatically.

Yii provides a lot of flexibility in managing routing and generating links. Follow me as I review the basics.

He starts with a bit of background on the URL manager that comes built in to the Yii2 framework and how the routes are defined. He then starts in by defining some of the desired routes for the application and how to set them up in the main configuration file (including defaults). The tutorial also includes configuration examples of "pretty URLs", and outputting custom URLs using the "Url" helper.

In a post to his site today Ben Ramsey shares his response to a question about hypermedia in APIs and how they could make the API more brittle if used incorrectly.

One of the most common problems I see in API development is lack of hypermedia, or none at all. By hypermedia, I mean links that describe relationships among data in the API. When hypermedia isn’t used, the API becomes brittle, and those building clients that talk to the API are forced to code to URLs. The URLs become an important interface to the API, and if they change, they break everything. This leads to URL-based versioning schemes, and the only upgrade path for clients is to modify their code to accommodate the new versions.

He suggests that when APIs use hypermedia they tend to no longer rely on the URLs of the resources (as they're linked from the meta in other requests). He also shares the slides for a presentation he gave at this year's True North PHP Conference with more information on the topic.

In her latest post Alison Gianotto looks at a few different ways that you can validate any URLs that your users might give you to ensure they're not anything malicious. She looks at two of the major services, the Google SafeBrowsing API and SURBLs, as well as mentioning a few others.

If you write software for the web that allows users to submit or share URLs (comment systems, mail clients, forums, URL shorteners, etc), you may find yourself in a position where you need to filter out malicious links. Fortunately, there are several free options for you to better protect your systems and your users against bad guys, and they’re pretty simple to implement. (My examples are in PHP, but could easily be adapted to whatever language you prefer.)

She starts with an example call to the Google’s SafeBrowsing service, making a curl call and parsing the result. The other service, SURBL, makes use of DNS validation calls complete with code examples. She also talks about Phishtank and VirusTotal as other options. She finishes the post with a few suggestions for working with the rate limit restrictions on these services, including things like only checking on click-through and ensuring failure is handled well.

On PHPMaster.com there's a new tutorial posted showing you how to generate one-time use URLs that could be used for various things across an application, including things like account verification links.

A one-time URL is a specially crafted address that is valid for one use only. It’s usually provided to a user to gain privileged access to a file for a limited time or as part of a particular activity, such as user account validation. In this article I’ll show how to generate, implement, and expire one-time URLs.

Included in the post is the SQL to create a sample "pending_users" table that includes a "token" column for storing the generated hash. Code is also included for generating the hash and checking the incoming URL to see if it matches the requested user (and hasn't expired).

As a matter of general house keeping you could write a secondary script to keep expired tokens from accumulating in the database if a user never follows them. The script could be run periodically by an administrator, or preferably set up as a scheduled task or cron job and run automatically.