Forem: Stephen Samra

Prevent spam in Statamic forms

Stephen Samra — Mon, 13 Nov 2023 21:33:38 +0000

If you're using Statamic's Forms feature to power a public facing form, you'll benefit from using some sort of spam prevention service. I've built plenty of "Contact Us" forms in my day, and I can tell you that eventually it will be targeted with spam messages. It's just a matter of time.

In this article, I'll show you how to add a spam detection service to your Statamic forms and reject any submissions that are deemed to be spam. I'll be using Akismet for this example, but you can use any spam detection service you'd like.

The first step is to create an account with Akismet (or similar service), get your API key, and add it to your .env file:

AKISMET_API_KEY="your-api-key"

...and add a new service to config/services.php so that we can access the API key in our code:

'akismet' => [
    'key' => env('AKISMET_API_KEY'),
],

Next, we'll create a listener that will be triggered when a form is submitted. Statamic dispatches a FormSubmitted event when a form is submitted, but before the submission is saved. The docs say:

You can return false to prevent the submission, but appear to the user as though it succeeded.

This will be perfect for our use case. We can return false in the listener if the submission is deemed to be spam, resulting in the submission not being saved and the site owner not being notified of a new submission.

Create the listener with the following command:

php artisan make:listener HandleFormSubmitted

...and don't forget to register it in app/Providers/EventServiceProvider.php:

<?php

namespace App\Providers;

use Statamic\Events\FormSubmitted;
use App\Listeners\HandleFormSubmitted;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

// use Illuminate\Support\Facades\Event;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event to listener mappings for the application.
     *
     * @var array<class-string, array<int, class-string>>
     */
    protected $listen = [
        FormSubmitted::class => [
            HandleFormSubmitted::class,
        ],
    ];

    // ...
}

Now, we can work on the listener. It's important to note that this code will run when any form is submitted, so we'll need to filter out the form submissions that we don't want to check for spam.

The listener's handle method will receive a FormSubmitted event, which contains the form being submitted and the submission itself. We can use this information to determine if we want to check for spam.

In this example, we'll only be checking the form with the handle of contact_us but if you have multiple forms that you want to check for spam, you could create an array of form handles and check if the submitted form is in that array.

<?php

namespace App\Listeners;

use Statamic\Events\FormSubmitted;

class HandleFormSubmitted
{
    public function handle(FormSubmitted $event): bool
    {
        // Form submissions that aren't for the contact_us form are saved as normal.
        if ($event->submission->form()->handle() !== 'contact_us') {
            return true;
        }

        return ! $this->isSpam($event);
    }

    protected function isSpam(FormSubmitted $event): bool
    {
        // Return true if the submission is spam.
    }
}

You should implement the isSpam method according to the spam detection service you're using. For Akismet, I went with something like this:

use Illuminate\Support\Facades\Http;

protected function isSpam(FormSubmitted $event): bool
{
    $formData = $event->submission->data();

    $response = Http::asForm()
        ->withUserAgent(config('app.name'))
        ->post('https://rest.akismet.com/1.1/comment-check', [
            'api_key' => config('services.akismet.key'),
            'blog' => config('app.url'),
            'user_ip' => request()->ip(),
            'user_agent' => request()->userAgent(),
            'referrer' => request()->headers->get('referer'),
            'comment_type' => 'contact-form',
            'comment_author' => $formData->get('name'),
            'comment_author_email' => $formData->get('email'),
            'comment_content' => $formData->get('message'),
            'comment_date_gmt' => now()->toIso8601String(),
            'blog_lang' => 'en',
            'blog_charset' => 'UTF-8',
            'user_role' => 'guest',
            'is_test' => ! app()->environment('production'),
        ]);

    return $response->body() === 'true';
}

I've removed some logging and error handling for brevity.

That about does it, your Statamic forms should now be protected from spam submissions. This is a good starting point but there's plenty of room for code and feature improvements, such as:

Showing spam submissions in the Statamic Control Panel
Submitting false positives/ham from the Statamic Control Panel
Being able to swap out the spam detection service for a different one
etc.

Maybe I'll write a follow up article on implementing some of these features, please let me know if that's something you'd be interested in.

I hope you found this article useful. If you have any questions or feedback, let's chat in the comments below. Or, you can always reach me on Bluesky or Twitter.

Express & Stripe: webhooks done right

Stephen Samra — Mon, 23 Oct 2023 19:34:27 +0000

