DEV Community: takahiro hashito

I merged three tools with 301 redirects on Firebase Hosting, and every old URL now takes two hops

takahiro hashito — Wed, 07 Oct 2026 14:42:29 +0000

Background

I run a site of small browser-based tools, and last week I folded three near-duplicate tools into the tools that already covered them.
For example, the calendar QR generator (calqr) became an option inside the event QR generator.

https://hashitosystem.com/en/tools/eventqr/

The old pages were deleted, so the old URLs needed permanent redirects.
I added them, opened an old URL in a browser, landed on the new tool, and moved on.
This morning I checked the raw HTTP responses instead of the browser, and every old URL was taking two redirects to arrive, not one.

The setup

The site is a static site on Firebase Hosting.
Firebase Hosting is Google's static hosting service, and it is configured through a firebase.json file in the project.
Two settings matter here.
cleanUrls: true serves /tools/eventqr/index.html without the index.html part.
trailingSlash: true makes the canonical form of every page end with /, and redirects the slash-less form to it.

The merge added redirect rules in the hosting.redirects array of firebase.json.
Each old tool got two rules: one for the bare path, and one with /** so that anything under the old directory is caught too.
Here is the pair for one of them, exactly as committed:

{
  "source": "/tools/calqr",
  "destination": "/tools/eventqr",
  "type": 301
},
{
  "source": "/tools/calqr/**",
  "destination": "/tools/eventqr",
  "type": 301
}

A 301 is a permanent redirect.
Search engines are expected to move the old URL's ranking signals to the destination, which is the whole reason for not just returning 404.

Seeing every hop

A browser follows redirects silently, and so does fetch by default, so neither shows you the chain.
In Node.js 18 or later, passing redirect: "manual" to fetch returns the redirect response itself, with its Location header readable.
The script below requests each path once and prints the status code and where it points.
Save it as redir.mjs and run it with node redir.mjs; change base and paths to your own site.

// redir.mjs: print the first response for each URL without following redirects
const base = "https://hashitosystem.com";
const paths = [
  "/tools/calqr",
  "/tools/calqr/",
  "/tools/calqr/index.html",
  "/tools/calqr/foo",
  "/tools/eventqr",
  "/tools/eventqr/",
];
for (const p of paths) {
  const r = await fetch(base + p, { redirect: "manual" });
  console.log(r.status, p, "->", r.headers.get("location") ?? "");
}

This is the output I got this morning:

301 /tools/calqr -> /tools/eventqr
301 /tools/calqr/ -> /tools/eventqr
301 /tools/calqr/index.html -> /tools/eventqr
301 /tools/calqr/foo -> /tools/eventqr
301 /tools/eventqr -> /tools/eventqr/
200 /tools/eventqr/ ->

The first four lines are my redirect rules working as written: every variant of the old URL goes to /tools/eventqr.
The fifth line is the catch.
/tools/eventqr is not the canonical URL on this site, so trailingSlash: true answers it with another 301 to /tools/eventqr/.
So the real path for an old link is /tools/calqr to /tools/eventqr to /tools/eventqr/: two hops.

It was not new, either.
An older merge on the same site (uuidgen into uuid) was written the same way and has the same chain.

Confirming the fix on a site with the same settings

I have another site on Firebase Hosting with the same cleanUrls: true and trailingSlash: true, where the redirect destinations were written with a trailing slash (for example "destination": "/tools/amidacuji/").
Running the same script against it gave this:

301 /amidacuji -> /tools/amidacuji/
301 /amidacuji/ -> /tools/amidacuji/
200 /tools/amidacuji/ ->

One hop, straight to the page that returns 200.
So the difference really is just the trailing slash in destination, and the fix for the merged tools is to write /tools/eventqr/ instead of /tools/eventqr in all twelve rules.
I have not deployed that change yet; it goes through a pull request on that repository like every other change.

Why bother about one extra hop

For a human, two hops cost a few extra round trips and nobody notices.
The reason I care is that the redirect is there for crawlers.
Google's documentation says Googlebot follows a limited number of redirect hops, and every hop is one more request out of the crawl it spends on a small site like mine.
A redirect whose only job is to pass a page's history to its replacement should do it in one step, not depend on a second rule I did not write on purpose.

Takeaway

When trailingSlash is on, a redirect destination must be the exact canonical URL, including the final /, or Firebase Hosting quietly adds a second 301.
Opening the old URL in a browser cannot show you this, because it follows the whole chain and only shows the last page.
Probe each old URL with fetch(url, { redirect: "manual" }) and check that the very first response points at a URL that returns 200.

My SRI hash was correct and the browser still blocked the script: line endings and the strongest-hash rule

takahiro hashito — Wed, 30 Sep 2026 14:46:52 +0000

Background

I run a small browser-based tool that generates Subresource Integrity values.

https://hashitosystem.com/en/tools/srihash/

You drop a file or paste some text, and it prints sha384-... plus a ready-made <script> tag.
While re-reading its code, I noticed two ways a user can get a perfectly "correct" hash that the browser still rejects.
Neither is a bug in the hashing itself, which is why they are easy to miss.

What SRI checks

Subresource Integrity (SRI) is the integrity attribute on <script> and <link> tags.
It holds a hash of the file you expect, for example sha384- followed by the Base64 of the SHA-384 digest.
When the browser downloads the file, it hashes the bytes it actually received and compares.
If they differ, the script or stylesheet is not applied.

The point is to protect you when the file comes from someone else's server, typically a CDN (a content delivery network that serves copies of popular libraries from many locations).
If the CDN copy is swapped for a malicious one, the hash no longer matches and the browser refuses it.

The spec is here:

https://www.w3.org/TR/SRI/

The important word is bytes.
SRI does not know about "text" or "the same code".
One different byte means a different hash.

Trap 1: pasted text is not the file

The tool has a textarea for pasting code.
Its handler takes the textarea value, encodes it as UTF-8, and hashes it with WebCrypto:

// from the tool: called on every input event of the textarea
function setFromText(){
  var text = $("textInput").value;
  lastBuffer = new TextEncoder().encode(text).buffer;
  lastLabel = T.pasted;
  render();
}

render() passes lastBuffer to crypto.subtle.digest() for each selected algorithm and Base64-encodes the result.
That part is fine.
The problem is textInput.value.

The HTML standard says the textarea's "API value", which is what the value property returns, is normalized so that line breaks are LF (\n) characters.

https://html.spec.whatwg.org/multipage/form-elements.html#the-textarea-element

So if your file on the server uses CRLF (carriage return + line feed, \r\n, the Windows default) line endings, and you copy its contents into the textarea, the tool hashes an LF version of the file.
The server keeps sending the CRLF version.
The hashes can never match.

I reproduced it with Node.js v24.11.1 and OpenSSL 3.2.3 on Windows.
The script below builds the same two lines of JavaScript with LF and with CRLF endings and hashes both.
It also contains a small checker, matches(), which I use for the second trap.

// sri.js - compute and check Subresource Integrity values with Node's crypto
const crypto = require('crypto');

function sri(alg, bytes) {
  return alg + '-' + crypto.createHash(alg).update(bytes).digest('base64');
}

// Same idea as the spec's "get the strongest metadata" + "do bytes match":
// only the strongest algorithm present in the attribute is compared.
const ORDER = ['sha256', 'sha384', 'sha512'];
function matches(integrity, bytes) {
  const items = integrity.trim().split(/\s+/)
    .map((t) => /^(sha256|sha384|sha512)-(.+)$/.exec(t))
    .filter(Boolean)
    .map((m) => ({ alg: m[1], value: m[2] }));
  if (!items.length) return true; // nothing usable -> no check
  const top = Math.max(...items.map((i) => ORDER.indexOf(i.alg)));
  return items
    .filter((i) => ORDER.indexOf(i.alg) === top)
    .some((i) => sri(i.alg, bytes) === i.alg + '-' + i.value);
}

const lf = Buffer.from('console.log("hello");\nconsole.log("world");\n');
const crlf = Buffer.from('console.log("hello");\r\nconsole.log("world");\r\n');

console.log('LF   ', sri('sha384', lf));
console.log('CRLF ', sri('sha384', crlf));

const good256 = sri('sha256', crlf);
const bad512 = 'sha512-' + Buffer.alloc(64).toString('base64');
console.log('sha256 ok only           ->', matches(good256, crlf));
console.log('sha256 ok + sha512 wrong ->', matches(good256 + ' ' + bad512, crlf));
console.log('LF hash vs CRLF file     ->', matches(sri('sha384', lf), crlf));

Running it gives this:

$ node sri.js
LF    sha384-PodCjN/UtI3bmhRbzuh2f8MreRrb6t3UGdbe/lAL2iaSiB0KG97YrjGiM+taFKlK
CRLF  sha384-vE2zXEYpHh/j7vNH9alyBTCnXDG/7MPztb/K7edllO3K5Fgi1AvFAQpqyzISrEIJ
sha256 ok only           -> true
sha256 ok + sha512 wrong -> false
LF hash vs CRLF file     -> false

The two files look identical in an editor, but the hashes are completely different.
The last line is the textarea situation: an LF hash checked against a CRLF file fails.

I also checked the same two files with OpenSSL, which is the command MDN and most READMEs show, and the output agrees with Node:

$ printf 'console.log("hello");\r\nconsole.log("world");\r\n' > app.js
$ echo "sha384-$(openssl dgst -sha384 -binary app.js | openssl base64 -A)"
sha384-vE2zXEYpHh/j7vNH9alyBTCnXDG/7MPztb/K7edllO3K5Fgi1AvFAQpqyzISrEIJ

This bites hardest on Windows, where Git may check files out with CRLF while the deployed copy (or the npm package on the CDN) has LF.
Hashing the file on your disk can be just as wrong as pasting it, if your disk copy is not byte-for-byte what gets served.

The fix is boring: hash the file that is actually served.
Download it (curl -o lib.js {URL}) and hash that, or use the tool's file input, which reads the file with FileReader.readAsArrayBuffer() and never goes through a textarea.
Pasting is fine for a quick look, but I now treat a pasted-text hash as a draft, not the value to ship.

Trap 2: only the strongest hash counts

The tool lets you tick SHA-256, SHA-384 and SHA-512 together and joins the results with spaces.
Multiple values in one attribute are allowed, and it is tempting to read them as "any of these may match".

That is not what the spec says.
Its "get the strongest metadata from set" step keeps only the entries using the strongest algorithm (the order is sha256 < sha384 < sha512), and only those are compared with the response.
Weaker entries are simply ignored.

The second and third lines of the output above show the effect, using matches(), which follows those two spec steps.
A correct sha256-... alone passes.
The same correct sha256-... next to an outdated sha512-... fails, because the browser only looks at the sha512 one.

This happens in real life when you update a library, regenerate one hash, and forget the other.
Where you do want multiple values is several entries of the same algorithm, for example two sha384 hashes for two acceptable builds of a file; any match among those passes.

What I would do

Generate SRI values from the exact bytes your users will download, not from a copy in your editor or clipboard.
Use one algorithm (sha384 is the common choice), and when you update the file, replace the whole integrity value instead of appending to it.
Those two habits remove both traps.

CVE-2026-81642: a DNSKEY compression pointer overflows Unbound's digest buffer

takahiro hashito — Wed, 23 Sep 2026 15:33:59 +0000

Background

I run a small fleet of static sites, and every day a scheduled job of mine picks one recent CVE (a public identifier assigned to one specific vulnerability) and writes up how to deal with it. Today the queue handed me an Unbound advisory, and I had to stop and read it twice.

I am not a DNS specialist. I keep a recursive resolver running because I want my own name resolution, not because I enjoy it. So when a DNS resolver gets a 9.8, I want to know exactly two things: am I in scope, and what do I turn off until I can patch.

This is that write-up. It is a summary of the primary sources, not original research.

What the bug is

CVE-2026-81642 affects NLnet Labs Unbound up to and including 1.26.0. NVD (the US National Vulnerability Database) publishes the affected range as "less than 1.26.1". Unbound is a validating, recursive, caching DNS resolver.

A few acronyms first, because the advisory assumes them:

CVSS (a 0-to-10 score for how severe a vulnerability is, where 7.0 and above counts as High) is v3.1 base score 9.8 here, rated CRITICAL.
DNSSEC is the signature layer on top of DNS. A DNSKEY record holds the public key a resolver uses to verify those signatures.
CWE-122 is the bug class: a heap-based buffer overflow.

The flaw is in the DNSSEC validator. When Unbound digests a DNSKEY, a record whose owner name is a compression pointer to its own RDATA can push the write past the end of the digest buffer.

Two things follow from the advisory. The reachable outcome is denial of service, and remote code execution is described as possible through attacker-controlled data. The attacker's path is to control a malicious zone and then get a vulnerable Unbound to query it.

That last part is why the score is what it is. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network reachable, no privileges, no user interaction. A recursive resolver's whole job is to go and fetch names it has never seen, so "make it query my zone" is not a high bar.

Am I in scope

Check the version first. Anything below 1.26.1 is in scope.

unbound -V

Then check that the running process is the binary you just inspected. If the package was upgraded but the service was never restarted, the on-disk version is new and the process is still old.

systemctl status unbound
unbound-control status

If you installed from a distribution package, the version string may not match upstream, because distributions backport fixes onto older numbers. In that case the version alone will not answer the question — look for CVE-2026-81642 in the package changelog.

dpkg -l unbound
rpm -q unbound

The bug lives in the DNSSEC validator, so it is worth confirming that validation is actually enabled in your config.

unbound-checkconf -o module-config
grep -E "trust-anchor|auto-trust-anchor-file|module-config" /etc/unbound/unbound.conf

The thing I nearly missed: Unbound ships inside other things. Routers, appliances, container images, and bundled components. I have no memory of installing it on at least one box where it turned out to be running. Checking firmware and image manifests is not wasted effort here.

What I can do before patching

The advisory I read lists no workaround. So everything below is derived from the CVSS vector rather than from the vendor, and you should confirm side effects with your own vendor before applying any of it.

Stop being reachable by things that should not reach you. Restrict access-control to networks you manage. The cost is that legitimate clients outside that range stop resolving.

unbound-checkconf -o access-control

Close 53/udp and 53/tcp at the perimeter. Obvious, but worth confirming rather than assuming.

Temporarily forward instead of recursing. If you forward to an already-patched upstream, you stop walking out to attacker-controlled zones yourself. The cost is that you now depend on that upstream's availability, and you need to know it is not carrying the same flaw.

Check the blast radius. Confirm the daemon runs as its own user and whether chroot is on. This does not fix the bug; it narrows what code execution would reach.

unbound-checkconf -o username
unbound-checkconf -o chroot

I did consider disabling DNSSEC validation, since that is where the bug is. I would rather not. Turning it off trades a heap overflow for losing tamper detection on every answer, which is a bad swap if you can just upgrade instead.

The fix

Upgrade to 1.26.1 or later. That is the only version the NVD range supports calling fixed.

Notes from doing it:

Save your config and trust anchor files first.
Whether a restart is required depends on how you installed it, so I am not going to claim it either way. After upgrading, confirm the running version with unbound-control status.
If you have more than one resolver, do them one at a time and watch that resolution keeps working.

CISA's KEV catalog (the US government list of vulnerabilities with confirmed exploitation in the wild) does not list this CVE. Being on that list comes with a remediation deadline for US federal agencies. Not being on it means no deadline — it does not mean the bug is hard to reach. The vector still says no authentication and no user interaction. I would not use "no deadline" as a reason to defer this one.

Looking for signs you were hit

No public indicators of compromise that I could find. So this is inference from the bug class, not detection of a known pattern.

Heap corruption tends to show up as a crash before it shows up as anything clever. Start there.

journalctl -u unbound --since "7 days ago" | grep -iE "segfault|signal|core|killed|restart"
coredumpctl list unbound
dmesg -T | grep -iE "unbound|segfault"

Then look at validation failures and SERVFAIL rates, in proportion to your normal traffic rather than as raw counts.

unbound-control stats_noreset | grep -E "num.answer.rcode.SERVFAIL|num.rrset.bogus"

And on the host itself, the generic post-exploitation checks: unexpected child processes, new files where config lives.

ps -ef --forest | grep -A3 unbound
find /etc/unbound /var/lib/unbound -newermt "7 days ago" -type f

If you want the same thing in Japanese, with the same fact-checked version numbers, my write-up is here: https://ai-news.autoarticles.net/article/post_1790134098643_3ok48m

Order I would do it in

Today: run unbound -V. If it is below 1.26.1, check what can reach port 53 and narrow access-control on the spot.

This week: upgrade to 1.26.1 or later, and verify the running version afterwards rather than the installed one.

After that: write down every device and image that bundles Unbound, and put them on the same version-tracking list as the resolvers you installed on purpose. The boxes I forgot about are the ones that will still be on 1.26.0 next year.

Embedding JSON-LD in a static site with template literals, and the one escape you cannot skip

takahiro hashito — Thu, 17 Sep 2026 13:17:25 +0000

Background

I run a small static site, a Japanese dictionary of words and phrases that are trending on X. Every page is generated daily by a dependency-free build.js: a Node.js script that only uses the built-in fs module to write HTML files.

Each page carries JSON-LD (JSON for Linked Data, the structured-data format where you describe what a page is about as JSON and put it in a <script type="application/ld+json"> tag for search engines). There is no template engine involved. The JSON-LD goes straight into the HTML through a JavaScript template literal.

This post walks through that setup, and through the single line of escaping that I consider mandatory whenever you embed JSON this way.

How it works

The structure is simple. Each page builds an array of plain objects it wants to publish as JSON-LD and hands that array to a shared head() function.

data/*.json（語のデータ）
   │
   ▼
renderWordPage(w)  ── DefinedTerm / Article / BreadcrumbList / FAQPage のオブジェクトを作る
   │  jsonld: [...]
   ▼
head(opts)         ── 配列を <script type="application/ld+json"> に1個ずつ変換して <head> に入れる
   │
   ▼
public/word/<slug>.html

(The labels in the diagram are the original Japanese notes: word data goes in, renderWordPage builds the DefinedTerm / Article / BreadcrumbList / FAQPage objects, and head turns each one into its own script tag inside <head>.)

Because the objects are ordinary JavaScript objects, adding or dropping properties conditionally is easy to read. The only place that builds an HTML string by hand is the very last step.

Implementation

1. head() turns the array into script tags

Here is the JSON-LD part of the real head() in build.js:

function head(opts) {
  const {
    title,
    description,
    canonicalPath,
    ogType = "website",
    ogImage = "/og-image.png",
    jsonld = [],
    noindex = false,
  } = opts;
  const url = CANON + canonicalPath;
  const jsonldStr = jsonld
    .map(
      (o) => `<script type="application/ld+json">${JSON.stringify(o).replace(/</g, "\\u003c")}</script>`,
    )
    .join("\n");

jsonld is an array of objects, and each object becomes one script tag. The important part is that every < in the JSON.stringify output is replaced with \u003c. The Gotchas section explains why.

2. Pages just build objects and pass them in

On a word page, the word itself is a DefinedTerm (the schema.org type for a defined term) and the explanation is an Article. This is an excerpt from the actual code:

const altNames = [w.reading, ...w.aliases].filter(Boolean);
const definedTerm = {
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  name: w.word,
  alternateName: altNames.length > 1 ? altNames : w.reading,
  description: w.meaning,
  inDefinedTermSet: {
    "@type": "DefinedTermSet",
    name: site.siteName,
    url: CANON + "/words",
  },
  url: CANON + path_,
};

If a word only has a reading, alternateName stays a plain string. It becomes an array only when the word also has alternative spellings. The Article object follows the same pattern: it skips keywords when there are no tags (...(w.tags.length ? { keywords: ... } : {})) and only sets datePublished when the word has a date. All of those decisions happen while building the object, not while building HTML.

Breadcrumbs appear on every page, so the JSON-LD version is generated by a function from the same array that renders the visible breadcrumb navigation:

function breadcrumbJsonLd(items) {
  return {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    itemListElement: items.map((it, i) => ({
      "@type": "ListItem",
      position: i + 1,
      name: it.label,
      item: CANON + it.href,
    })),
  };
}

Since both the on-page breadcrumb and the structured-data breadcrumb come from the same crumbs array, they cannot drift apart when one of them is edited.

This is the actual output on a generated word page (/word/50-50). The full page has more blocks, so only the BreadcrumbList is shown:

<script type="application/ld+json">{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"トップ","item":"https://kotoba.autoarticles.net/"},{"@type":"ListItem","position":2,"name":"辞書","item":"https://kotoba.autoarticles.net/words"},{"@type":"ListItem","position":3,"name":"50-50","item":"https://kotoba.autoarticles.net/word/50-50"}]}</script>

The three input crumbs come out as ListItem entries with position 1 to 3, on a single line. (The name values are the Japanese labels for "Top" and "Dictionary".)

Gotchas

JSON.stringify alone lets the script tag close early

JSON.stringify gives you valid JSON. It does not give you something that is safe to drop into HTML. The HTML parser does not read the script body as JSON; it closes the tag as soon as it sees </script. If a word's description or a product name ever contains the string </script>, the JSON-LD gets cut off right there and the rest is parsed as HTML.

Here is a minimal script you can run yourself:

const o = { "@type": "DefinedTerm", name: "</script><script>alert(1)</script>" };
const raw = `<script type="application/ld+json">${JSON.stringify(o)}</script>`;
const safe = `<script type="application/ld+json">${JSON.stringify(o).replace(/</g, "\\u003c")}</script>`;
console.log(raw);
console.log(safe);
const body = safe.match(/<script type="application\/ld\+json">([\s\S]*?)<\/script>/)[1];
console.log(JSON.parse(body).name);

Running it with node prints:

<script type="application/ld+json">{"@type":"DefinedTerm","name":"</script><script>alert(1)</script>"}</script>
<script type="application/ld+json">{"@type":"DefinedTerm","name":"\u003c/script>\u003cscript>alert(1)\u003c/script>"}</script>
</script><script>alert(1)</script>

Line 1 (before the replace) has a literal </script> in the middle of the value, which is where the HTML parser closes the tag. In line 2 (after the replace) every < is \u003c, so </script never appears in the HTML. Line 3 shows that \u003c is a JSON string escape, so JSON.parse gives you the original value back. Search engines see exactly the same data; only the HTML structure is protected.

> and & are left alone. What ends a script body is the appearance of </script, so removing < is enough.

Add a test that fails if the replace disappears

To anyone who did not write it, this line looks like a pointless replace, which makes it an easy casualty of a refactor. So test/jsonld-escape.test.js checks two things (run with npm test, which is node --test test/):

It extracts every JSON-LD block from all generated HTML under public/ and asserts that no raw < remains and that each block passes JSON.parse.
It reads the build.js source and asserts that the expression embedding JSON-LD has .replace(/</g, "\\u003c") attached.

Check 1 on its own passes silently whenever the current data happens to contain no <. Check 2 catches the fix being removed regardless of the data. Both also fail when they find no JSON-LD at all, so the test cannot go green by checking nothing.

The result

This is the site that ships JSON-LD this way. Open the source of any word page and you will see the script tags described above: https://kotoba.autoarticles.net

The same one-line replace is also in the build.js of my other sites that are built the same way.

Wrap-up

For JSON-LD on a static site, build plain objects and let head() turn them into script tags. Conditional logic stays on the object side, and the code stays readable.
When embedding with a template literal, always run JSON.stringify(o).replace(/</g, "\\u003c"). Valid JSON and safe-to-embed-in-HTML are two different problems.
Defensive code whose purpose is not obvious should come with a test that fails the moment it is removed.

One service account for 21 GA4 and Search Console properties, with zero dependencies

takahiro hashito — Wed, 16 Sep 2026 13:14:54 +0000

Background

I run 21 small sites and I wanted one command that pulls GA4 (Google Analytics 4) numbers and Search Console numbers for all of them, every night.

Both are reachable through Google APIs, but each site is a separate property. Wire it up naively and you need one authorization per site. Browser-based OAuth is a bad fit for an unattended nightly job: nobody is there to click the consent screen.

So I made one service account (SA) and added it as a viewer on every property. An SA is a Google account for a program rather than a person; if you hold its private key you can mint tokens without a consent screen. Authentication collapsed into a single key file.

This post covers how that collapse was built, and — more importantly — how I misread the numbers it collected.

How it works

Here is the whole path. One key file becomes a JWT (JSON Web Token: a short signed string that asserts "I am this service account"), the JWT is exchanged for an access token, and the same token drives both APIs.

                 ┌───────────────────────┐
  1 SA key ────▶ │ sign an RS256 JWT      │
                 └──────────┬────────────┘
                            │ grant_type=jwt-bearer
                            ▼
                 oauth2.googleapis.com/token
                            │  access_token
             ┌──────────────┴──────────────┐
             ▼                             ▼
   GA4 Data API (runReport)      Search Console API (searchanalytics)
             │                             │
             └──────────────┬──────────────┘
                            ▼
                    per-site JSON (stdout)

No third-party library appears anywhere in that path. I kept dependencies at zero on purpose: googleapis would be easier, but every new machine that runs the nightly job then needs an npm install. Signing a JWT takes nothing but Node's built-in crypto.

Implementation

Getting an access token from the key is the entire trick. The SA JSON holds client_email (the account's address) and private_key (an RSA private key). Below is the part that assembles the JWT and posts it to Google's token endpoint. sa is the parsed key file, now is the current UNIX time in seconds, and b64url is a small Base64URL helper.

const claim = {
  iss: sa.client_email,
  scope: "https://www.googleapis.com/auth/analytics.readonly",
  aud: "https://oauth2.googleapis.com/token",
  iat: now,
  exp: now + 3600,
};
const unsigned = `${b64url(JSON.stringify(header))}.${b64url(JSON.stringify(claim))}`;
const sig = crypto.createSign("RSA-SHA256").update(unsigned).sign(sa.private_key);
const jwt = `${unsigned}.${b64url(sig)}`;

const res = await fetch("https://oauth2.googleapis.com/token", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: new URLSearchParams({
    grant_type: "urn:ietf:params:oauth:grant-type:jwt-bearer",
    assertion: jwt,
  }).toString(),
});

What comes back is an access_token valid for one hour. From there both APIs take the same Authorization: Bearer header, and swapping the scope string is the only change needed to reuse the function for Search Console.

The second change was less glamorous and paid off just as well: one ledger instead of two. The map from site name to numeric GA4 property ID was hardcoded in the fetch script. The same map also lived in the dashboard collector. I diffed all 21 entries and every value matched — but one key was spelled differently (doraemon-tools vs doraemon), and that one site silently failed to resolve.

const PROPERTY_IDS = (() => {
  const { SITES } = require("../dashboard/collect.js");
  const out = {};
  for (const s of SITES) if (s.ga) out[s.key] = String(s.ga);
  return out;
})();

Deriving the map from the collector removed the copy. A side effect: two sites that only existed in the collector's list became fetchable without passing --property by hand.

Gotchas

A missing environment variable wiped out a whole day of measurement. An unattended job does not inherit your interactive shell's environment. GOOGLE_APPLICATION_CREDENTIALS was unset and one night's log was a single line saying GA/SC could not be fetched. I added a fallback to a known key path (~/.config/ga/...). "No env var" and "no key" are different failures.

And the big one: I was reading total sessions as a result.

Some sites had zero rows in their 28-day Search Console query report while GA reported three-digit session counts. Measured on 2026-09-12: blog 146, cve-watch 83, anime-trend 50. If a site has never appeared in search results, then whoever showed up did not arrive through search. They came direct, from a referral, or they were bots. None of that is an SEO result.

The fix was to always pull the channel breakdown (sessionDefaultChannelGroup) and decide reach on the Organic Search figure alone.

function reachVerdict(channels, scImpressions) {
  const organic = Number(channels.organicSearch || 0);
  const total = Number(channels.total || 0);
  const out = {
    organicSearchSessions: organic,
    totalSessions: total,
    nonSearchSessions: Math.max(0, total - organic),
    scImpressions: scImpressions ?? null,
    reached: organic > 0,
  };
  if (organic === 0 && total > 0) {
    out.verdict = "not-reached";
  } else if (organic > 0) {
    out.verdict = "reached";
  } else {
    out.verdict = "no-sessions";
  }
  return out;
}

Three states, not two: not-reached (people arrive, but not from search), reached (search delivers), and no-sessions (nobody came at all). The old code folded the first and the last into a single "has sessions / has none" test, which is exactly how not-reached got read as success.

One detail I care about: when the Search Console figure cannot be fetched, it is not filled in with 0.

const sc = scImpressions === undefined || scImpressions === null
  ? null
  : Number(scImpressions);

A missing measurement and a measured zero are different facts. Writing 0 turns a day when the API was down into a day with zero impressions, and a week later that ledger shows a decline that never happened. It stays null, and the verdict text says so explicitly.

The result

A site that runs on this: https://hashitosystem.com

Wrap-up

One SA added to every property reduces unattended auth to a single key file. Signing the JWT needs only Node's crypto, so the dependency count stays at zero
Two copies of the same lookup table will drift in spelling even when every value matches. Derive it from one source
A session count is not evidence that search brought anyone. Pull the channel breakdown and judge on Organic Search
Never store a failed fetch as 0. Once a gap and a real zero share a type, you cannot tell them apart later

Generating per-article og:image with headless Chrome and zero npm dependencies

takahiro hashito — Mon, 14 Sep 2026 14:44:21 +0000

The problem

I run about twenty small sites that publish new articles every day through an automated pipeline. For a long time every single article on every single site shared one identical og:image.

og:image is the <meta property="og:image" content="..."> tag that decides which picture shows up when someone pastes your URL into X or Slack. When three of your articles land in the same timeline with the same picture, they read as one article. Whatever is different about them never gets across.

There are three obvious ways to fix this:

Call a hosted image-generation API (pay per image)
Add an image library such as sharp or canvas
Emit SVG and point og:image at it

Option 3 is out: the major social platforms do not render SVG for og:image. X and Slack both ignore it and fall back. Option 1 costs money that scales with article count. Option 2 pulls in a native build step, and I run this pipeline on both macOS and Windows, so I did not want one more thing that breaks differently per platform.

What I ended up with: lay the card out in HTML and CSS, then let the Chrome that is already installed take a screenshot of it. Zero npm dependencies, zero recurring cost. Here is how it works, plus the four traps I walked into.

The pipeline

The flow from an article's metadata to the meta tag on the published page looks like this:

article metadata (title / badge / accent / siteLabel / domain / expired)
  ↓  templateHtml()           … build a fixed 1200×630 HTML+CSS page
temp file og.html
  ↓  Chrome --headless=new --screenshot --window-size=1200,820
PNG (820px tall, padding at the bottom)
  ↓  cropPngHeight()          … cut to the top 630 rows using only Node's zlib
public/articles/<slug>.og.png
  ↓  each site's build.js      … uses this PNG if present, otherwise a shared image
the published page's <meta property="og:image">

Every step is deterministic: the same metadata always produces byte-identical output. The only inputs are the site's data/site.json and data/articles.json. One article's metadata renders one card. The caller looks like this:

const { generateOgImages } = require('./automation/scripts/ogp/generate-og.js');

await generateOgImages([
  {
    out: 'public/articles/campaign-famima-asa-combiwari.og.png',
    title: 'ファミマ朝5時〜11時「コンビ割」9月15日開始',
    badge: '最大145円引き',
    accent: '#6f4e37',
    siteLabel: 'コーヒーのセール情報',
    mark: '珈',
    domain: 'coffee.autoarticles.net',
    note: '価格・在庫は変動。最新はAmazonでご確認ください。',
    expired: false,
  },
]);

The interesting parts

Let CSS do the drawing

There is not a single line of image-manipulation code in here. The gradient, the rounded badge, the diagonal light streaks, the "expired" ribbon — all of it is CSS.

const grad = expired
  ? 'linear-gradient(135deg,#8a8f94,#6b7075)'          // expired deals go grey
  : `linear-gradient(135deg,${escHtml(accent)},${escHtml(endColor)})`;

The title font size steps down as the title gets longer, and -webkit-line-clamp:3 caps it at three lines. Those two rules alone eliminated overflow in practice:

h1{
  font-size:${fontPx}px; line-height:1.28;
  display:-webkit-box; -webkit-line-clamp:3; -webkit-box-orient:vertical; overflow:hidden;
}

The real payoff of staying in CSS is that you can iterate on the layout in a browser. Open the same HTML in your local Chrome and you see essentially the output. You do not get that if you are computing coordinates against an imaging library.

Take the shot

The assembled HTML goes into a temp file, and Chrome is launched exactly once to capture it. chromeBin() lazily resolves the browser binary, out is the destination PNG path, and htmlPath is the og.html written into a temp directory:

execFileSync(chromeBin(), [
  '--headless=new',
  '--disable-gpu',
  '--hide-scrollbars',
  '--no-sandbox',
  '--force-device-scale-factor=1',
  '--window-size=1200,820',
  `--screenshot=${out}`,
  fileUrl(htmlPath),
], { stdio: 'ignore' });
cropTopLeft(out, 1200, 630);

After that single call, out holds a 1200×820 PNG, and cropTopLeft trims it to the top 1200×630. The publishable file is finished at that point.

--force-device-scale-factor=1 is not optional. Without it a HiDPI machine hands you 2400×1260 and every downstream crop is wrong.

Do not redraw what has not changed

A hash of the input parameters is stored next to the PNG as <name>.og.hash, and a match means skip:

const hashPath = out.replace(/\.png$/i, '') + '.og.hash';
const h = hashOf(it);                       // `out` is excluded from the hash on purpose
if (!opts.force && fs.existsSync(out) && fs.existsSync(hashPath)) {
  if (fs.readFileSync(hashPath, 'utf8').trim() === h) { skipped++; continue; }
}

This matters more than it sounds. A real daily build logs:

[og] coffee: 生成 4 / スキップ 152 / 計 156

Four of 156 articles were redrawn — the ones actually touched that day. Chrome startup costs 0.5–1s per image, so rendering all 156 every day would add over two minutes to the nightly run.

Four traps

1. `--window-size` height is the viewport height

Passing --window-size=1200,630 does not give you 630px. Chrome's --headless --screenshot treats window height as viewport height, but the captured image can extend to the full page height, leaving padding at the bottom.

The fix is to shoot big and crop: capture at --window-size=1200,820, then cut to the top 630 rows.

2. Cropping without an imaging library

sharp would make this one line, but that breaks the zero-dependency premise. Reading the PNG spec, it turns out Node's built-in zlib is enough for this specific case.

PNG pixel data is stored as scanlines, each prefixed by a one-byte filter type, all concatenated and deflated into the IDAT chunks. Crucially, a filter only ever references rows above it. So if you inflate the stream and keep the first targetH rows, what you have is a valid image of the top targetH rows — no recompute needed.

const channels    = colorType === 6 ? 4 : 3;   // 6=RGBA, 2=RGB
const bytesPerRow = 1 + width * channels;      // leading byte is the filter type
const raw     = zlib.inflateSync(Buffer.concat(idat));
const cropped = raw.subarray(0, targetH * bytesPerRow);   // top targetH rows

const newIhdr = Buffer.from(ihdr);
newIhdr.writeUInt32BE(targetH, 4);             // patch only the height in IHDR
const out = Buffer.concat([
  PNG_SIG,
  pngChunk('IHDR', newIhdr),
  ...passthrough,
  pngChunk('IDAT', zlib.deflateSync(cropped, { level: 9 })),
  pngChunk('IEND', Buffer.alloc(0)),
]);

You do have to compute the chunk CRC32 yourself, but that is another thirty lines. Anything the code cannot handle — interlaced, non-8-bit depth, palette — throws instead of guessing. Chrome always emits 8-bit non-interlaced RGB/RGBA, so this holds in production.

This trick only covers vertical cropping. Cropping horizontally means cutting inside each row, which changes the bytes-per-row and makes the problem meaningfully harder. Here the width already matches the window width, so height is all that is needed.

3. Windows produced zero images, silently

This one hurt. The list of candidate Chrome paths contained no Windows entries at all. On a Windows box with Chrome plainly installed, the resolver threw "Chrome/Chromium not found."

Worse, the caller swallowed that exception and returned exit 0. Each site's build.js has a deliberately safe fallback: use the per-article PNG if present, otherwise the shared site image. So with generation totally dead, the build still succeeded, pages still shipped, and og:image quietly stayed on the shared image. Nothing in the logs said otherwise.

The fix came in two parts:

Split out a pure function. chromeCandidates(env, platform, homedir) only assembles candidate paths and never touches the filesystem; findChrome() takes that list and checks existence. Now a test running on macOS can assert that Windows candidates are produced.
Drop the fallback. If the binary cannot be resolved, fail.

4. The same shape of bug, somewhere else

There was a second instance. Passing --site <key> resolves the site through a task definition's repoPath (e.g. /Users/hashito/git/web/coffee). On Windows that macOS-absolute path is interpreted as drive-relative, so it resolves against whatever drive the process happens to be on and does not exist. The old code then silently fell back to a different clone of the site.

That clone also has a data/ directory, so generation succeeded. The log said success. But that tree is never deployed, so nothing reached production.

The fix: path.resolve to pin the drive before dispatching, and fail when the site cannot be resolved. The fallback to a different tree is gone; --dir exists for the case where you genuinely want to point elsewhere.

The result

One of the sites running on these generated og:images: https://blog.hashito.biz

Takeaway

If a process has a fallback, count how often the fallback fires and print it. Of the four traps above, the hard one was #2 (cropping PNG with nothing but zlib), but the expensive ones were #3 and #4. In both cases a well-intentioned "safe fallback" concealed the fact that generation had died completely.

A fallback limits the damage when something goes wrong; it is not evidence that nothing went wrong. Print generated / skipped / total on every run and "generated 0, skipped 0" jumps out of the log immediately. That single line is the difference between an implementation that tells you it is broken and one that ships the same placeholder image for weeks.

Your CVSS >= 7.0 filter is silently dropping the CVEs you most want

takahiro hashito — Sun, 13 Sep 2026 13:43:21 +0000

The problem: too much input

A CVE (Common Vulnerabilities and Exposures) is the globally unique ID assigned to a single vulnerability, in the form CVE-2026-85706. The NVD (National Vulnerability Database, run by the US government) collects them, and it registers anywhere from a few dozen to well over a hundred entries per day. Reading all of that by hand is not an option for a side project.

So I wrote a collector that keeps only the serious ones. CVSS (Common Vulnerability Scoring System) rates severity from 0.0 to 10.0, where 7.0 and above is High and 9.0 and above is Critical. It is a number, so a machine can cut on it.

The first version of that cut threw away exactly the entries I cared about most. This post is about where the threshold belonged.

The shape of the collector

Two sources feed one merge step:

                     ┌──────────────────────────┐
  CISA KEV ─────────▶│ diff against known IDs   │
  (exploited)        │ (data/vulns.json)        │──▶ new candidates
  NVD ──────────────▶│                          │
  (last N days)      └──────────────────────────┘

CISA KEV (short for Known Exploited Vulnerabilities Catalog) is a list of entries that CISA has confirmed are being exploited in the wild. It ships as a single JSON file. NVD is the full database, queryable by date range and severity.

The rule I settled on:

The OR is the whole point.

What went wrong

The obvious implementation merges first and filters once:

// first version (wrong)
const candidates = [...fromKEV(), ...fromNVD()];
const filtered = candidates.filter((c) => c.cvssScore >= 7.0);

Run that and zero KEV entries survive. The KEV feed has no CVSS field at all. Here is a real record:

{
  "cveID": "CVE-2026-85706",
  "vendorProject": "GitLab",
  "product": "Community Edition and Enterprise Edition",
  "vulnerabilityName": "GitLab Community Edition and Enterprise Edition Path Traversal Vulnerability",
  "dateAdded": "2026-09-11",
  "dueDate": "2026-09-14",
  "knownRansomwareCampaignUse": "Unknown"
}

No cvssScore. In JavaScript, undefined >= 7.0 is false, so every KEV candidate is dropped. No exception. Nothing in the logs. The count just goes to zero.

And what was being dropped was the highest priority half of the input. KEV membership means the vulnerability is being exploited right now, not that a scoring rubric says it could be bad. A 6.5 that attackers are using outranks a 9.8 that nobody has touched. A filter meant to keep the serious items was deleting the ones under active attack.

The fix: push the filter into the source

The filter moves out of the merge step and into each fetcher. The KEV fetcher below reads the catalog JSON, sorts by dateAdded descending, and skips only IDs already present in known (the set of CVE IDs the site has published). There is no score comparison anywhere in it.

// KEV source: no CVSS cut. Confirmed exploitation is the evidence.
async function fromKEV(known, max) {
  const data = await getJSON(KEV_URL);
  const vulns = (data && data.vulnerabilities) || [];
  vulns.sort((a, b) =>
    String(b.dateAdded || "").localeCompare(String(a.dateAdded || "")),
  );
  const out = [];
  for (const v of vulns) {
    const id = String(v.cveID || "").toUpperCase();
    if (!id || known.has(id)) continue;
    out.push({ cveId: id, source: "CISA KEV", /* ...trimmed... */ });
    if (out.length >= max) break;
  }
  return out;
}

