DEV Community: Koray KÖYLÜ

npm trust github Fails with 400 Bad Request: The Missing Permission Flag

Koray KÖYLÜ — Sat, 22 Aug 2026 21:46:35 +0000

We published a JavaScript client to npm this week, and wiring up trusted publishing cost three failed attempts and two wasted two-factor approvals before the real cause turned up. The command failed with a bare 400 Bad Request and no explanation, in the CLI output and in the debug log alike. The fix is one flag. Finding out which flag took an hour, because the npm version that knows about it is the only thing that will tell you.

If you landed here from that error, the short answer is at the top of the next section. The rest explains why it happens, which npm versions are affected, and the two other traps waiting on the same path.

Why does npm trust github return 400 Bad Request?

Because your npm CLI is older than 20 May 2026 and is sending a trust configuration that no longer satisfies the registry. On that date npm started requiring every trusted publisher configuration to name at least one allowed action, and it shipped the CLI flags for it the same day. An older CLI does not know the field exists, sends the old payload, and the registry rejects it without saying what is missing.

The fix is to run a newer npm and pass the flag:

npm trust github \
  --file publish.yml \
  --repository your-org/your-repo \
  --environment npm \
  --allow-publish

On a current npm the same mistake is diagnosed properly. Instead of a 400 you get:

npm error At least one permission flag is required (--allow-publish, --allow-stage-publish)

Which npm versions are affected?

We pinned the boundary by running the same dry run against each version. It is exact:

npm 11.14.1 (8 May 2026) and older: accepts the command, sends a payload with no permissions field, and the registry answers 400 Bad Request with no body.
npm 11.15.0 (20 May 2026) and newer: refuses client side and names the missing flag.

The machine we hit this on had npm 11.11.0, shipped in February 2026, three months before the rule changed. That is recent enough to feel current and old enough to fail silently, which is the worst combination.

Worth noting for anyone debugging this: nothing on the wire tells you either. The verbose log records http fetch POST 400 and the stack trace, and that is all. There is no error body to read, so the usual instinct of increasing log level does not help.

What if you cannot upgrade npm globally?

This is a real corner. npm 12 requires Node 24.15.0 or newer, and if your Node is even slightly behind, the upgrade is refused:

npm error notsup Not compatible with your version of node/npm: npm@12.0.2
npm error notsup Required: {"node":"^22.22.2 || ^24.15.0 || >=26.0.0"}
npm error notsup Actual:   {"node":"v24.14.1","npm":"11.11.0"}

A global install can also need elevated permissions you would rather not use for a one off command. You do not have to install anything. Run a newer npm directly:

npx -y npm@11.19.0 trust github \
  --file publish.yml \
  --repository your-org/your-repo \
  --environment npm \
  --allow-publish

Pick the newest npm that still supports your Node. The trust command talks to the registry, so it does not matter which npm your project normally uses.

Why can OIDC not publish the first version?

This is the trap before the trap. Trusted publishing is configured from an existing package's settings page, so the package has to exist before OIDC can be attached to it, which means OIDC cannot perform a package's first publish. You publish version one manually, then attach the trusted publisher, and every release after that goes through CI with no token.

If you have used PyPI, this will surprise you. PyPI lets you register a pending publisher for a name that does not exist yet, so the very first release can go out through OIDC with no manual step. npm has no equivalent.

One thing to be careful about when you read up on this: npm's own trusted publishing documentation does not state the limitation either way. It simply assumes you already have a package. The constraint is documented in npm/cli issue 8544, which is open, and the publish-once-then-attach workaround is what every third party guide recommends. Do not write it up as confirmed by the npm docs, because it is not.

Why is the two-factor URL hidden?

Both npm publish and npm trust require a second factor, and when npm cannot open a browser it prints the approval URL for you to open yourself. Except in a non-interactive shell it redacts it:

npm error This operation requires a one-time password.
npm error Open this URL in your browser to authenticate:
npm error   https://www.npmjs.com/auth/cli/***

The redaction is in the debug log too, so there is nowhere to recover it from. If you are driving npm from a script, a CI shell, or any context without a TTY, allocate a pseudo-terminal and the URL comes through in full:

printf '\n' | script -q /dev/null npm publish --access public --auth-type=web

The printf answers npm's "Press ENTER to open in the browser" prompt, which makes it open the browser directly. Two practical notes: the approval link expires after a few minutes, so only run this when someone is actually at the keyboard, and the command sits waiting while it polls, so a short timeout will kill it before anyone can approve.

The sequence that works

For a brand new package, start to finish:

