DEV Community: Web-Engineer

Passwordless sign-in for DontSendMeACard, powered by Web-Engine Sentry

Craig Lawson — Fri, 30 Oct 2026 17:05:56 +0000

Signing in to DontSendMeACard.com now takes one field. You type your email address, a code lands in your inbox, you enter it, and you're in. There's no password to remember and no traffic lights to click. Behind that simple screen is a change we've wanted to make for a while: using Web-Engine Sentry, our own bot-protection service, to stop spam and make sign-in faster for real people.

A bit of background

DontSendMeACard.com describes itself as "the online alternative to greeting cards". People send e-cards, often designed by charities, and donate what they would have spent on paper cards and postage. We've supported the platform for years. Like any site with public sign-up forms, it attracts bots.

When the captcha wasn't the problem, and wasn't the answer

A few years ago the site's sign-up form started filling with junk accounts, even though Google reCAPTCHA v2 was in place. When we audited the history recently, the numbers were stark. Between September 2023 and August 2024, with reCAPTCHA v2 on the form, sign-ups matching our spam pattern ran at roughly 200 to nearly 1,000 a month.

The uncomfortable finding was that the server was checking reCAPTCHA correctly. The bots were simply arriving with tokens that passed. That's an important lesson. A captcha integration can be implemented perfectly and still fail, because the challenge itself is no longer a reliable test of whether a visitor is human.

A stop-gap was added in 2024 and the spam dropped sharply. But that check was never designed to prove a visitor was a person, and charities told us it wasn't the friendliest way to register. It needed replacing with something built for the job.

Step one: Sentry on every front door

We started by switching the site's three public entry points to Sentry: charity sign-up, donor account set-up and sign-in. One setting controls all three.

A few design choices matter here:

Server-to-server confirmation. The browser widget's result isn't trusted on its own. The site's server confirms each result directly with Sentry before it creates an account or signs anyone in. A missing, forged or reused result is refused.
Choice of challenge. Visitors aren't forced into one kind of test. For example, they can solve a visual puzzle or verify with an emailed code. Email verification needs no puzzle and doesn't depend on being able to see one, which makes it a more accessible route for many people.
Resilience. The widget loads from a backup CDN if the primary one is unavailable, and confirmation falls back to a second API host. We've written about how we built failover into Sentry before, so we won't repeat it here.

Before release we tested the obvious attacks locally: posting with no result, a forged result, a result replayed a second time and a result that claims to come from the wrong host. Each one was refused.

Step two: turning the human check into the sign-in

Once Sentry was verifying email addresses on the sign-in page, a question followed naturally. If we've already proved someone controls an inbox, why also ask for a password?

So the next day we flipped the sign-in page around:

Enter your email. That's the only field.
Sentry emails you a one-time code.
Enter the code. The form submits as soon as Sentry accepts it. There's no extra "Sign in" button to hunt for.

You're signed in to the account whose address Sentry verified. The address typed into the page is never trusted on its own. If someone verifies one address and then tries to submit another, the sign-in is refused. Other safeguards follow:

Codes are single-use and time-limited. A code is accepted for 15 minutes.
Every sign-in starts a fresh session, whichever route you used.
Matching is exact, so addresses that only look similar can't be swapped in.

Passwords haven't disappeared. A small "Try another way" link under the form leads to the familiar email-and-password sign-in and password reset, for anyone who prefers them. The new sign-in also sits behind a configuration switch, so it can be turned off without a deploy if it ever needs to be.

Here's the shape of the server-side check, as illustrative pseudo-code only. It isn't Sentry's API:

// Illustrative only: sign in as the address that was verified,
// never the address the form claims.
$receipt = confirmWithVerificationService($request->token); // server to server
if (!$receipt || $receipt->used || $receipt->isExpired()) {
    refuse();
}
$user = findOpenAccountByExactEmail($receipt->verifiedEmail);
if (!$user) {
    offerRegistrationOrTryAnotherWay();
}
startFreshSession($user);

The key line is the lookup. The account comes from what was verified, not from what was typed.

Codes that look like they belong

A one-time code is only reassuring if people trust the email it arrives in. A message from an unfamiliar sender with someone else's branding looks a lot like phishing.

DontSendMeACard is the first site to use a new Sentry option for its own mail settings and branding. The code emails now arrive under the DontSendMeACard name, with its logo and its own wording, and that can be updated from our cloud platform in moments, without touching the site's code. The DSMAC team are already refining the copy, including a clear reminder that staff will never ask you for your code.

What it adds up to

For visitors, sign-in is now one field and one code. For the site, every way in passes through a check that's confirmed on the server rather than trusted from the browser. And because email verification needs no puzzle, that check is easier for more people to complete.

We'll be honest about one thing: it's early. The change has only just gone live, and we'll review the sign-up spam figures over the coming weeks. Moving from reCAPTCHA to Sentry was a deliberate choice, made because the data showed reCAPTCHA wasn't stopping these bots. We'll share how it holds up.

Want the same for your site?

Web-Engine Sentry is WordPress-first, but it ships with an API and examples, which is exactly how we integrated it into DontSendMeACard's custom PHP platform. If spam is getting through your forms, or your sign-in is more effort than it needs to be, get in touch. We're happy to talk through what would work for you.

Failover beyond DNS