// NVD source: not in KEV, so the score is the only evidence. Enforce 7.0 here.
for (const it of items) {
  const m =
    (metrics.cvssMetricV31 && metrics.cvssMetricV31[0]) ||
    (metrics.cvssMetricV30 && metrics.cvssMetricV30[0]);
  const cvss = m && m.cvssData ? m.cvssData.baseScore : null;
  if (cvss != null && cvss < 7.0) continue;
  out.push({ cveId: id, source: "NVD", cvssScore: cvss, /* ...trimmed... */ });
}

The NVD loop is the other half of the same file. It walks the API results, pulls the base score out of whichever CVSS metric block is present (v3.1 first, v3.0 as fallback), and applies the 7.0 cut there and only there.

The cvss != null guard matters. NVD occasionally serves an entry with no score yet (still being analysed). Those are kept rather than dropped: "cannot be judged by score" must not collapse into "fails the score check", or you have built the same silent-deletion path a second time.

Output after the fix:

$ node automation/scripts/cve/fetch-critical.js --max 3 --days 7
{
  "generatedFrom": ["CISA KEV", "NVD(last 7 days)"],
  "knownCount": 317,
  "candidates": [
    { "cveId": "CVE-2026-85706", "source": "CISA KEV", "vendorProject": "GitLab",  ... },
    { "cveId": "CVE-2026-86060", "source": "CISA KEV", "vendorProject": "MikroTik", ... },
    { "cveId": "CVE-2026-67277", "source": "CISA KEV", "vendorProject": "MikroTik", ... }
  ],
  "errors": []
}

