Security, Insights, and Results for your Drupal or WordPress Website - The Open Source for Business Solutions

Fred Hutchinson Cancer Research Center eagle-i Integration

John Locke — Mon, 01 Jan 2018 08:00:00 +0000

Fred Hutchinson Cancer Research Center eagle-i Integration

Additional Screenshots

John Locke Mon, 01/01/2018 - 00:00

University of Washington Center for Reinventing Public Education (CRPE)

Don Dill — Mon, 25 Dec 2017 20:56:12 +0000

University of Washington Center for Reinventing Public Education (CRPE)

Additional Screenshots

Don Dill Mon, 12/25/2017 - 12:56

Seattle Humane Society

Don Dill — Wed, 20 Dec 2017 21:16:54 +0000

Seattle Humane Society Don Dill Wed, 12/20/2017 - 13:16

Middle East Policy Council

Don Dill — Wed, 01 Nov 2017 19:48:15 +0000

Middle East Policy Council

Additional Screenshots

Don Dill Wed, 11/01/2017 - 12:48

American College for Healthcare Sciences (ACHS)

Don Dill — Sun, 15 Oct 2017 22:26:21 +0000

American College for Healthcare Sciences (ACHS) Don Dill Sun, 10/15/2017 - 15:26

Peninsula College and Athletics Sites

Don Dill — Mon, 02 Oct 2017 20:09:37 +0000

Peninsula College and Athletics Sites

Additional Screenshots

Don Dill Mon, 10/02/2017 - 13:09

Seattle Children's Alliance

Don Dill — Mon, 16 Jan 2017 02:06:47 +0000

Seattle Children's Alliance

Additional Screenshots

Don Dill Sun, 01/15/2017 - 18:06

Queen City Yacht Club

Don Dill — Sat, 16 Jul 2016 07:00:00 +0000

Queen City Yacht Club Don Dill Sat, 07/16/2016 - 00:00

Rate Limiting an aggressive bot in Nginx

John Locke — Tue, 22 Aug 2023 17:58:05 +0000

Rate Limiting an aggressive bot in Nginx John Locke Tue, 08/22/2023 - 10:58

High load isn't necessarily an emergency, but it may be a heads-up before a site noticeably slows down. Sometimes there are weird spikes that just go away, but sometimes this is an indication of a Denial of Service.

Rate Limiting

NGinx has rate limiting that can be used to handle cases where a slow URL is targeted. Today one of our sites had high load alerts. Here's how I handled it:

Check to see what was using the load. I logged into the server, and ran top, which immediately showed 7 - 8 PHP processes near the top of the list.
Check the responsible process's status. I went to the PHP status page we have in our Nginx config, and saw that all available processes were in use, and many of them had a /index.php?document-type=... path -- e.g. a search path with a lot of parameters.
Review the logs. Looking in the Nginx access_log, I found that the /search path was being hit 2 - 3 times per second, from multiple different IP addresses but all sharing the same user agent -- "Bytespider". This is a crawler from ByteDance (the company that owns TikTok).
Determine a plan. In this case, after figuring out that Bytespider had hit the search page 33K times in the previous 6 hours, and it was also loading all page-related assets, I decided this was not something to block entirely, but a good situation to use a rate limit.

Implementation

A couple searches gave me some good references/instructions on this: https://serverfault.com/questions/639671/nginx-how-to-limit..., https://theawesomegarage.com/blog/limit-bandwidth..., https://www.nginx.com/blog/rate-limiting-nginx/

