Nuxtstop

For all things nuxt.js

Security in Code Deployment - part 5: Patching with Composer and Deploy

#drupal #drush #composer #deployment
6 0

Part 5/5. The article was initially published in Drupal Watchdog 7.01, spring 2017.

Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment

Security in Code Deployment:

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

"extra": {
  "patches": {
    "drupal/field_group": {
      "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"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

After you have added the patch files to the composer. json file, apply the changes and update the composer.lock file:

$ composer install
$ composer update --lock
Enter fullscreen mode Exit fullscreen mode

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.

If you are interested in building your Drupal 8 projects with Composer, two good resources are Wolfgang Ziegler’s presentation from Drupal Iron Camp 2016 and the Composer documentation at Drupal.org.

Deployment Process

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.json and 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.

*Special thanks to Rami Järvinen for contributions to this blog post and to Anastasios Daskalopoulos and James Narraway for their help correcting my words to much better English.

Add comment