Every candidate carries source, so the evidence behind each pick is auditable later. Without it there is no way to check whether the rule was right.

Two things that bit me

1. The NVD API returns ancient CVEs unless you pass dates.

Query with cvssV3Severity=CRITICAL alone and you get the head of the registration order, which is CVEs from around 2002. I was collecting "new critical vulnerabilities" and receiving twenty-year-old ones.

pubStartDate and pubEndDate must be sent as a pair, and the span is capped at 120 days. Ordering is not guaranteed either, so sort by publication date yourself after fetching.

function nvdUrl(days) {
  const span = Math.min(Math.max(Number(days) || 30, 1), 120);
  const end = new Date();
  const start = new Date(end.getTime() - span * 24 * 60 * 60 * 1000);
  const iso = (d) => d.toISOString().replace(/\.\d{3}Z$/, ".000");
  const q = new URLSearchParams({
    cvssV3Severity: "CRITICAL",
    resultsPerPage: "40",
    pubStartDate: iso(start),
    pubEndDate: iso(end),
  });
  return `https://services.nvd.nist.gov/rest/json/cves/2.0?${q}`;
}

2. "Could not fetch" and "found nothing" must not look alike.

Same failure shape as the threshold bug. A dropped connection or a rate limit both produce "0 candidates" if you write it naively, and the caller cannot tell that apart from a genuinely quiet day.