Create the public repository and add a publish workflow triggered on release: published, with id-token: write permission and an environment set.
Create that environment in the repository settings. It can be empty, with no protection rules.
Publish version one manually with npm publish --access public, approving the two-factor prompt.
Attach the trusted publisher with npm trust github, including --allow-publish, approving two-factor again.
Every release after that publishes itself. No token is stored anywhere and no second factor is requested.

Verify with npm trust list <package>. A successful configuration prints the type, the repository, the workflow file, the environment and the permissions, so you can see exactly what the registry accepted.

One last thing on the first publish, since you only get one shot at it looking right: run npm publish --dry-run and read the file list. It is the cheapest way to catch a package that ships its source, its tests, or its lockfile because a files entry was missing.

Why we were doing this

The package that triggered all of this is @ibanchecker/client, the JavaScript and TypeScript client for the ibanchecker.cash API. It validates IBANs across 92 countries, resolves the bank behind an account, and looks up BIC codes, with no runtime dependencies and both ESM and CommonJS builds. There are Python and PHP clients as well, and those two publish through OIDC on their own registries, which is what made the npm difference so noticeable.

If you just want to check an IBAN without installing anything, the validator is free and needs no account.

Sources

npm Docs: trusted publishing, including allowed actions and the 20 May 2026 change
npm/cli issue 8544: allow publishing the initial version with OIDC
npm/cli pull request 9248: add permissions support to trust commands
GitHub Changelog: npm trusted publishing with OIDC is generally available

A payment QR code is just twelve lines of text

Koray KÖYLÜ — Wed, 12 Aug 2026 04:56:12 +0000

If you have paid an invoice in Europe recently, you have probably pointed your banking app at a small square and watched it fill in the payee, the IBAN and the amount by itself. I run ibanchecker.cash and I spent the last few weeks on both sides of those squares: generating them and reading them back. The format turned out to be far simpler than most people expect, and a couple of its rules surprised me even after years around IBANs.

What is actually in there

The standard is EPC069-12, published by the European Payments Council. German banks market the result as a GiroCode. There is no binary framing and no JSON. The payload is plain text, twelve elements separated by line breaks. This is the exact content of the code on the cover image:

BCD
002
1
SCT
COBADEFF
Webajans Bilisim Ltd
DE89370400440532013000
EUR149.00


Invoice 2026-014

Line	Element	In this code
1	Service tag	always `BCD`
2	Version	`002`, which makes the BIC optional
3	Character set	`1` means UTF-8
4	Identification	`SCT`, a SEPA Credit Transfer
5	BIC	`COBADEFF`
6	Beneficiary name	who gets paid
7	IBAN	the account
8	Amount	currency glued to the value
9	Purpose	empty here
10	Structured reference	empty here
11	Unstructured reference	free text
12	Beneficiary to originator	may be absent entirely

A few rules worth knowing before you implement any of this. The whole payload must fit in 331 bytes. The name is capped at 70 characters and the reference at 140. The amount is euro only, from 0.01 to 999,999,999.99; the standard simply has no concept of another currency. Error correction must be level M. And there is no signature anywhere: nothing in the code proves who produced it, which is worth remembering the next time a QR sticker appears on a parking meter.

The field we got wrong

Line 6 is the beneficiary name. The account holder. The person or company the money goes to.

The first version of our generator wrote the detected bank name there. Scan such a code and your banking app politely suggests paying "Commerzbank" instead of the person behind the account. It ran like that for about three weeks before we caught it. If you take one thing from this article: line 6 is the payee, never the bank. It is an easy mistake to make because the bank name is usually the string you have just resolved from the IBAN and it is sitting right there in a variable.

Rebuilding the generator

The old tool had a Generate button. The new one updates the code live as you type, which sounds cosmetic but changes how people use it: you see the code grow as the reference gets longer, and you see the byte counter move toward the 331 limit.

Exports are SVG, high resolution PNG and a vector PDF. The PDF was the fun part: a QR code is nothing but rectangles, so instead of pulling in a PDF library we walk the SVG path data and emit the rectangles into a hand-written PDF. Zero dependencies. Dropping a logo into the center automatically raises error correction to H.

One design decision I want to defend explicitly: if you enter an amount in a currency other than the euro, the tool still generates the code but tells you plainly that banking apps outside SEPA may not read it. The alternative, silently producing something that looks official, felt wrong.

Reading codes back

The newer tool is the reverse: drop in a picture of a payment QR and it lists all twelve elements with their byte counts, measured against the limits the standard sets. Decoding happens entirely in the browser with a dynamically imported jsQR; the image is never uploaded anywhere. The bytes are re-decoded with whatever character set the payload declares, so an ISO 8859 umlaut survives.

