DEV Community: Geoff

Controlling ESP32-C3 Super Mini Onboard LEDs

Geoff — Thu, 25 Sep 2025 21:52:44 +0000

I bought some ESP32 C3 Super Mini boards that have an RGB LED, and information for the onboard LEDs wasn't as easy to find as for the standard ESP32 dev board, so I wanted to consolidate my notes here.

Standard ESP32 dev boards often have a single LED driven by GPIO2. As a strapping pin it's pulled high by default, so the led will turn on when the board gets power and will stay on if the pin is not set low. With ESPHome, it's easy to setup the Status LED component which will turn off the LED after boot, and blink it if there is a warning or error.

status_led:
  pin:
    number: 2
    ignore_strapping_warning: True

For the C3 boards I purchased there is a basic LED and an addressable RGB LED, both connected to pin 8. During boot the RGB LED will flash then turn off, while the basic LED will remain on. Setting GPIO8 high or low will control the basic LED, so the status LED component can be used by configuring it to the correct pin, but the RGB LED will remain off.

The RGB light is a WS2812, and can be controlled with the ESP32 RMT LED Strip component which works with both the ESP-IDF and Arduino frameworks. The Arduino framework also has NeoPixelBus Light and FastLED components as options.

light:
  - platform: esp32_rmt_led_strip
    id: board_rgb_led
    pin:
      number: 8
      ignore_strapping_warning: True
    num_leds: 1
    chipset: WS2812
    rgb_order: GRB

It is not possible to control both LEDs by just enabling both light components and setting allow_other_uses for the pin.

The Status LED component can only be configured to a pin, so can't use the RGB LED. The Status LED Light component which enables controlling the LED when it's not being used to show a warning or error status can be configured to control a binary output component instead of a pin - a Template Binary Output component could use its write_action trigger to control the RGB light during a warning/error state ^[1].

Another option instead of using the status component is using on_loop with a custom lambda to check for an error state and adjust the RGB LED.

This is the definition I put together to slow blink yellow on warning, and fast blink red on error:

substitutions:
  status_pin: GPIO8

esphome:
  on_loop:
    then:
      lambda: |-
        static uint32_t last_state = 0;
        auto state = App.get_app_state() & STATUS_LED_MASK;
        if (state != last_state) {
          if (state & STATUS_LED_ERROR) {
            auto call = id(board_led).turn_on();
            call.set_brightness(.2);
            call.set_rgb(1, 0.01, 0.01);
            call.set_effect("fast-pulse");
            call.perform();
          } else if (state & STATUS_LED_WARNING) {
            auto call = id(board_led).turn_on();
            call.set_brightness(.2);
            call.set_rgb(1, 1, 0.01);
            call.set_effect("slow-pulse");
            call.perform();
          } else {
            auto call = id(board_led).turn_off();
            call.perform();
          }
          last_state = state;
        }

light:
  - platform: esp32_rmt_led_strip
    id: board_led
    pin:
      number: ${status_pin}
      ignore_strapping_warning: True
    num_leds: 1
    chipset: WS2812
    rgb_order: GRB
    effects:
      - pulse:
          name: "fast-pulse"
          update_interval: 0.3s
          transition_length: 0.3s
          min_brightness: 15% # Light turns off below 11%
          max_brightness: 50%
      - pulse:
          name: "slow-pulse"
          update_interval: 1s
          transition_length: 1s
          min_brightness: 15%
          max_brightness: 50%

With that definition in a separate file, I can easily include it for my projects running on C3 boards:

packages:
  - !include common/c3-rgb-status.yaml

There's an open PR to implement triggers for status changes, which would replace the need for on_loop

A Tier List of Drupalcon Swag T-shirts

Geoff — Tue, 06 Jun 2023 10:55:36 +0000

A staple of conference swag is the t-shirt, and some companies do it better than others. With Drupalcon Pittsburgh happening ~~soon~~ now¹, I thought I would shuffle through my t-shirt collection to rank some of the ones I've gotten at Drupalcons past.

Lullabot