So errors are collected instead of swallowed, and a non-empty error list sets the exit code:

result.newCount = result.candidates.length;
if (result.errors.length > 0) process.exitCode = 1;
process.stdout.write(JSON.stringify(result, null, 2) + "\n");

A successful fetch that returned nothing exits 0 with errors: []. The caller can now treat the two cases differently. Never let a missing measurement pass as a green result.

Demo

One of the sites running this collector: https://cve.autoarticles.net

Takeaway

Cutting noise with a threshold was the right idea. The mistake was where the cut lived.

Generalised: write filters per data source, not over the merged set. Merge first and apply one shared condition, and every source lacking that field disappears completely and silently. Here that was the one source I could least afford to lose.

Before you make a field part of a condition, confirm it always exists on that path. If it might not, spell out the != null case so "unknown" does not collapse into "rejected". And always report a fetch failure through a different exit than a measured zero.

Decoding a UUID by hand: version, variant, and the embedded timestamp

takahiro hashito — Sat, 12 Sep 2026 13:42:36 +0000

Background

A UUID (Universally Unique Identifier) is a 128-bit value written as 32 hex digits, used as an identifier that will not collide across systems. I run a small UUID generator on a personal tools site. Recently I added the other half: paste a UUID in, and it tells you which version it is, which variant it belongs to, and — when the version carries one — the timestamp baked into it.