When integrating Stripe into an Express application, there's a good chance you'll need to handle Stripe's webhooks to keep your application data in sync with Stripe's data. This article will show you how to organise your webhook handling code to make it easier to maintain and extend.

Some of the examples you'll find online (including Stripe's own docs) will show you how to handle Stripe webhooks using an if or switch statement to handle each event type:

app.post('/webhooks/stripe', (request, response) => {
  const event = request.body;

  // validate the request...

  if (event.type === 'payment_intent.succeeded') {
    try {
        // handle payment intent succeeded event...
    } catch (err) {
        return response.status(500).json({success: false});
    }
  } else if (event.type === 'payment_method.attached') {
      try {
        // handle payment method attached event...
      } catch (err) {
        return response.status(500).json({success: false});
      }
  } else {
    console.log(`Unhandled event type ${event.type}`);
  }

  response.json({success: true});
});

This approach works, but having all of this logic inside of an if statement is not ideal. It can become unwieldy and awkward to maintain as you add more event handlers. It also makes it difficult to see, at a glance, what events are being handled by your application.

Let's refactor this code address these issues.

The first improvement we can make is to extract each event handler into its own function:

app.post('/webhooks/stripe', (request, response) => {
  const event = request.body;

  // validate the request...

  if (event.type === 'payment_intent.succeeded') {
    try {
      handlePaymentIntentSucceeded(event);
    } catch (err) {
      return response.status(500).json({success: false});
    }
  } else if (event.type === 'payment_method.attached') {
    try {
      handlePaymentMethodAttached(event);
    } catch (err) {
      return response.status(500).json({success: false});
    }
  } else {
    console.log(`Unhandled event type ${event.type}`);
  }

  response.json({success: true});
});

function handlePaymentIntentSucceeded(event) {
  // handle payment intent succeeded event...
}

function handlePaymentMethodAttached(event) {
  // handle payment method attached event...
}

With these function in place, we can eliminate the if block and use an object to map event types to event handlers instead:

const handlers = {
  'payment_intent.succeeded': handlePaymentIntentSucceeded,
  'payment_method.attached': handlePaymentMethodAttached,
  // ...
};

app.post('/webhooks/stripe', (request, response) => {
  const event = request.body;

  // validate the request...

  const handler = handlers[event.type] || handleUnhandledEvent;

  try {
    handler(event);
  } catch (err) {
    return response.status(500).json({success: false});
  }

  response.json({success: true});
});

function handlePaymentIntentSucceeded(event) {
  // handle payment intent succeeded event...
}

function handlePaymentMethodAttached(event) {
  // handle payment method attached event...
}

function handleUnhandledEvent(event) {
  console.log(`Unhandled event type ${event.type}`);
}

This is much better. Now, all that's required to add a new event handler is to add an entry to the handlers object and implement the corresponding function. We can also clearly see what events are handled by our application and where to go if one of them needs to be updated.

If you were to stop reading here, you'd be in good shape. However, there's one more improvement we can make.

Instead of using global variables to store the event map and handler functions, we can encapsulate them in a class, in a separate file:

class StripeWebhookHandler {
  constructor() {
    this.handlers = {
      'payment_intent.succeeded': this.handlePaymentIntentSucceeded,
      'payment_method.attached': this.handlePaymentMethodAttached,
      // ...
    };
  }

  handleEvent(event) {
    const handler = this.handlers[event.type] || this.handleUnhandledEvent;

    handler(event);
  }

  handlePaymentIntentSucceeded(event) {
    // handle payment intent succeeded event...
  }

  handlePaymentMethodAttached(event) {
    // handle payment method attached event...
  }

  // ...

  handleUnhandledEvent(event) {
    console.log(`Unhandled event type ${event.type}`);
  }
}

export default StripeWebhookHandler;

Back in our Express route, we can instantiate StripeWebhookHandler and use the handleEvent method to handle the events:

import StripeWebhookHandler from './stripe-webhook-handler';

const stripeWebhookHandler = new StripeWebhookHandler();

app.post('/webhooks/stripe', (request, response) => {
  const event = request.body;

  // validate the request...

  try {
    stripeWebhookHandler.handleEvent(event);
  } catch (err) {
    return response.status(500).json({success: false});
  }

  response.json({success: true});
});

This has the added benefit of separating the Express route from the webhook handling logic; the route is now only concerned with validating the request, passing it to the webhook handler, and returning a response. Updating the webhook handler no longer requires touching the Express route, and vice versa.

I hope you found this article useful. If you have any questions or feedback, let's chat in the comments below. Or, you can always reach me on Bluesky or Twitter.