Security in Code Deployment – part 5: Patch with Composer and Deploy
Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment
This is part of “Security in Code Deployment” -series.
- Security in Code Deployment – part 1: Drush make file
- Security in Code Deployment – part 2: Patch modules with Drush
- Security in Code Deployment – part 3: Unknown Drupal codebase
- Security in Code Deployment – part 4: Advantages of using Composer
Composer is able to apply patches if you are using
drupal-composer/drupal-project or some other patching plugin for Composer (Listing 14).
LISTING 14: Composer Patching
"A patch with URL": "https://www.drupal.org/files/issues/ field_group-empty_group_nonnumeric_index-2761159-2-D8.patch",
"A local patch file, path relative to the composer.json file": "patches/field_group-fix_it.patch"
After you have added the patch files to the composer. json file, apply the changes and update the
$ composer install
$ composer update --lock
Currently with Drupal 8, all contrib modules and other resources must be added manually one by one. If you are creating a
composer.json file from a Drupal 7 site, you might benefit by using the Composer Generate module.
For codebase deployment, it is best to rely on a builder tool. Ideally, you commit only your custom code (e.g., modules and themes and a Drush make file or the
composer.lock files) to the project repository, with specific versions and, optionally, patching information. With proper versioning (think Git tags), you can test your next release’s code in development and staging environments and reduce the probability of reintroducing old or introducing new issues.
Web server configuration is very much related to deployment security, too. However, because it is too broad a topic to be covered here, just remember to make sure your server does not allow end users access to any files other than those they absolutely need. Patch files, Drupal core, and a module’s text files – especially
CHANGELOG.txt and build time
PATCHES.txt – are good examples of files that have no business being visible to the world. Even when most of the attacks against websites are automated, there is no reason to leave information about website internals in the open.