In our normal Nginx configurations, any .conf file in /etc/nginx/conf.d/*.conf is included in the main "http" block, so I created a "limits.conf" file there for the 'limit_req_zone' directive:

map $http_user_agent $limit_bot {
  default "";
  ~*(Bytespider) $http_user_agent;
}

limit_req_zone $limit_bot zone=bots:10m rate=30r/m;

... I had to read up on the map and limit_req_zone to understand this -- a map creates a new variable, and the first arg to limit_req_zone skips applying the zone if the value of the variable is empty. So this map outputs the Bytespider user agent string, or nothing.

The limit_req_zone creates a zone named 'bots', allocating 10 MB of space to track variations (which is probably entirely unnecessary, we only have a single variation here!). And then each variation of the user agent passed in $limit_bot is limited to 30 requests per minute -- 1 every 2 seconds.

To actually apply this, I could add directly to the sites-enabled file for the site, but this does get reset by our configuration management system (Salt Stack) every day. So instead I created another file in /etc/nginx/includes/limit_search.conf . Files in includes need to be explicitly included to take effect, and we have a section in our Salt configuration to do this.

In this file, I applied the actual limit to the search path:

location ~ /search {
  limit_req zone=bots burst=4;
  limit_req_status 429;
  try_files $uri @rewrite;
}

... this applies the "bots" limit to the /search path, allowing at most 4 concurrently running instances before it sends an error.

By default it sends a 503 error -- but looking up status codes, I found that 429 is "Too many requests", meant for rate limiting, so I changed the error code to send that.

And finally, this location block was taking over the entire URL -- but doesn't exist on the disk, and so I had to add the try_files handler to get it handled by Drupal/PHP.

And then the only thing left was to add it to the site configuration, using the line:

include includes/limit_search.conf

... and the traffic and load immediately dropped back to normal levels:

Recovering from attacks

Page Load speeds

Eric A-M

Thanks a bunch for this! This works to rate limit bots across multiple IPs, which is better than the IP approach I was using previously.

You're awesome!

29 Sep, 2023

Add new comment

Deploying blocks and content to other site environments

John Locke — Sun, 16 Apr 2023 21:06:47 +0000

Deploying blocks and content to other site environments John Locke Sun, 04/16/2023 - 14:06

If you have a current Drupal site (built in Drupal 8 or later) you no longer need to entirely rebuild your site -- ever again. That doesn't mean it couldn't use a freshening up now and then.

We have several clients revamping their home pages, along with key landing pages. As part of this refresh, they are getting new designs in place, new messaging, new content. And they would like to launch the new design, and content, all at once.

While it's easy to deploy code and configuration changes from a development site to production, getting content up there is not so simple. Even posting a new block has long been a challenge -- if you add it on a dev site and push your configuration up, you get a "Broken or missing block" text on production, leading to deployment gyrations to get new content deployed smoothly.

For the past couple years, we've been using Fixed Block Content to get new blocks deployed, but that's proven to be finicky and inconsistent -- you have a lot of clicking to get actual content into an actual new block. And on one site if you make any changes, it blanks out the content when we deploy (largely due to a conflict from a custom module).

Two new modules to deploy content

So these may not be entirely new, but they are new to us: Structure Sync and Default Content. Both of these modules allow you to export content to code, and import it on other site environments. And they work entirely differently.

Both of these are very easy to use, and solve the basic problem of deploying content quickly and easily -- with a couple gotchas.

Keep content in sync with code - Structure Sync

First of all, Structure Sync allows you to export any custom blocks, taxonomy terms, or menu links on your site. This module uses its own configuration entities to store the content. If you want to sync all custom blocks, it's really easy:

> drush export:blocks
Exporting blocks...                                                                                                                                                                                  
 [notice] Custom blocks export started                                                                                                                                                               
 [notice] Exported "Homepage Hero"                                                                                                                                                                   
 [notice] Exported "Social block"                                                                                                                                                                    
 [notice] Exported "Explore Life & Legacy Feature"                                                                                                                                                   
 [notice] Exported "From Our Archives"                                                                                                                                                               
 [notice] Exported "Museum Exhibitions"                                                                                                                                                              
 [notice] Exported "Archive & Exhibit Feature"                                                                                                                                                       
 [notice] Exported "PYV Hero_L1"                                                                                                                                                                     
 [notice] Exported "Library Location_Google Map"                                                                                                                                                     
 [notice] Exported "Library Hours"                                                                                                                                                                   
 [notice] Exported "PYV_L1_Lead"     
 ...
 [notice] Custom blocks exported                                                                                                                                                                     
 [notice] Message: The custom blocks have been successfully exported.
   
> drush config:export
 [notice] Differences of the active config to the export directory:
+------------+---------------------+-----------+
| Collection | Config              | Operation |
+------------+---------------------+-----------+
|            | structure_sync.data | Create    |
+------------+---------------------+-----------+

 The .yml files in your export directory (../config/sync) will be deleted and replaced with the active config. (yes/no) [yes]:
 > 
 [success] Configuration successfully exported to ../config/drupal/sync.

... that's all there is to saving all your custom blocks. This process can handle taxonomy terms and menu items as well -- with an important caveat: it only saves the item itself, and not anything related to it -- images, media, other content referenced by an entity reference field.

Once you've exported your content, it gets stored in the Structured Sync data configuration -- but this does not automatically deploy your content. After you've gotten the configuration to your other environment, you still need to import the data.

> drush import:blocks
Importing blocks...

 What import style would you like?:
  [0] Full
  [1] Safe
  [2] Force
 >

... will import all blocks on the new environment, with 3 choices of how. Read the project page to decide which you want -- this module can update content of existing blocks, delete blocks that are not exported, or only import blocks that don't already exist.

The admin page for structure sync has even more options -- you can select individual blocks, menus, or vocabularies to export or import.

This is a great option for sites that need to deploy blocks or a new menu along with a fresh design!

Deploy rich content using Default Content

Default Content is entirely different -- it can deploy any content entity, not just blocks, menus and taxonomy. It's far more granular -- you export individual items, one at a time. This can include nodes, paragraphs, users, any kind of content entity.

This module was originally meant to create demo content for testing new websites, but it's useful for deploying new content as well, especially pages with paragraphs, images, and the like -- with the "Export References" option, when you point it at a single node, it will export all related entities at the same time!

For a simple, one-shot deployment of several pages, this is how we've done it:

Set content to be owned by user 1. (If you don't, it will export the author's user account, which currently throws an error on import if it already exists).
drush default-content:export-references node <nid> --folder=content to export a particular node, to a new directory called "content".
Add any other nodes/items you want to deploy.
Create a new custom module. e.g. drush generate my_new_content. You only need the .info.yml file.
Edit the info.yml file, adding a default_content block listing the entities to import grouped by entity type. Each entity is exported to a file named with its UUID -- this is what you need to add to the info file.
Move the content folder into the new module.

Example info.yml file:

name: New Pages
type: module
description: Default content for homepage, about, and leadership pages
package: Custom
core_version_requirement: ^9 || ^10
dependencies:
  - default_content:default_content

default_content:
  node:
    - 0ab700ab-89ff-48b3-af0b-786659fe7e0a
    - 2e4598da-23f2-411f-ada1-f4571b6fdbaa
    - fa4d9814-c290-431e-8fad-090b6c58f310

Now, when you deploy this module to the new environment, all you need to do is enable it, and your new content will get imported!

This successfully deploys paragraphs embedded in the content, as well as attached images. We have not (yet) tried this with images embedded in rich content, or layout builder, but I do see issues with patches available or fixes.

So far we've only used this to deploy new content, and as is, if you enable this module when any of the entities in it already exist, you will get SQL errors. However, it does look like there are patches that might make this a more robust solution for rolling out changes to existing content in addition to just deploying new content.

Which to use?

Both of these modules seem extremely useful, with different gotchas and quirks. One big benefit of Default Content is deploying content to entirely different sites. If the two sites have the same field structure, this makes it easy to move content around.

Some other miscellaneous notes:

Issue with a patch to prevent erroring out if an entity already exists.
Issue with a patch to manually import content without a module.
Add layout builder support.
Default Content Deploy module -- this looks like an alternative built around deployment, but looks related to an earlier version of default content. I'd love to hear more about whether this is a better fit, please comment below if you have hands on experience with these!

Integrations with other systems

DevOps