The IBAN inside then runs through the same engine as the rest of the site: country, length, national structure, the ISO 13616 check digits, the national account check digit where a country defines one (25 countries so far; for Germany that means the per-bank Prüfziffer methods, for the UK the VocaLink modulus check) and a directory lookup for the bank and its BIC.

Two rules were fixed before the first line of code. The image never leaves the browser. And decoded text is never rendered as a clickable link, because QR phishing works precisely by making that tap convenient.

One honest limitation: Swiss QR-bills are recognized but not parsed. They follow a different standard from SIX, not the EPC one, and mapping their fields onto the EPC layout would be guessing dressed up as decoding.

About the cover image

The QR on the cover is real. I generated it with the first tool and verified it by feeding the finished image back into the second one. The IBAN in it is the well-known documentation example, DE89 3704 0044 0532 0130 00, not a live account.

Both tools are free and need no signup: the generator and the decoder.

We built a free ipify alternative - here's what we learned

Koray KÖYLÜ — Fri, 12 Jun 2026 20:23:26 +0000

If you've ever needed your public IP in a script, you've probably typed this:

curl api.ipify.org

ipify is one of those quiet pieces of internet infrastructure. Launched in 2014, it answers one question — "what is my public IP?" — so simply that it ended up embedded in millions of scripts and apps, serving billions of requests a month. Respect.