Fun, whimsical designs
Probably won't be presumed as being a 'Bot while wearing these
Limited quantities, so I missed out on them some years 😔

A Tier

Four Kitchens

A fun play on the company name
Theme (usually) tied to the conference location
There was a good chance of both me and a former manager wearing the same one of these shirts on the same day

A Tier

Cheeky Monkey Media

A handful of funny or nerdy options were available
I'd wear the Drupal comm badge even through I'm not a Trekkie (though the graphic is a little too big), but the big slogan on the back takes this shirt out of something I'd wear in public
The fabric of this shirt does not spark joy
Not for me, but there's potential

B Tier

Acquia

DC LA shirt has small, unobtrusive design and logo - wouldn't hesitate to wear going about a normal day.
Slogans are not my thing, but I do like pink
Sizing on the slogan shirt is very snug

B- Tier

Pantheon

Multiple designs to choose from that change each year
Wait watching a demo, then wait again to get the shirt
I don't vibe with the "I Make The Internet" slogan myself, but you do you
Some creative takes on the company logo, that feel less awkward to wear as someone who has never worked there or used their product
The company's leadership has defended providing services to Alliance Defending Freedom, which the Southern Poverty Law Center has designated as a hate group for it's actions against LGBTQ+ rights

D Tier

The basic logo

I'll save the individual companies from shame, cause there's a lot
I resist wearing shirts with just the logo of companies I've actually worked for² - I'm not going to wear one of an agency I don't, or a product I don't use
Your marketing dollars are better spent on a shirt that doesn't only get worn when I'm going to get dirty cleaning my bike
Your company probably has a designer on the team - give them a day to make something fun that people will be excited to wear

D Tier

Twilio

Simple illustration related to the company's product

B- Tier

Mandrill

It's just a logo, but it's colourful and could just be mistaken for something I bought after visiting the zoo.

C+ Tier

Do you have a favourite swag shirt from a past conference? Is there a great shirt to get in Pittsburgh? Some other great swag item you've received at a conference? Tell me about it in the comments.

¹ I will not be there
² Most logos from any company, really

And if your team is looking for a Senior Drupal Developer with oddly specific opinions on some niche topics, send me a message.

Analyzing a Content Security Policy circumvention for script injection and data exfiltration

Geoff — Mon, 19 Sep 2022 07:49:10 +0000

In today's news, a particular unsavoury website has had a script injection in place on its website, reportedly for quite some time:

Kevin Beaumont

@gossithedog

The saga continues - there was (also?) a script injected for a month on Kiwi Farms called Troonshine, gathering information and credentials from user’s systems, posting it to “poz.hiv”.

They look very, very owned.

18:28 PM - 18 Sep 2022

What (might have) happened

The provided log entry shows that file with a .opus extension was requested from the server, with its referrer being the path /test-chat. It's likely that it was added to the page as an <iframe> through some other content injection vector. File extensions are often not particularly meaningful on the web, so the server and browser both can be just fine treating the .opus file as an HTML page to include as the contents of an inline frame.

While the parent page reportedly had a Content Security Policy set via a meta tag that restricted scripts on the page, such a policy does not apply to the contents of nested iframes, which need their own policy. As result the iframe is able to load a malicious script from an external domain without restriction.

How bad was it?

Pretty bad. But also quite bad that it's just a link in a chain for the full exploit.
Preconditions for the full exploit are being able to (1) upload a file to the website's origin domain and (2) inject an iframe referring to that file elsewhere on the site.

Normally iframe sandboxing restricts accessing the parent page's contents. However, since the iframe's destination is hosted on the same domain as the parent page it has access to things such as cookies or localStorage, and can make further requests to the origin domain as the user and extract any data from the responses. If a session key is accessible (by not being in a http-only cookie), it can be extracted and used to hijack the session, bypassing password and 2FA authentication.

Prevention for savoury people

There's a bunch of measures that could make a vulnerability like this less likely to be exploited on your (savoury) site.

