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.

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.

Picture the scene, it's 2010, you're a young web developer working in a satellite office of a fast paced digital agency. The work is interesting, but normally quite stressful as there are tight deadlines and high expectations on delivering good work. There is a lot going on so you tend to finish one website and jump onto the next. The company you work for has a history of firing people and making people redundant, especially in the satellite office you work at. Low morale, a culture of blame, and absolutely zero investment in people means that there is very little enthusiasm for the work from anyone. The economy is still recovering from the collapse of the banking system from a couple of years before. You have a young family at home and so you'll put up with a lot of poor working conditions to ensure a pay cheque every month.

I have been using Git for a number of years and I can remember feeling quite daunted at the complexity of some of the commands I saw on the internet. When I started using Git on a daily basis I soon realised that the basics were quite simple and the complexity only lay further down the road with commands like cherry-pick or rebase.

Whilst Git does sometimes make me scratch my head, it is never as bad as the days of SVN where I would have a notepad of 'fix' commands that I would copy and paste into my terminal to solve random problems. I usually didn't even know what the problems were, just that this command fixed things so I could continue on and not lose work.

Drupal Views is a powerful module. The ability to generate lists of things in Drupal means that it is used everywhere. It even has a powerful plugin system that allows other modules to interface with it and create more functionality.

With multilingual sites there is a common issue I come across quite a lot that is quite easy to fix. A View will be created (usually via the Views wizard) that is intended to list a type of content. When an item of content is translated the content is duplicated in the View and you end up with a single list containing both translations of a single content item.

The Luhn algorithm was created by Hans Peter Luhn and is a way of creating a simple checksum for a number. This algorithm, also known as the mod 10 algorithm, is used in a wide variety of applications but is commonly associated with credit card numbers.

If you look at the numbers on the front of your credit card the last digit on the right is the checksum. An algorithm is done on the other numbers and if the checksum is the same then the number is considered valid.

Outside of credit card numbers, the Luhn algorithm can be used to create a checksum on any number that you want to store. It is especially handy when you want to give users a number that they will be hand typing into a computer. The checksum helps spot any errors in typing in the number before that number is processed. The good thing about the Luhn algorithm is that it doesn't matter how long the number is so it will work with any kind of digit sequence.