But a while ago I noticed something while browsing its GitHub repo: the last code change was January 2018. Community pull requests — CORS headers, Docker support, even one-line README fixes — have been sitting unanswered for years. The hosted service still runs (it's commercially operated by WhoisXML API), but the open-source project that made developers trust it is effectively frozen. And geolocation was never part of the free deal — it's a separate paid product.

That gap looked like an invitation. We run whatsmy.fyi, an IP and network info tool, and we decided to build the thing we wished existed. Here's what we shipped and — more usefully — what we learned along the way.

What we built

A keyless endpoint that's deliberately compatible with ipify's response format:

# Plain text
curl https://whatsmy.fyi/ip
# → 203.0.113.42

# JSON — identical shape to api.ipify.org
curl "https://whatsmy.fyi/ip?format=json"
# → {"ip":"203.0.113.42"}

Swapping it into existing code is a one-URL change. No key, no signup, CORS enabled, IPv4 + IPv6, nothing logged.

When you need more than the bare IP, a free API key (10,000 requests/day) returns city, country, coordinates, timezone, ASN, and ISP — the data ipify sells separately. There's also a TypeScript SDK with a keyless mode:

import { WhatsMyFyi } from '@whatsmyfyi/sdk'

const client = new WhatsMyFyi()           // no key needed
const ip = await client.ip.address()      // "203.0.113.42"

Lesson 1: friction decides everything in this category

Our API originally required a key for everything. Reasonable, right? Usage tracking, rate limits, dashboards.

Wrong — at least for this use case. The entire reason curl api.ipify.org won the internet is that it works before you've decided to care. A developer comparing IP APIs closes the tab the moment they see "sign up first." We realized the keyless endpoint wasn't a nice-to-have; it was the price of admission. The authenticated API now earns its keep as the upgrade path, not the front door.

Lesson 2: the edge changed the economics

ipify's era required choices: serving geolocation means licensing a GeoIP database, updating it, and eating lookup latency. Charging for geo made sense in 2014.

Running on Cloudflare Workers changed that math for us. Every request already arrives with geolocation, ASN, and timezone attached (the request.cf object) — data from the network itself, with no external database call. Serving "rich" IP data now costs us roughly the same as serving the bare IP. That's not cleverness on our part; it's a structural shift that makes the old free-IP/paid-geo split feel dated.

Lesson 3: honesty is a feature you can ship

We published a comparison page covering ipify, icanhazip, ip-api.com, ipapi.co, and ipinfo — and we verified every claim by calling each API ourselves (ip-api.com really does reject HTTPS on the free tier; ipapi.co really did 429 our first request). The page also lists the places where competitors beat us, and recommends icanhazip for shell scripts and ipinfo for enterprise needs, because that's the truth.

This felt risky to write. But developers can smell a rigged comparison table from a mile away; an honest one is rare enough to be memorable — and it gives every claim on the page a "verify it yourself" quality that no marketing copy can match.

Lesson 4: maintenance is the moat

Here's the uncomfortable part: nothing we built is technically hard. A keyless IP endpoint is a weekend project. What ipify's story actually demonstrates is that the hard part is still being there — answering issues, merging PRs, shipping releases — years after the launch excitement fades.

So we wrote the only durable differentiator we could into our CONTRIBUTING.md: every issue and PR gets a human response within a few days. If we ever stop honoring that, someone should build the whatsmy.fyi alternative — and they'd be right to.

IP geolocation with zero external APIs, the Cloudflare Workers cf object

Koray KÖYLÜ — Wed, 10 Jun 2026 12:49:39 +0000

When I built whatsmy.fyi, I assumed I'd need a geolocation provider: MaxMind, ipinfo, ip-api, pick your poison. They all mean the same thing: an external dependency, an API key, a quota, added latency, and someone else's server seeing your users' IPs.

Then I found out Cloudflare Workers makes the whole category unnecessary.

The `cf` object

Every request that hits a Cloudflare Worker carries a request.cf object, populated at the edge before your code even runs. No lookup, no latency, no key. Here's what's inside:

{
  asn: 34984,                    // ISP's autonomous system number
  asOrganization: "Superonline", // ISP name
  city: "Istanbul",
  region: "Istanbul",
  country: "TR",
  continent: "AS",
  isEUCountry: undefined,        // "1" if EU, undefined otherwise
  latitude: "41.01380",          // string, not number!
  longitude: "28.94970",
  postalCode: "34000",
  timezone: "Europe/Istanbul",
  colo: "IST",                   // which CF datacenter handled this
  clientTcpRtt: 12,              // user's RTT to the edge, in ms
  httpProtocol: "HTTP/3",
  tlsVersion: "TLSv1.3",
  tlsCipher: "AEAD-AES128-GCM-SHA256"
}

That last group surprised me most: you get the user's HTTP protocol, TLS version, and actual TCP round-trip time for free. Try getting that from a geo API.

A complete IP endpoint in ~30 lines

export default {
  async fetch(request) {
    const cf = request.cf ?? {};
    const ip = request.headers.get("CF-Connecting-IP");

    return Response.json({
      ip,
      city: cf.city ?? null,
      country: cf.country ?? null,
      isp: cf.asOrganization ?? null,
      asn: cf.asn ?? null,
      timezone: cf.timezone ?? null,
      lat: cf.latitude ? parseFloat(cf.latitude) : null,
      lng: cf.longitude ? parseFloat(cf.longitude) : null,
      protocol: cf.httpProtocol ?? null,
      tls: cf.tlsVersion ?? null,
      rttMs: cf.clientTcpRtt ?? null,
    });
  },
};

That's the entire backend. No database, no GeoIP file to update monthly, no vendor.

The gotchas (learned the hard way)

1. Coordinates are strings. latitude: "41.01380" — parse them or your JSON consumers will suffer.

2. Every field can be missing. Tor exits, some corporate proxies, and brand-new IP ranges come through with sparse data. Null-check everything:

const city = typeof cf.city === "string" ? cf.city : null;

3. isEUCountry is the string "1" or undefined. Not a boolean. You've been warned.

4. Local dev gives you an empty object. wrangler dev (and Next.js dev servers behind adapters) won't populate most fields. Guard for it, and test geo logic in preview deployments.

5. City-level accuracy is "usually right, sometimes hilarious." Same as every IP geolocation source, this data comes from the same underlying registries. Country is reliable; city is best-effort. Don't build anything that requires city precision.

The privacy angle

This architecture has a property I didn't fully appreciate until I wrote the privacy policy: the user's IP never leaves the request path. There's no third-party geo provider receiving your traffic logs as a side effect. Combined with not writing logs yourself, you can honestly say: nothing is stored, nothing is shared. That's the whole privacy section.

For whatsmy.fyi this is the entire data pipeline: the site, the free API, all of it runs on request.cf and nothing else. Sub-50ms TTFB, zero external calls, zero logs.

If you're on Workers and calling a geo API today, check request.cf first. The data was already there before you asked.

I built a "what is my IP" site because I was tired of the ugly ones

Koray KÖYLÜ — Thu, 28 May 2026 15:39:14 +0000

I use "what is my IP" sites maybe once a month. Every time I end up on something covered in ads, calling three different tracking APIs, and showing me results I don't fully understand. So I spent a weekend building whatsmy.fyi.

The thing I didn't expect: you don't need an IP geolocation API at all if you're on Cloudflare Workers. Every request comes with a cf object that already has your city, country, ISP, TLS version, HTTP protocol, and RTT. Free. Zero latency.

The part I enjoyed most was the WebRTC leak test. It checks whether your browser is exposing your real IP through RTCPeerConnection even when you're on a VPN. I ran it on my own setup. It was leaking.

Zero logs. Zero storage. Just your data, shown to you.

https://whatsmy.fyi