The site admin provided an example of the page's Content Security Policy, which only included a script-src directive (though not entirely clear if their example was shortened to only what they thought was relevant). If your site doesn't use iframes, then adding a frame-src: 'none' directive would prevent a similar content injection from being effective. Even better would be to start with a restrictive default-src, and adding exceptions to more specific directives where necessary.
Having the web server add a restrictive policy to the headers served for any file resources - e.g. default-src 'none'; frame-ancestors 'none', would prevent them from being embedded elsewhere, or being able to execute any scripts if accessed directly.
If any user-uploaded content is provided through a separate subdomain (e.g. user-content.example.com), then pages served from it don't have access to cookies restricted to the parent domain, and can't make requests impersonating the user to the main domain.
A Content Security Policy directive only including the top level domain (either explicitly or via 'self') would also not allow any subdomain content from being loaded where not wanted - e.g. default-src 'self'; img-src 'self' user-content.example.com.

A helper module for throttling tasks in Drupal

Geoff — Sat, 26 Dec 2020 07:52:22 +0000

It is pretty common that a site needs to do something regularly, but not too often. Most frequently it is maintenance tasks done through hook_cron, like core's update_cron which limits how often it checks for new versions of a site's modules. The pattern is pretty simple - store a timestamp in the site's state when the task is executed, then before executing the task again check that the desired period has elapsed.

A colleague took another approach that I thought was interesting and worth polishing into a contrib module, so I created Periodic. Instead of each task needing to duplicate the code for storing and checking a timestamp, Periodic's cron task emits events for common periods of time which other modules can respond to as needed:

MyModuleEventSubscriber {

  public static function getSubscribedEvents() {
    $events = [];
    $events[PeriodicEvents::HOUR] = ['hourlyTask'];
    $events[PeriodicEvents::DAY] = ['dailyTask'];
    return $events;
  }

  public function hourlyTask() {
    // Do hourly task.
  }

  public function dailyTask() {
    // Do daily task.
  }

}

If a different interval is needed for a task, Periodic offers a service to check if execution should proceed:

function mymodule_cron() {
  $periodicManager = \Drupal::service('periodic.manager');

  // Limit task to every six hours.
  if ($periodicManager->execute('mymodule.crontask', 21600)) {
    // Do custom task.
  }
}

Inline JavaScript in Drupal 8

Geoff — Wed, 20 Nov 2019 00:49:27 +0000

A Brief History Inline

In Drupal 7, the global function drupal_add_js() accepted three types of arguments:

A path to an internal file, or an external URL
A snippet of JavaScript to be added to the page inline
An array of values to be added to Drupal.settings for JavaScript to use.

Each item had a few properties to determine where on the page it appeared, and what order relative to other items (e.g. ['scope' => 'header', 'group' => JS_DEFAULT, 'weight' => -10]).

drupal_add_js() could be called at any time during page execution, prior to the page markup being rendered, or render arrays could have the same parameters added to their ['#attached']['js'] array.

The Drupal 8 Libraries API

Drupal 8 introduced some substantial changes:

Instead of adding individual files to the page, modules and themes must define libraries - which can contain multiple files.
Libraries can only be added to the page by specifying them in a render element's ['#attached']['library'] array, or via hook_page_attachments().
There is no API to add inline snippets of JavaScript to the page.

The Libraries API offers a number of benefits:

If there was an ordering conflict with JavaScript files in D7, a site would need to implement an alter function to adjust the weights of relevant files to ensure the correct execution order. Drupal 8 libraries instead each define what other libraries they depend on, allowing Drupal core to automatically resolve the order.
In D7 all scripts defaulted to being added to the head of the page, since it wasn't possible to determine if libraries like jQuery did not have any other scripts placed in the header dependent on it. By having D8 libraries define their dependencies, they can default to be included at the bottom of the page markup for better loading performance, but automatically be moved to the header if needed by a dependent library.
Drupal 8 introduced the Dynamic Page Cache, which caches rendered fragments of the page and improves performance for authenticated users. If scripts were added separately from render elements, the Dynamic Page Cache wouldn't be able to properly add them when content is retrieved from the cache, resulting in broken functionality.
The risk of Cross-Site Scripting vulnerabilities can be substantially reduced by blocking inline scripts with a Content Security Policy. If a site's modules all make use of the libraries API & drupalSettings, it's even possible to automatically generate a policy for a Drupal site.