The reason was practical. IDs arriving from other systems come with no documentation. When you generate them yourself you know the scheme; when you receive them you are guessing. The spec makes this mechanically decidable, so I wrote the reader.

What this post is actually about is not the feature. It is how I convinced myself the decoder was correct, which turned out to be the interesting part.

How it works

A UUID is 32 hex digits. The canonical form groups them 8-4-4-4-12 with hyphens, but for reading you want the hyphens gone and a flat 32-character string.

Only two positions matter for classification (0-based indices into that flat string):

What	Index	Meaning
version	12	the UUID scheme (1/3/4/5/6/7/8)
variant	16	which family of specs this UUID belongs to

"Variant" is the less familiar one. UUIDs have several historical lineages, and the variant bits say which. Everything in normal use today is the RFC 4122 variant (carried forward by RFC 9562), meaning the top two bits of nibble 16 are 10.

Three versions embed a timestamp: v1, v6 and v7. This is where it gets awkward, because the epoch and the unit differ by version:

v7: the first 48 bits are milliseconds since the Unix epoch. Read them as a number, done.
v1 / v6: 100-nanosecond intervals since 1582-10-15, and in v1 the 60-bit timestamp is split across three fields stored out of order.

v4 is random and v3/v5 are name hashes, so there is no time to recover.

Implementation

Dependency-free JavaScript. Normalize the input, read the variant, then branch per version to recover the time. Hyphenated, unhyphenated, uppercase and brace-wrapped GUID strings all show up in practice, so everything that is not a hex digit is stripped before the length check.

const GREG_OFFSET_MS = 12219292800000; // ms between 1582-10-15 and 1970-01-01

function normalize(raw) {
  return String(raw).replace(/[^0-9a-fA-F]/g, "").toLowerCase();
}

function variantOf(nibble) {
  if ((nibble & 0x8) === 0) return "NCS (legacy)";
  if ((nibble & 0xc) === 0x8) return "RFC 4122 / RFC 9562";
  if ((nibble & 0xe) === 0xc) return "Microsoft GUID (legacy)";
  return "reserved for the future";
}

