Articles

Naming things is hard^{[citation needed]} and there are a lot of things that you can name when configuring a Drupal site. Picking the right machine names for the different parts of Drupal can make your life easy in the long run. Changing labels is simply a case of tweaking the label in the interface, or through configuration updates. The issue is that once you decide on a machine name for something in Drupal it's pretty much set in stone forever.

The machine names you pick are often used in database tables, paths, interface elements and pretty much anywhere it is used. Changing entity or field machine names at a later date is difficult and can mean writing complex code or using migrations to achieve.

I have previously talked about configuring a Drupal site to authenticate against a remote SimpleSAMLphp install, but as Drupal is an excellent user management system I wanted to turn it around and use Drupal as the identity provider. This means that Drupal would allow users to log into other systems using their Drupal username and password by leveraging the power of SimpleSAMLphp.

This can be accomplished by wrapping the Drupal site and SimpleSAMLphp together along with a couple of modules to power the communication between the two systems.

The same terms apply as I described in the previous post, but to reiterate their meaning in this context I will go over them again.

I have previously talked about installing SimpleSAMLphp using composer, so the next step is setting up the system to actually provide authentication against a SimpleSAMLphp system. As I spend a lot of time using Drupal I wanted to set up the authentication with Drupal and SimpleSAMLphp in order to see how things worked.

First, let's define a couple of terms that are important to this setup.

SP - Service Provider - This is the system that users are trying to log into, which in this setup is Drupal. The Drupal site is providing a 'service' and as such users want to authenticate with it. Service providers will generally create a local user to track the user within the site, although that's not always the case.

Security Assertion Markup Language (SAML) is a standard that passes authentication credentials between hosts and essentially allows for a single sign on solution to be created. The standard uses XML files that get passed between the authentication system (known as the identity provider or IdP) and the service users want to sign into (known as the service provider or SP). 

SimpleSAMLphp is an open source application that implements SAML mechanisms and allows for the authentication system to be created as well as some administration tasks to be performed. The system is robust and battle tested, having been integral to the open source authentication systems for a number of years.

The events system in Drupal 9 allows for different parts of the system to communicate in an object-oriented manner. During the normal processing of a page, Drupal will trigger events that components will subscribe to in order to perform actions. The events system is built upon the Symfony event dispatcher component, which is an implementation of the mediator design pattern.

The mediator design pattern is a way for objects to communicate with each other through a mediator object (hence the name). The idea being that the different parts of the events system are never directly linked. This reduces the dependencies that objects have and allows parts of the application to be decoupled. Events are useful in a large and modular application like Drupal as it allows different parts of the application to work together without having to explicitly reference the objects involved.

I've been building Drupal forms for a number of years so I'm quite familiar with to putting together a Drupal form using the FormBase class and the form API. When I attempted to create a GET form this week I realised that there is actually quite a bit to think about. All forms are built using GET requests, it's the submission that I am specifically talking about. By default, forms in Drupal use POST requests to submit their data, and although it is possible to convert a form to use GET to submit data, it isn't well documented.

There are a couple of GET forms already available in Drupal. If you look at the Views filter form or the Search form they both process submissions through a GET request. These forms tend to use a combination of a form, a hook and a controller to manage their rendering and results. What I wanted was an example of a GET form that was more self contained inside a Drupal form object.

If you run a Drupal site for any length of time you will quickly realise that a few paths that have nothing to do with Drupal will receive a lot of traffic. All of these paths result in page not found errors so the only impact is taking up your server resources. It's common to see paths like wp-login, xmlrpc.php, phpBB/page_header.php, postnuke/article.php, as well as a multitude of others. These requests are clearly bots probing the site to see what sort of CMS is in use and if they can exploit it or not.

It's a bit of a shame that the internet is like this, but it's just one of the things you need to be aware of when managing a website. Users, and more often, bots, will continuously probe your site and servers for exploits. This is why you need to have firewalls and ensure your software is up to date as people are only too willing to crack your site and expose your data.

Drupal configuration is normally changed or removed through the configuration import and export process. For example, the process I follow is to make the change in the configuration locally, export the configuration into the source code, deploy the source code to a remote server and import the configuration. Using this mechanism, configuration changes that were exported locally are imported into the site and are ready to use.

There are certain situations where using update hooks to update the configuration is necessary. This means that you would change the configuration in your system directly using code in update hooks, rather than following the export and import process. These situations are rare, but necessary from time to time in order to maintain a consistent configuration on your site.

I recently acquired a Vissles V84 mechanical keyboard and I have spent some time giving it a go. Vissles was founded in 2018 and have a selection of decent looking accessories and devices including wireless chargers, headphones and monitors. The V84 is the second of keyboard that Vissles have created, iterating on the previous design.

The keyboard itself has 84 keys and is a 75% ANSI layout, this is also called tenkeyless as it is a normal keyboard without the keypad. This keyboard moves a few of the keys around in order to fill the entire surface of the board with keys, rather than separate out the arrow and home/end keys. The compact design gives the keyboard a slim look, but it doesn't feel cramped or small to use.

When copying a database from your production environment to your dev or local setup you should probably be sanitising it. This means to remove all user identifiable information from the database. You would assume that this means removing passwords and email addresses, but it also includes any fields you might have added to the user that might contain information. Things like name, address, company or even gender should all be sanitised.

Sanitisation is important from a data security point of view as you do not want any user data leaking out from your development (or testing) platforms. You want your users to have confidence in your abilities to protect their data and sanitisation allows you to keep their user data only on your production environment (and any production backups).

If you are using Drupal 9 and Drush then you can sanitise your data easily using the sql:sanitize command. This comes with Drush and should be available out of the box.