Craig Lawson — Thu, 15 Oct 2026 15:11:32 +0000

So you've built a service and it's running in the cloud. It sits in a Kubernetes cluster, it's designed for high availability, and every component has a replica. Then the data centre loses its connection to the internet, and none of that helps.

It happens more often than we'd like to admit. Data centres with multiple independent points of presence still have outages. On 20 October 2025, a DNS fault inside AWS's US-EAST-1 region cascaded into hours of disruption for a long list of services that had nothing to do with each other, apart from where they were hosted. Cloudflare has had more than one bad day too, including an outage of its 1.1.1.1 DNS resolver in July 2025 and a network-wide failure that November. When a large share of the web sits on a handful of providers, one provider's bad afternoon becomes everyone's.

The uncomfortable lesson is that your hardware can be perfectly healthy and you can still be offline. Spread yourself across data centres with failover between them, and a DNS problem can still undo the whole arrangement.

Why this mattered to us

Web-Engine Sentry (Sentry for short) is our site-protection plugin. It cuts spam by making a site hard work for bots while keeping it easy for humans. It's built for WordPress first, and it ships with an API and examples so it can protect any site. Sentry gives sites several ways to check that a visitor is real: captcha, email verification and mobile verification. As soon as a site puts one of those checks in front of its contact form or login page, our uptime becomes their uptime. If we're unreachable, their visitors can't get in touch or sign in.

So "it's in the cloud" wasn't a good enough answer. We needed a plan that keeps the service running wherever possible, whatever fails underneath it.

Option one: throw hardware at it

You can solve most availability problems with hardware, if you have the budget. Large cloud providers do exactly that, and they price it in. For most teams, though, a purely hardware-based answer is expensive, and you're still bound by the physical limits of someone else's estate.

The conventional approach would be to host in two geographic regions and use DNS failover to switch between them. It works, but it isn't instant. Once the primary goes down, health checks have to notice, records have to change, and resolvers around the world have to let go of cached answers. Short TTLs help, but not every resolver honours them. That leaves a window, often a few minutes, where requests fail. For a verification step sitting in front of someone's checkout, a few minutes is a long time.

Option two: make the software smarter

The alternative is to let the client decide. Give the consumer of the service an ordered list of endpoints, add some basic error handling, and when a request fails, move to the next one straight away.

The real advantage is that those endpoints can be completely independent: different hosting, different networks, even different DNS providers. Failover no longer waits for a record to propagate. It happens on the next request, in milliseconds. Our weak point becomes our own code and the service itself, rather than the rigid physical constraints of our suppliers, and our own code is something we can test, improve and ship.

DNS failover vs client-side fallback

The idea in its simplest form:

// Simplified illustration, not the Sentry SDK itself
const ENDPOINTS = [
  'https://a.example-primary.net',
  'https://b.example-secondary.org',
  'https://c.example-tertiary.io',
];

async function callService(path, options = {}) {
  for (const base of ENDPOINTS) {
    try {
      const res = await fetch(base + path, {
        ...options,
        signal: AbortSignal.timeout(3000),
      });
      if (res.ok) return res;
    } catch (e) {
      // network error or timeout: try the next endpoint
    }
  }
  throw new Error('All endpoints unavailable');
}

Decentralise by design

Real resilience comes from breaking the application into its key parts and giving each one its own availability strategy. Once you treat each component as a separate service, you can tune how each one fails over. Here's how that played out for Sentry.

DNS

We spread our endpoints across several domains, each managed by a different DNS provider, with multiple endpoints behind each domain. If one provider has a bad day, the others are unaffected. Relatively short TTLs mean we can repoint routes quickly when we need to.

Frontend

The browser script loads from whichever CDN endpoint is available. The frontend knows about the alternatives, so if a script fails to load it moves on to the next one. That gives us geographically separate fallbacks managed entirely on the visitor's side. Once it finds an endpoint that works, it sticks with it for the rest of the session, so visitors don't pay the cost of a failed attempt twice.

Backend

On the site's own server, the Sentry SDK acts as a gateway to the available service endpoints. That pushed us to treat each backend as a separate node from the start and to design a proper synchronisation strategy between them. We had to decide early what the service provides and how to deliver it in a decentralised way, rather than bolting resilience on later.

Data

Each node also runs its own separate database, holding a specific set of tables duplicated across several sites. Our APIs keep these in sync with the master. Some of that data is read-only reference data; the rest lets a node keep tracking activity on its own. That's enough for the service to keep running even when the primary site is unavailable. When the master comes back, each node syncs what it recorded back to it.

Behind everything sits a highly available database cluster, and the nodes treat it as the ultimate source of truth. On paper, that cluster should never go down. We deliberately don't assume it won't. Making no promises about its availability gives us another layer of fault tolerance, and forced us to plan up front how data is reconciled once everything is back online.

The result

None of this is exotic. It's a fallback list, some careful error handling, and the discipline to assume every layer can fail. Together those give a site running Sentry verification that keeps working through regional outages, DNS failures and the occasional very bad day in a data centre.

Try it, and tell us what you think

You can install Sentry from the WordPress plugin directory, or read more about Web-Engine Sentry and the Sentry API to use it on any site.

How do you handle failover in your own services? Have you been caught out by DNS? Join the discussion and let us know.