function inspect(raw) {
  const hex = normalize(raw);
  if (hex.length !== 32) return { input: raw, error: "not 32 hex digits" };
  const ver = parseInt(hex.charAt(12), 16);
  const variant = variantOf(parseInt(hex.charAt(16), 16));
  let unixMs = null;
  if (ver === 7) {
    unixMs = parseInt(hex.slice(0, 12), 16);
  } else if (ver === 1 || ver === 6) {
    const hi = hex.slice(0, 8), mid = hex.slice(8, 12), high = hex.slice(13, 16);
    const tick = ver === 1 ? BigInt("0x" + high + mid + hi)
                           : BigInt("0x" + hi + mid + high);
    unixMs = Number(tick / 10000n) - GREG_OFFSET_MS;
  }
  return { input: raw, version: ver, variant, unixMs,
           utc: unixMs == null ? null : new Date(unixMs).toISOString() };
}

Three things carry the weight here.

Test the variant masks from narrow to wide. & 0x8, then & 0xc, then & 0xe — the masks widen from one to three bits, so this order is the only correct one. Check Microsoft first and you will misclassify ordinary RFC UUIDs.
v7 needs no BigInt. 48 bits is about 2.8e14, comfortably inside Number.MAX_SAFE_INTEGER (2^53), so parseInt is enough.
v1 needs BigInt and a re-ordering. v1 splits its 60-bit timestamp into time_low (first 8 digits), time_mid (next 4) and time_hi (3 digits right after the version nibble). To rebuild it you concatenate high-to-low: time_hi + time_mid + time_low. v6 is v1 with those fields already in ascending order, so the concatenation reverses.

The final Number(tick / 10000n) - GREG_OFFSET_MS converts 100-ns Gregorian ticks to Unix milliseconds: divide by 10000 for ticks-to-ms, then subtract the 12219292800000 ms between 1582 and 1970.

Gotchas

How do you know code written from a spec is right? That is the real problem. Slide a field boundary by one digit and you do not get an obviously broken value — you get a plausible different date. And writing your own unit tests does not help, because you also author the expected values. If your reading of the spec is wrong, your test is wrong in exactly the same way.

What worked was agreement between two independent paths. RFC 9562 publishes one v1 example and one v7 example, and they are constructed to denote the same instant. Two completely different encodings, decoded by two completely different branches of my code — if they land on the same moment, both branches are validated at once.

Here is the run:

{"input":"017f22e2-79b0-7cc3-98c4-dc0c0c07398f","version":7,"variant":"RFC 4122 / RFC 9562","unixMs":1645557742000,"utc":"2022-02-22T19:22:22.000Z"}
{"input":"C232AB00-9414-11EC-B3C8-9F6BDECED846","version":1,"variant":"RFC 4122 / RFC 9562","unixMs":1645557742000,"utc":"2022-02-22T19:22:22.000Z"}
{"input":"9f1a7c54-8f3e-4b2a-b9d1-6e2c5a0f77aa","version":4,"variant":"RFC 4122 / RFC 9562","unixMs":null,"utc":null}
{"input":"{0199A9C0000070008000000000000000}","version":7,"variant":"RFC 4122 / RFC 9562","unixMs":1759489556480,"utc":"2025-10-03T11:05:56.480Z"}
{"input":"00000000-0000-0000-0000-000000000000","version":0,"variant":"NCS (legacy)","unixMs":null,"utc":null}

Line 1 is the v7 example, line 2 the v1 example. Both came out as 2022-02-22T19:22:22.000Z. The parseInt path and the BigInt re-ordering path arrived independently at the same answer. Get either field layout wrong and that agreement disappears.

Two more findings from the same run:

Line 4: {0199A9C0000070008000000000000000} — brace-wrapped, unhyphenated, uppercase — decodes identically, because normalization runs first. Without it, every GUID pasted out of a Windows tool would be rejected.
Line 5: the nil UUID (all zeros) reports version: 0 and variant: "NCS (legacy)". That is not a bug; it is what those bits literally say. But surfacing it as "a legacy NCS UUID" is misleading, because nil means "no value". Bit extraction and human-facing labels belong in separate layers — I had collapsed them. The shipped tool now special-cases nil and max (all f) before classification.

The result

A site that runs on this: https://hashitosystem.com/tools/uuid/

Generation (v1 / v4 / v7, up to 1000 at a time) and inspection live on the same page. Classification and time math happen entirely in the browser; pasted UUIDs are never sent to a server.

Wrap-up

Classifying a UUID comes down to reading two of its 32 digits. Order the variant masks narrow-to-wide, re-order v1's split timestamp before handing it to BigInt, and the implementation stays short.

The verification is the part worth keeping. Code written straight from a spec cannot be validated by tests you wrote from the same reading. Look for a case where the spec encodes one fact two different ways, and check that your two code paths agree. When two unrelated routes reach the same answer, your own misreading cannot explain it.

Why I dropped the X API for an IFTTT webhook - and what it cost me

takahiro hashito — Fri, 11 Sep 2026 13:36:09 +0000

Introduction

I run a small bot that announces updates to my own sites on X.
My first plan was to use the X API. I ended up dropping it and posting through an IFTTT webhook instead.

IFTTT is a SaaS that connects "when A happens, do B". One of its inputs is Webhooks: you get a URL,
you send one HTTP request to it, and the applet you configured runs. In other words, you get
"one HTTP call posts to X" without app registration or token refresh code.

This post is about what that trade bought me, what it cost me, and how I covered the cost.
Short version: what I gave up was confirmation that the post actually happened, and the fix was
to measure it through a separate path.

The overall shape

Three pieces:

Generate - build the announcement text from the day's updated articles and push it into a local queue.json, each item carrying a scheduledAt timestamp.
Post - a launchd job (launchd is the macOS service manager: you drop an XML plist file and it handles daemons and scheduled jobs, filling the role systemd and cron do on Linux) wakes every 30 minutes and sends only the items whose time has come.
Verify - read the public timeline separately and count what actually landed.

Generation and posting are split so the posts can be spread over a time window. If you generate and
send in the same pass, everything goes out at the same minute.

The core of the implementation

Sending is short. The IFTTT webhook takes fixed field names, value1 through value3.

const url = `https://maker.ifttt.com/trigger/${event}/with/key/${key}`;
const payload = { value1: tweetText };
if (imageUrl) payload.value2 = imageUrl;
const response = await axios.post(url, payload, {
  headers: { 'Content-Type': 'application/json' }
});

With the X API, this is where OAuth 1.0a signing or OAuth 2.0 refresh-token handling would live,
plus app registration. For a personal announcement bot that was the heaviest part. The webhook removes it.

The problem starts after this line. The code above looks successful whenever it gets a 200.
But the IFTTT webhook returns 200 when:

the applet is turned off
the X connection has been revoked
you have hit the free-tier applet limit

The webhook is answering "I accepted the event", not "the applet ran" and certainly not "it is on X".
I missed this, and my logs showed a 100% success rate the entire time delivery was completely dead.

I fixed it in two steps. First, stop looking only at the status code.

static extractError(data) {
  if (data == null) return null;
  if (typeof data === 'object') {
    const errs = Array.isArray(data.errors) ? data.errors : null;
    if (errs && errs.length) {
      return errs.map(e => (e && e.message) || String(e)).join(' / ');
    }
    return null;
  }
  const text = String(data);
  if (/"errors"\s*:/.test(text)) {
    try { return IFTTTService.extractError(JSON.parse(text)); }
    catch (e) { return text.slice(0, 200); }
  }
  if (/invalid key|not found|rate limit|too many requests/i.test(text)) {
    return text.slice(0, 200);
  }
  return null;
}

IFTTT can return an error in the body while the status stays 200. Send a key with one character
changed and you get HTTP 200 plus {"errors":[{"message":"You sent an invalid key."}]}; the function
above pulls that string out.

Second, split the names. Instead of one success flag, the call returns accepted and published.
accepted means the request was taken. published means it is live - and published is always
null (unknown), because the webhook cannot tell you.

Not writing true for something you cannot observe was the single most useful decision here.

Things that bit me

The posting job runs under macOS launchd with StartInterval set to 1800 (every 30 minutes).

<key>ProgramArguments</key>
<array>
    <string>/Users/hashito/.nodebrew/current/bin/node</string>
    <string>/path/to/src/index.js</string>
    <string>--process</string>
</array>
<key>EnvironmentVariables</key>
<dict>
    <key>PATH</key>
    <string>/Users/hashito/.nodebrew/current/bin:/usr/local/bin:/usr/bin:/bin</string>
</dict>
<key>StartInterval</key>
<integer>1800</integer>

node is an absolute path because launchd does not go through a login shell, so the nodebrew PATH
from .zshrc never arrives. The only evidence was node: command not found in the log. Setting
PATH explicitly in EnvironmentVariables fixed it.

The other one: a Mac sleeps. An interval job does not fire while asleep. launchd runs the missed
invocation after wake, so if the queue is ordered by time, the backlog drains on wake in order.
Give up on holding the interval, and let the queue hold the ordering - then sleep turns from a
failure into a delay.

The result

One of the sites this bot announces: https://gadget.autoarticles.net

Takeaway

Dropping the X API for a webhook removed all the auth code. It also removed the answer to
"did it post?".

Generalised: always check how far an external service's success response actually reaches.
If a response only guarantees "accepted" and you record it as "completed", you lose the ability to
detect breakage. Measure the unguaranteed part through another path, or at minimum keep it as
null / unknown. The moment you fill it with true, your monitoring starts lying to you.