Adding Inline Snippets

If you think you really need some inline JavaScript it's still possible to add it to a page in a few ways, depending on your needs.

Copy to an external file

If the snippet is static code, and any of it's configuration is included in the snippet and doesn't change based on the page content, it can just be placed in an external file added to the page via the Libraries API. The code will then be aggregated with the page's other JS.

Refactor to use DrupalSettings

When data needs to be passed from PHP to JS the best solution is to refactor the snippet to work as an external file that uses data provided by drupalSettings.

The Googalytics module is an example of this approach. Instead of using string concatenation to generate JavaScript to be added as an inline snippet, the method parameters are added to drupalSettings which is added to the page as a JSON object, then dynamically passed to the relevant JS function:



  for (var i = 0; i < drupalSettings.ga.commands.length; i++) {
    ga.apply(this, drupalSettings.ga.commands[i]);
  }

Create a new render element

If the snippet is a repeatable element, create a new renderable element so that you can place it on the page via a render array, and provide any parameters that need to passed to the corresponding Twig template:



$render['js_embed'] = [
  '#type' => 'js_embed',
  '#id' => 12345,
];



<script>
  js_embed( {{ id }} );
</script>

Add to html.html.twig

Snippets can be added directly to Twig templates. For global JavaScript, just add it to html.html.twig after <js-placeholder token="{{ placeholder_token }}"> or <js-bottom-placeholder token="{{ placeholder_token }}"> as required. If configurable parameters are needed, these can be passed through to the twig template by setting them in hook_preprocess_html().

HTML Markup

A script tag can be added to the page via the html_tag render element.



$render['snippet'] => [
  '#type' => 'html_tag',
  '#tag' => 'script',
  '#value' => 'alert("Hello World!");',
];

or via #markup



$render['snippet'] => [

  '#markup' => '<script>alert("Hello World!");</script>',

  '#allowed_tags' => ['script'],

];

The Attach Inline Module

Some people still want core to provide an API to add inline snippets. At the risk of bolstering those who want this re-introduced to core (which I don't think is a good idea), I created the Attach Inline module to:

Explore whether a contrib module can sufficiently supply this functionality.
Better scope the effort required to implement a robust API.
Enumerate the limitations and trade-offs of this API, to support whether or not it should actually be a candidate for re-inclusion in Drupal core.
Provide an integration with the Content Security Policy module to limit the risk of using inline scripts.

Usage

The module re-introduces the ['#attached']['js'] array to render elements:



$render['element'] = [

  '#attached' => [

    // Existing Functionality

    'library' => [

      'drupal/drupalSettings'

    ],

    'drupalSettings' => ['module' => $data],

<span class="c1">// New functionality</span>
<span class="s1">'js'</span> <span class="o">=&gt;</span> <span class="p">[</span>
  <span class="s1">'alert("World");'</span><span class="p">,</span>
  <span class="p">[</span>
    <span class="s1">'data'</span> <span class="o">=&gt;</span> <span class="s1">'alert("Hello!")'</span><span class="p">,</span>
    <span class="s1">'scope'</span> <span class="o">=&gt;</span> <span class="s1">'header'</span><span class="p">,</span>
    <span class="s1">'weight'</span> <span class="o">=&gt;</span> <span class="o">-</span><span class="mi">10</span><span class="p">,</span>
  <span class="p">],</span>
<span class="p">],</span>



],

];

The limitations so far

Because inline snippets cannot define their library dependencies directly, if a snippet is added to the page header the dependency resolution cannot determine what libraries should be promoted to the page header. This could be worked around by having a placeholder library that only defines the dependencies which inline snippets need to be placed in the page head.
Snippets only have basic weighted ordering, and are placed after all included files. If an external file requires a snippet to be defined first, this can currently only be accomplished by placing the snippet in the page head and the corresponding library at the end of the page.
I have no idea if this cooperates with the Dynamic Page Cache or Big Pipe modules, or many other pieces of Drupal core.