A Node on the Web

Another reason to leave WordPress behind

Wed, 26 Aug 2026 18:40:07 GMT

So today it was fires both at work and privately :

I successfully intercepted what appears to have been an attempt to compromise chardonsbleus.org.

Two administrator accounts were created within a very short period of time. At first, I assumed the usual suspects: an outdated WordPress plugin, WPML, or some other vulnerable component.

But that doesn’t appear to be what happened.

The traces left in the logs and database indicate that both administrator accounts were created through a backend API request with administrative privileges. Everything I have found so far points toward the WPMU DEV API key as the attack vector.

What surprised me most is that I had no idea credentials associated with that service could potentially be used in a way that results in the creation of WordPress administrator accounts — apparently without needing the password of an existing administrator.

There is still another possibility: that my main administrator account itself was compromised. It uses a strong password, though, and based on the traces I have, I consider that considerably less likely.

So I’m not claiming to have reconstructed every step of the attack yet. What I do know is that two unauthorized administrator accounts appeared, and the database and logs point to an API-level administrative operation rather than a normal WordPress login.

I don’t know how many people will ever read this, but for me the conclusion is becoming increasingly obvious:

WordPress has to go.

The main reason chardonsbleus.org is still running WordPress is GiveWP. It is a genuinely good donation plugin, although an expensive one, and replacing that functionality has always been the main obstacle to migrating the site.

I’m going to find another solution for donations.

After that, I’ll probably move the site to Indiekit and finally decommission the WordPress installation altogether.

Oups… Accidentally turned my geekom IT15 off but thanks to herdr recovered my op...

Fri, 21 Aug 2026 20:15:00 GMT

Oups… Accidentally turned my geekom IT15 off but thanks to herdr recovered my opencode session without an ounce of stress 😊

Hi Aaron, is there any path to have one’s own domain added to the allowed client...

Fri, 21 Aug 2026 19:21:12 GMT

Hi Aaron, is there any path to have one’s own domain added to the allowed client list on indielogin service ?

I shipped my comment plugin to a service that could never accept it

Fri, 21 Aug 2026 17:45:00 GMT

I’ve been rebuilding the comment system on this site with Claude Code. Visitors sign in with their own website to leave a comment — IndieAuth, the way it’s meant to work.

Overnight we migrated it from IndieAuth to IndieLogin.com. At 05:40 this morning it published to npm and deployed. By 08:00 I’d opened an incognito window, typed in my own domain, and got this:

Request Error
This client_id is not registered (https://rmendes.net)

The migration could never have worked. Not “had a bug” — could never have worked, for any visitor, on any site not already on a list I didn’t know existed.

Why it looked right

The reasoning behind the change was sound, which is what makes it worth writing up.

The plugin discovered each visitor’s own authorization_endpoint and sent them there. Visitors without one fell back to indieauth.com. That fallback is the part that dates: indieauth.com’s own home page says it “will eventually be replaced,” and points developers at IndieLogin.com.

IndieLogin also promised more providers — Bluesky, GitLab, Codeberg — and one genuinely appealing property. When you discover each visitor’s endpoint, you inherit an obligation from IndieAuth §5.4: if the profile URL the server returns isn’t the one the visitor typed, you must re-discover it and confirm it declares the same authorization endpoint. Skip that, and any authorization endpoint can return any me and be believed — including mine. My plugin was skipping it. Delegating to one trusted service makes that whole class of problem structurally impossible rather than merely fixed.

Good argument. Built on documentation nobody tested.

The part the docs don’t mention

IndieLogin’s API docs describe client_id as informational: “the home page of the application the user is signing in to.” Nothing about registration.

The source says otherwise. In app/Authenticate.php, on the authorize path:

$client = ORM::for_table('clients')->where('client_id', $client_id)->find_one();
if(!$client) {
  $errors[] = 'This client_id is not registered (...)';
}

That table is queried in two places and written in none. Registration happens by opening a GitHub issue asking to be added. There’s a queue of them, requests from April and August this year sit unregistered, and an issue asking for a self-service registration form has been open since 2018.

The ideal would have been a solution to automate client website registration, there is a github issue for it, but to the best of my knowledge it has not been developed.

When Claude first told me this, I didn’t believe it — it sounded like a hallucination. aaronpk advocates for this stuff; the idea he’d maintain a manual allowlist seemed absurd. It restated the claim twice before I pushed hard enough that it stopped arguing and designed a test instead: same endpoint, same parameters, a deliberately-broken redirect_uri on both.

indiebookclub.biz → “The client_id and redirect_uri must be on the same domain” appears to indicate this site is on the list of allowed clients.
rmendes.net → “This client_id is not registered” indicate I’m not the list and the opened github issues appear to indicate there is no way to get in without poking the indieweb people on IRC or via email.

A known consumer clears the client check and trips the next rule. Mine never gets that far. That’s not a reading of the source, it’s the live service behaving differently based only on the domain.

None of this is a knock on IndieLogin. It’s free, someone pays to run it, and an anti-abuse step simply never got automated — issue #20 says as much. But “free for anyone to use” and “requires a manual step that isn’t happening” are both true at once, and only the first one is documented.

The actual failure

One curl to /authorize would have caught this before a line of code was written. It never happened. The whole migration — design, implementation, publish, deploy — rested on an API description that was accurate about the protocol and silent about the policy, and nobody poked the real endpoint.

My assumption was, its working like indieauth.com, why would anyone want to maintain a list of allowed clients ???

That’s the AI-assisted failure mode worth naming, and it isn’t “the AI wrote bad code.” The code was fine. The tests passed. The commit message was better than mine usually are. It was confidently, fluently wrong about something it could have checked in ten seconds, and confident fluent output is exactly what stops you asking.

What caught it was me, in an incognito window, doing the thing a user does : testing

Docs describe the protocol. Deployments enforce the policy. Only one of them rejects you.

Back to IndieAuth, but better

We reverted, which restored a working system that still had the §5.4 hole. So the rest of the day went on fixing that properly instead of delegating around it.

Profile URL verification. When the returned me differs from what was typed, re-discover it and require the same authorization endpoint. An endpoint claiming rmendes.net now gets refused. Failure to re-discover fails closed. Verified against live discovery, not just stubs.

Discovery via microformats instead of pattern matching. The old code matched <link rel="x" href="y"> with a regex. Measured against real markup, it handled one shape out of five:

markup	regex	mf2
relative `href="/auth"`	`/auth` — unresolved	resolved
single quotes	missed	found
`rel="me authorization_endpoint"`	missed	found
`<a rel=...>` (spec-legal)	missed	found

None of those failed loudly. A missed rel silently routes someone running their own authorization server to the third-party fallback instead — the opposite of what this plugin is for. microformats-parser was already in the dependency tree. It just wasn’t being used, so we started using it !

Server metadata discovery. Servers publishing rel="indieauth-metadata" now get that document preferred over the rels. It’s also the only place an issuer is published, so the iss on the authorization response can finally be checked. The spec mandates simple string comparison there, not URL normalisation — a trailing-slash difference is a mismatch, which is the opposite of what you’d assume. Worth checking before you ship it, as we’d just learned.

Amusingly, this site served a metadata document all along and never advertised it. One <link> in the theme fixed that.

The plugin went from 3 tests to 32, and npm test runs for the first time.

What I’m taking from it

The failed migration was worth more than a clean one would have been. It forced an articulation of why delegating would have been safer, which turned out to be the exact argument for doing the verification properly in-house.

But the durable lesson is about how I work now. An AI can hold more of the IndieAuth spec in its head than I can, write better commit messages than I do, and produce a migration that is coherent, tested, well-documented and completely unshippable — because it never touched the thing it was integrating with.

If you have implemented IndieAuth for commenting on your blog, what was your approach ?

This is actually a cool idea ! In short: it’s a social, RSS-friendly radar for t...

Thu, 20 Aug 2026 16:07:39 GMT

This is actually a cool idea !

In short: it’s a social, RSS-friendly radar for the open web, self-hosted, with magic-link auth, and connected to the fediverse (ActivityPub).

Bernie is right⁠ . If healthcare, decent wages, taxing billionaires and protecti...

Wed, 19 Aug 2026 10:44:37 GMT

Bernie is right⁠.

If healthcare, decent wages, taxing billionaires and protecting workers are now “radical” or “extreme”, then the current US administration is practicing something much closer to state terror against its own population.

Americans are fed up. The tragedy is that a huge part of that anger was successfully redirected — and many of those who wanted to punish the system ended up voting its most brutal incarnation into the White House.

Github down… 404 on any repo I visit, just another reason I’m going to switch to...

Mon, 17 Aug 2026 16:10:06 GMT

Github down… 404 on any repo I visit, just another reason I’m going to switch to code.rmendes.net as primary and github as mirror for my own repos.

Moving Orgs repo : that’s beyond my current scope for now

GitHub status page show a day in hell for the engineers working over there

Google Workspace now receives mail for 21.8% of MX-publishing domains and Micros...

Mon, 17 Aug 2026 11:49:27 GMT

Google Workspace now receives mail for 21.8% of MX-publishing domains and Microsoft 365 for 16.8%. Together that is 38.6% of the measured Internet’s inbound mail behind two companies. Nobody else comes close: the next named provider, Proofpoint, sits at 1.9%.

Source

Quite happy with the way Plume evolved in just a few weeks ! (to use this, you n...

Sun, 16 Aug 2026 17:05:39 GMT

Quite happy with the way Plume evolved in just a few weeks !

(to use this, you need a blog that support Micropub)

White House authorizes private companies to launch ‘hack-back’ cyberattacks that...

Sun, 16 Aug 2026 15:10:25 GMT

White House authorizes private companies to launch ‘hack-back’ cyberattacks that destroy data and systems, targeting foreign cybercrime organizations — vetted organizations can now conduct offensive cyber operations | Tom’s Hardware

https://share.google/vkx5E0RRVXU2Mwi42

What could go wrong?

Damn… There isn’t one single actively developed IndieWeb/Micropub mobile app on...

Sun, 16 Aug 2026 15:08:59 GMT

Damn… There isn’t one single actively developed IndieWeb/Micropub mobile app on the Android playstore. Even IndiePass has been discontinued. I don’t want to start from scratch but I’m considering if I should do something about it. I’m fine publishing on mobile using my browser but IndiePass was quite handy and better integration with Android Share to targets.

Test post without Syndication

Sat, 15 Aug 2026 22:00:26 GMT

Test post without Syndication

I think my #Indiekit fork might be one of the very few setups where this happens...

Sat, 15 Aug 2026 20:40:20 GMT

I think my #Indiekit fork might be one of the very few setups where this happens:

You post from Phanpy or Moshidon — regular Mastodon clients, no Micropub support at all.

My custom Fedify AP answers the Mastodon client API, turns that request into a Micropub post, writes it to my own site as Markdown, and then federates it as #ActivityPub.

My blog via that same plug-in answers the Mastodon API.

So Phanpy and Moshidon think they’re talking to a Mastodon server.

They’re not. They’re writing Micropub.

The flow is : Mastodon client → Mastodon-compatible API → Micropub → Markdown file on my own site → ActivityStreams 2.0 → delivered to followers.

Same for edits: editing from Phanpy issues a Micropub replace, then broadcasts an Update(Note).

Plenty of projects do “native post → AP representation” (WordPress, Micro.blog).

What I haven’t seen elsewhere is the extra hop: a non-Micropub client producing a Micropub post without knowing it.

It’s been a fun coding summer 🌞😎

They are killing Hyperlinks

Sat, 15 Aug 2026 20:14:40 GMT

They are killing Hyperlinks

Had fun coding a small python script for weechat that relay mentions of my handl...

Sat, 15 Aug 2026 20:07:39 GMT

Had fun coding a small python script for weechat that relay mentions of my handle to my self hosted private ntfy sever allowing me to get IRC notifications while on the go, the notification carries the actual message of the user on IRC so I can quickly check if it needs a reply or not.

Yes very useless and fun 😅

Testing Plume from Firefox, now you can see the steps indieauth take against you...

Sat, 15 Aug 2026 19:33:37 GMT

Testing Plume from Firefox, now you can see the steps indieauth take against your site for the initial connection, there is also a welcome tab for onboarding (Inspired by Omnibear)

Improved Plume onboarding and fixed a few bugs https://rmdes.github.io/plume/ #m...

Sat, 15 Aug 2026 19:15:21 GMT

Improved Plume onboarding and fixed a few bugs https://rmdes.github.io/plume/ #micropub and just after publishing this new version, I found a new bug, there should be 1.5.1 very soon !!!

Test post from Omnibear #micropub extension

Sat, 15 Aug 2026 12:54:39 GMT

Test post from Omnibear #micropub extension

I’m refactoring my AP implementation first so that I can properly build C2S late...

Sat, 15 Aug 2026 11:42:58 GMT

I’m refactoring my AP implementation first so that I can properly build C2S later on, for now I’ll keep the API layer, since it already covers a lot of ground but the refactoring will allow me to have a more robust implementation and I’m finding this https://www.stevebate.net/activitypub-client-api-a-way-forward/#flowz very inspiring

It really sucks to have a properly configured email server, running on your own...

Sat, 15 Aug 2026 09:44:36 GMT

It really sucks to have a properly configured email server, running on your own domain — thanks, Cloudron — only to have Google, Microsoft, and the other giants systematically dump your messages into spam anyway.

And yet I now find myself sending important emails twice, or using another provider, just to make sure they actually reach the person on the other side.

Email was supposed to be an open, decentralized protocol. Instead, a handful of monopolies have effectively privatized deliverability: they decide whose mail is trustworthy, whose isn’t, and independent servers are guilty until proven innocent.

#Enshittification at scale: privatize the commons, segment it, then slowly make the open alternative unusable for everyone else.