Let the sitemap decide which URLs your bot is allowed to announce

takahiro hashito — Thu, 10 Sep 2026 13:40:50 +0000

The problem

I run about 20 small content sites that update themselves daily, and a bot announces each day's new articles on X. Every so often the announcement pointed at a URL that returned 404.

The cause was easy to find. The bot built announcement URLs from my own bookkeeping. The daily job writes "today I added this slug" (a slug being the short string that identifies an article) into state.json, and the bot glued that slug onto the site's base URL.

That is a lie in disguise. The ledger proves that the job intended to add a page. It does not prove the page is live. If the build failed halfway, or the deploy did not finish, the ledger row is still there. An announcement must not trust the ledger.

So I changed the rule: the bot may only announce URLs that appear as a <loc> in the site's own sitemap.xml.

The design

sitemap.xml is the site declaring, publicly, which pages exist. It is meant for search engines, but as a list of live pages it is far more trustworthy than my ledger. It is a build artifact, so a failed build leaves it stale, and an undeployed build never reaches production at all.

The pipeline became:

Take today's slugs from the ledger (state.json).
Fetch https://<site>/sitemap.xml and parse it into a list of <loc> values.
Find a <loc> containing the slug. Only those become announcement candidates.
If a site resolves zero candidates, report the count and drop the site.

Step 3 failing means "in the ledger, not published." Do not announce it.

The core of it

Resolving a slug to a real URL is a plain substring match. locs below is the array of URLs pulled from the sitemap:

_resolveSlugUrl(slug, locs) {
  if (!slug) return null;
  const matches = locs.filter(u => u.includes(slug));
  if (matches.length === 0) return null;
  // prefer the article itself over /tags/ and other index pages
  const preferred = matches.find(u => !/\/tags?\//i.test(u));
  return preferred || matches[0];
}

Returning null on no match is the whole point. The tempting "helpful" version — fall back to building the URL from the base path — puts you right back where you started.

The /tags/ branch came out of real runs. Most of these sites publish /tags/<same word as the slug>, so the tag index matches before the article does. Tag pages return 200, so a pure liveness check cannot reject them. They exist; they are just not what I meant to announce.

Where it broke

One site resolved zero candidates every single day while publishing normally. Its article URLs share no characters with the ledger index. The ledger holds CVE (Common Vulnerabilities and Exposures — the globally unique identifier assigned to a single known security flaw) numbers, while the public URLs look like /article/post_<epoch_ms>_<random>. Measured on 2026-08-20: of 1338 <loc> entries, 0 contained a CVE ID.

The mechanism was behaving exactly as specified. It was also silently discarding a site that published every day.

The fix had two parts. First, count what you drop: sites that ended with zero candidates now show up in the report as {key:"ai-news", added:1, tried:3} — "one article added, three strategies tried, nothing resolved." That line is what made the problem visible at all. Second, add a fallback that reads <lastmod> (each page's last-modified timestamp) and treats same-day entries as today's publications — with a guard:

const dated = entries.filter((e) => e.lastmod && lastmodJstDate(e.lastmod) === logDate);
if (dated.length === 0) return [];
/* If *every* page carries today's lastmod, the site regenerated itself.
 * That is not the same as "these pages were written today." */
if (dated.length / entries.length > 0.5) return [];

One site regenerates all 26 of its pages daily, so every lastmod is today's date. Calling those "new articles" would be a lie to readers, hence the ratio guard. The CVE site, by contrast, had exactly one same-day lastmod, matching the ledger's "1 added."

There was also a timezone bug worth naming. <lastmod> is UTC (2026-09-04T21:23:46.517Z), my calendar day is JST, and I was comparing slice(0, 10) of both. Articles published between 00:00 and 09:00 JST never matched. Announcements silently vanished on nights the job ran late — a wonderfully hard bug to reproduce on purpose.

Liveness, in three states

The final check does an actual HTTP request, and its verdict is deliberately not a boolean:

const evaluate = (status) => ({
  ok: status >= 200 && status < 400,
  status,
  definitive: status >= 400 && status < 600,   // genuinely broken
  reason: status >= 200 && status < 400 ? 'ok' : `http-${status}`
});

definitive is set only when a numeric 4xx/5xx came back. A timeout or DNS failure leaves it false. "Broken" and "could not determine" must not collapse into one value, or a transient network blip permanently evicts a perfectly good page — quietly, which is the worst part.

One of the live sites: https://manga.autoarticles.net

Takeaway

Derive outward-facing correctness from the published artifact, never from your own records. Your records prove intent; the sitemap proves publication. And whenever you add a filter, count what it removes and print that count — a rejection nobody counts is indistinguishable from a rejection that never happened.

A dependency-free snapshot dashboard: http.server + sqlite3, and the ALTER TABLE trap

takahiro hashito — Wed, 09 Sep 2026 13:37:59 +0000

Background

I run more than twenty small sites as a solo developer. Publishing is automated; looking at the results was not. Google Analytics and Search Console are both fine for one site, but opening two consoles per site, aligning the date ranges, and remembering yesterday's number does not scale to twenty. I stopped doing it after three days.

So I put a small server on a Mac mini at home and started pushing every site's numbers to it a few times a day. It uses only the Python standard library, http.server and sqlite3. There is no pip install step, no framework, and nothing to keep updated.

This post is about the storage design, and specifically about one decision that paid off and one bug it caused.

How it works

Three pieces, nothing else.

A collector (Node) gathers Analytics and Search Console numbers for every site into one JSON object.
It sends that object to POST /api/ingest, authenticated with a single shared token in an X-Token header.
The Python server appends it to SQLite and serves the dashboard HTML from GET /.

The whole server boot is this:

from http.server import ThreadingHTTPServer, BaseHTTPRequestHandler
import sqlite3, json

if __name__ == "__main__":
    init_db()
    ThreadingHTTPServer(("0.0.0.0", PORT), H).serve_forever()

ThreadingHTTPServer rather than plain HTTPServer because the plain one is sequential: the browser's favicon request blocks the HTML response. Even with a single viewer, opening two tabs makes it feel broken.

The ingest handler returns the id of the row it just created:

def do_POST(self):
    if self.path != "/api/ingest":
        return self._send(404, "not found", "text/plain")
    tk = token()
    if not tk or self.headers.get("X-Token") != tk:
        return self._send(401, json.dumps({"error": "unauthorized"}), "application/json")
    n = int(self.headers.get("Content-Length", "0"))
    payload = json.loads(self.rfile.read(n) or b"{}")
    return self._send(200, json.dumps({"ok": True, "snapshot_id": ingest(payload)}), "application/json")

Returning snapshot_id is the design in one line. Each push creates a new row rather than updating an existing one.

Implementation

One snapshot = one parent row plus N child rows

The schema below is what init_db() runs on every boot. snapshots holds one row per push, and site_metrics holds one row per site within that push, linked by snapshot_id:

CREATE TABLE IF NOT EXISTS snapshots(
    id INTEGER PRIMARY KEY AUTOINCREMENT, ts TEXT, ts_jst TEXT, gcp_cost TEXT, meta TEXT);

CREATE TABLE IF NOT EXISTS site_metrics(
    snapshot_id INTEGER, site_key TEXT, label TEXT, url TEXT,
    ga_sessions_y REAL, ga_users_y REAL, ga_pv_y REAL,
    sc_clicks REAL, sc_impressions REAL, sc_ctr REAL, sc_position REAL, added INTEGER);

CREATE INDEX IF NOT EXISTS idx_sm_snap ON site_metrics(snapshot_id);

So a push of 23 sites writes 1 row into snapshots and 23 into site_metrics, all carrying the same snapshot_id. site_metrics deliberately has no primary key. A row is not "the current state of a site", it is "how that site looked at that push". Dozens of rows per site_key is the correct state. Nothing is ever updated or deleted; reads always filter by the latest snapshot_id, which is why the index is on that column.

Adding a metric is one ALTER TABLE

Metrics always grow. This table started with a handful of columns and now has 29, after splitting organic search out of total sessions, then adding a per-channel breakdown, then a traffic-quality figure.

Append-only storage makes that cheap, because nothing has to be backfilled:

def ensure_columns(c, table, cols):
    """Idempotent migration: ALTER TABLE ADD COLUMN only for columns that are missing.
    Existing rows are never rewritten; the new column is NULL for them, which is correct."""
    have = {r["name"] for r in c.execute(f"PRAGMA table_info({table})").fetchall()}
    for name, decl in cols:
        if name not in have:
            c.execute(f"ALTER TABLE {table} ADD COLUMN {name} {decl}")

PRAGMA table_info(<table>) is SQLite's introspection query: it returns one row per column. Building the set of existing names and adding only what is missing makes the function idempotent, meaning it can run on every boot and produce the same result no matter how many times it has run before.

The important part is that NULL on old rows is semantically right. A July snapshot has no organic-search column because that metric did not exist yet, not because the value was zero.

That distinction is enforced end to end: a failed fetch stores NULL, a measured zero stores 0. Collapse both into 0 and a flat line in the chart becomes unreadable forever after, because nothing tells you whether traffic died or collection did.

And that is exactly what breaks positional INSERT

Cheap column additions mean frequent column additions. And INSERT INTO t VALUES(?,?,?) names no columns, so it breaks the moment the column count changes.

Here is a reproduction I actually ran:

import sqlite3
c = sqlite3.connect(":memory:")
c.execute("CREATE TABLE m(snapshot_id INTEGER, site_key TEXT, clicks REAL)")
c.execute("INSERT INTO m VALUES(?,?,?)", (1, "coffee", 3))
print("before ALTER:", c.execute("SELECT * FROM m").fetchall())

c.execute("ALTER TABLE m ADD COLUMN impressions REAL")
print("after ALTER :", c.execute("SELECT * FROM m").fetchall())

try:
    c.execute("INSERT INTO m VALUES(?,?,?)", (2, "beer", 5))
except Exception as e:
    print("positional INSERT ->", type(e).__name__, e)

c.execute("INSERT INTO m(snapshot_id,site_key,clicks) VALUES(?,?,?)", (2, "beer", 5))
print("named INSERT ok  :", c.execute("SELECT * FROM m").fetchall())

Output:

before ALTER: [(1, 'coffee', 3.0)]
after ALTER : [(1, 'coffee', 3.0, None)]
positional INSERT -> OperationalError table m has 4 columns but 3 values were supplied
named INSERT ok  : [(1, 'coffee', 3.0, None), (2, 'beer', 5.0, None)]

Three things to take from that. ALTER TABLE ADD COLUMN does not damage existing rows. The new column is NULL for them. And the unnamed INSERT fails from the very next write onward.

It does not fail for one site. Every site goes through the same statement, so the entire push fails. The change that caused it was a display change, which puts the cause and the symptom far apart.

The fix is to define the column list once and build the SQL from it:

SITE_METRIC_COLS = ["snapshot_id", "site_key", "label", "url",
                    "ga_sessions_y", "ga_users_y", "ga_pv_y", "ga_sessions_7d", "ga_pv_7d",
                    "sc_clicks", "sc_impressions", "sc_ctr", "sc_position", "added",
                    "ga_organic_y", "ga_organic_7d", "ga_organic_engaged_7d"]

sm_sql = ("INSERT INTO site_metrics(" + ",".join(SITE_METRIC_COLS) + ") VALUES("
          + ",".join("?" * len(SITE_METRIC_COLS)) + ")")

Adding a column now touches three places: the CREATE TABLE, the ensure_columns list, and SITE_METRIC_COLS. Three sounds like a lot, but forgetting one fails loudly and immediately instead of silently reaching production.

Gotchas

"It works today" is not evidence that positional INSERT is safe. As the repro shows, there is no warning until the first write after a column is added. Name columns from the start in any table you expect to grow.
Separate NULL from 0 on day one. You cannot reconstruct the difference later; a stored 0 gives you nothing to decide with. Watch the collector too, where a ?? 0 default quietly destroys it.
http.server is sequential. Switching to ThreadingHTTPServer is a one-line fix, but until you do, one favicon request stalls the page.
ALTER TABLE ADD COLUMN is a metadata-only operation in SQLite, so it is fast regardless of row count. The flip side is that no default is written into existing rows. For this design, not writing one was the correct behaviour.

The result

A live example of the sites this dashboard tracks: https://hashitosystem.com

Wrap-up

Store operational metrics as append-only snapshots. Adding a metric costs one ALTER TABLE ADD COLUMN, no observation is ever rewritten, and NULL keeps its natural meaning of "not measured then".

In exchange, never use INSERT INTO t VALUES(?,?,?) in a table whose columns will grow. Keep the column list as a constant and generate the statement from it. If you make adding columns cheap, pair it with writes that survive the addition.

My English page shipped with Japanese error messages, because the logic owned the strings

takahiro hashito — Wed, 09 Sep 2026 13:32:14 +0000

Background

I ship small single-file browser tools. Every tool has a Japanese page and an English page, and the rule I set for myself is that the two pages share the exact same logic. Same functions, same parsing, same edge cases. Only the wording differs.

Today I added a Cache-Control analyzer and shipped it. Then I opened the English page and the result panel said this:

Browser cache
  Freshness lifetime  365d
  Remaining           365d
  State               新鮮

新鮮 means "fresh". The labels were English, the values were Japanese.

The mistake was in what the shared function returned

The shared analyzer looked like this. analyze() takes a Cache-Control value and returns freshness plus a list of findings.

var DIRECTIVES = {
  "max-age": { arg: "delta", who: "both",
    desc: "応答が新鮮でいられる秒数。Age を差し引いた残りで判定されます。" },
  "no-store": { arg: "none", who: "both",
    desc: "どのキャッシュにも保存させない。最も強い指定です。" },
  // ...
};

function freshness(limit, age) {
  if (limit === null) return { lifetime: null, state: "指定なし（ヒューリスティックに委ねられる）" };
  var rem = limit - age;
  return { lifetime: limit, remaining: rem, state: rem > 0 ? "新鮮" : "古い（要再検証）" };
}

Both pages loaded this same file, and each page defined its own label table:

// on the English page
var L = { browser: "Browser cache", lifetime: "Freshness lifetime", state: "State" };

So the page owned the labels and the logic owned the values. That split looked fine while I was writing it, and it is exactly the bug. The English page had no way to say "fresh", because the only place that word existed was inside a Japanese string literal in the shared file.

Nothing failed. No console error, no missing key, no fallback. The page rendered perfectly in two languages at once.

What I changed

I pulled every human-readable string out of the logic and turned it into a message pack the page supplies. The logic keeps the branching; the page keeps the wording.

The message pack below is generated per language and concatenated in front of the shared logic, so MSG and DIRTEXT are already in scope when the parser runs.

// generated per language, concatenated before the shared logic
var DIRTEXT = {
  "max-age": "How many seconds the response stays fresh. Freshness is measured against Age.",
  "no-store": "No cache may store the response at all. This is the strongest directive."
};
var MSG = {
  stHeuristic: "Not set (left to heuristics)",
  stFresh: "Fresh",
  stStale: "Stale (needs revalidation)",
  noCacheMaxAge: function (n) {
    return "no-cache is present, so every reuse revalidates even though max-age=" + n + ".";
  }
};

DIRTEXT is keyed by directive name and feeds the explanation shown under each directive; MSG holds everything else the parser needs to say. The shared logic then reads like the code below, where limit is the max-age in seconds and age comes from the Age response header.

// shared logic, now with no literals a reader can see
function freshness(limit, age) {
  if (limit === null) return { lifetime: null, state: MSG.stHeuristic };
  var rem = limit - age;
  return { lifetime: limit, remaining: rem, state: rem > 0 ? MSG.stFresh : MSG.stStale };
}

The branching is untouched. The only difference is that the three outcomes now name a key instead of spelling out a word, so the English page renders "Fresh" and the Japanese page renders the same state in Japanese from the same call.

Messages that interpolate a number became functions rather than templates with placeholders. That is deliberate: word order differs between the two languages, and a function lets each language put the number wherever it belongs instead of forcing both into one sentence shape.

I checked the result with a grep over the shared file. Zero lines containing CJK characters, apart from one code comment. If a Japanese literal ever comes back, that check finds it.

The part I did not expect

The obvious win is the English page being English. The unexpected win was that writing the two message packs side by side made me reread every message.

Three of them were vague in Japanese and I only noticed while translating. One said the equivalent of "this directive does not work", which is not useful. Writing the English version forced me to say why: private stops shared caches from storing the response, so s-maxage has no audience. I then rewrote the Japanese one to match.

Translation turned out to be a review pass I had not budgeted for.

The rule I am keeping

A shared function that returns a display string has silently chosen a language for every caller. If some callers are in a different language, that choice is a bug, and it is a bug that renders fine.

So: return keys, or take the strings as a parameter. Either way, the page decides the words.

Both tools are here:

https://hashitosystem.com/en/tools/cachecontrol/

If you maintain a page in more than one language, grep your shared modules for literals in your own first language today. Anything that comes back is a string your other pages cannot translate, and it will ship looking fine.

DEV Community: takahiro hashito

I merged three tools with 301 redirects on Firebase Hosting, and every old URL now takes two hops

Background

The setup

Seeing every hop

Confirming the fix on a site with the same settings

Why bother about one extra hop

Takeaway

My SRI hash was correct and the browser still blocked the script: line endings and the strongest-hash rule

Background

What SRI checks

Trap 1: pasted text is not the file

Trap 2: only the strongest hash counts

What I would do

CVE-2026-81642: a DNSKEY compression pointer overflows Unbound's digest buffer

Background

What the bug is

Am I in scope

What I can do before patching

The fix

Looking for signs you were hit

Order I would do it in

Embedding JSON-LD in a static site with template literals, and the one escape you cannot skip

Background

How it works

Implementation

1. head() turns the array into script tags

2. Pages just build objects and pass them in

Gotchas

JSON.stringify alone lets the script tag close early

Add a test that fails if the replace disappears

The result

Wrap-up

One service account for 21 GA4 and Search Console properties, with zero dependencies

Background

How it works

Implementation

Gotchas

The result

Wrap-up

Generating per-article og:image with headless Chrome and zero npm dependencies

The problem

The pipeline

The interesting parts

Let CSS do the drawing

Take the shot

Do not redraw what has not changed

Four traps

1. --window-size height is the viewport height

2. Cropping without an imaging library

3. Windows produced zero images, silently

4. The same shape of bug, somewhere else

The result

Takeaway

Your CVSS >= 7.0 filter is silently dropping the CVEs you most want

The problem: too much input

The shape of the collector

What went wrong

The fix: push the filter into the source

Two things that bit me

Demo

Takeaway

Decoding a UUID by hand: version, variant, and the embedded timestamp

Background

How it works

Implementation

Gotchas

The result

Wrap-up

Why I dropped the X API for an IFTTT webhook - and what it cost me

Introduction

The overall shape

The core of the implementation

Things that bit me

The result

Takeaway

Let the sitemap decide which URLs your bot is allowed to announce

The problem

The design

The core of it

1. `--window-size` height is the viewport height