Slik publiserer vi til nettsiden uten admin-innlogging

Jeg publiserte denne artikkelen uten å logge inn på en nettside. Det finnes ingen admin-side på fmcybersecurity.com, ingen /login, ingen /forgot-password-flyt, ingen brukertabell. Jeg åpnet Claude Desktop på laptopen, gikk gjennom utkastet med Claude, og ba om publisering. MDX-en traff GitHub-repoet vårt, Cloudflare bygde siden på nytt, og artikkelen lå live etter rundt 90 sekunder.

Dette er publiseringsflyten for hver konsulent i FM CyberSecurity som er autorisert til å publisere. Samme Claude Desktop, samme laptop, samme MCP-server som vi skrev selv.

I fjor kjørte jeg fire gjennomganger av kundenes web-plattformer. Hver gang spiste publiseringsflyten uker av prosjekttiden. Å legge til en redaktør var en sak. Å fjerne en var en ny sak, pluss et passord-tilbakestill, pluss en vurdering av lisens-sete. CMS-en var flaskehalsen på en prosess som burde vært en Git-commit. Vi bygde rundt det.

Sist gjennomgått 2026-05-12 av Fredrik Standahl.

TL;DR: FM har ingen admin-grensesnitt på nettsiden. Forfattere publiserer gjennom Claude Desktop som kaller fm-publisher-mcp, en Cloudflare Worker vi skrev selv, sluset gjennom Microsoft Entra-gruppemedlemskap. MCP-en committer MDX og forsidebilde til GitHub atomisk. Ny artikkel er live etter rundt 90 sekunder. Tre gevinster: færre sårbarheter (ingen admin, ingen brukertabell, ingen passord), raskere publisering (skriv i Claude, live på 90 sekunder), og bedre innhold per utkast fordi Claude kjører en skill vi skrev med FM sine voice-regler bakt inn.

Slik publiserer en konsulent i dag

Slik ser det ut når jeg publiserer. Jeg åpner Claude Desktop på laptopen og trykker Connect på fm-publisher-mcp. En lokal OAuth-handler åpner en nettleserfane mot Microsoft. Har jeg allerede en aktiv M365-session, hoppes prompten over. Microsoft returnerer en auth-kode til Cloudflare Worker-en vår, som bytter den mot et access-token, validerer JWT-en mot Entras JWKS-endpoint, og kaller Microsoft Graph for å sjekke om jeg fortsatt står i Entra-gruppen “FM Publishers”.

Er svaret ja, utsteder Worker-en sitt eget access-token (1 times TTL) og refresh-token (30 dagers TTL) til Claude. Jeg skriver eller reviderer artikkelen i Claude Desktop, ber Claude publisere, og Claude kaller write_article på MCP-en med MDX-kropp og forsidebilde i ett kall. Worker-en committer begge filer til GitHub gjennom Git Data API som én atomisk commit. MDX og forsidebilde lander sammen, eller ingen av dem. Cloudflare-bygget plukker opp commiten og bygger siden på nytt. Ny artikkel er live etter rundt 90 sekunder.

Jeg ser fire øyeblikk i den flyten. Åpne Claude Desktop, trykke Connect, skrive utkastet, be Claude publisere. De andre fem stegene går uten oppmerksomheten min.

Stacken under

fm-publisher-mcp kjører på en Cloudflare Worker. Den eksponerer åtte verktøy (list_articles, read_article, create_article, update_article, unpublish_article, pluss tre for angreps-listen). Cloudflares pakke @cloudflare/workers-oauth-provider håndterer OAuth 2.1-serversiden. Mekleren mot Microsoft Entra skrev vi selv, rundt 450 linjer TypeScript, slik at Worker-en kan bytte en brukers Entra-identitet mot sitt eget bearer-token uten å holde på et passord.

Det finnes ett Workers KV-namespace, OAUTH_KV. Der ligger token Worker-en har utstedt. Brukerdata ligger ikke der. Vi har ingen users-tabell, ingen e-post-til-passord-map, ingen profilstore. Den eneste persisterte tilstanden om en publisist er token-utløpsraden, og den raden fordamper innen 30 dager etter siste bruk.

Selve nettsiden kjører på Astro 6 med output: static, deployet til Cloudflare Pages. Astro 6 kom i mars 2026, og Astro-teamet sitter nå inne i Cloudflare etter oppkjøpet i januar 2026, noe som betyr at rammeverket og hosten deler veikart. Cloudflare folder Pages inn i Workers, og vi migrerer den dagen kostnaden ved å bli liggende blir høyere enn kostnaden ved å flytte.

Deployer er atomiske. Cloudflares egen dokumentasjon kaller dem nettopp det. Når bygget lykkes, kutter den nye versjonen over i én operasjon. Når det feiler, fortsetter forrige versjon å levere trafikk. Vi har aldri mistet en forespørsel til en deploy. Tilbakerulling til et tidligere bygg er ett klikk i Pages-dashbordet, eller ett API-kall fra terminalen når vi trenger det derfra. Time-to-first-byte fra norske byer måler 30 til 50 ms.

Hva dette gir oss

Ingen admin-innlogging på fmcybersecurity.com. Ingen flate å phishe, ingen /login å brute-force, ingen session-cookie å stjele, ingen SSO-knapp på offentlig side å peke et phishing-kit mot. Nettsiden autentiserer ingen, fordi nettsiden ikke trenger det.

Ingen brukertabell. Hvem som kan publisere lagrer vi ikke, det gjør Microsoft Entra. Å legge til en publisist er ett klikk i Entra (legg til i “FM Publishers”). Å fjerne en er ett klikk i Entra. Innenfor Worker-ens access-token-TTL slår endringen inn. Slutter personen i FM og M365-kontoen deaktiveres, dør hvert eksisterende token de holder neste gang det presenteres, fordi JWT-valideringen feiler mot de roterte nøklene.

Audit trail er Git. Hver commit til site-repoet navngir både den menneskelige forfatteren (hentet fra Entra-tokenet) og bot-committeren (fm-publisher[bot]). Auditten er git log. Vi kjører ingen parallell publiserings-event-database, og vi trenger ingen.

Null passord lagret noe sted i denne stacken. Vi kjører ingen /forgot-password-flyt, for det finnes ingenting å gjenopprette. Autentisering er delegert ende-til-ende til Microsoft Entra, som allerede håndterer MFA, conditional access, device compliance, og resten av M365-kontrollene vi allerede betaler for.

Bedre innhold per utkast. Vi skrev en Claude-skill (fm-website-writer) som koder FM sine voice-regler, bannede ord, seks artikkeltype-maler, SEO- og GEO-mekanikk, og markedsføringsdisiplin under markedsføringsloven. Claude kjører den skill-en på hvert utkast inne i denne MCP-en. Første gang vi leser et utkast, sitter strukturen, de bannede ordene er borte, SEO-frontmatteren er fylt ut. Det menneskelige reviewet handler om argumentet, ikke om å fjerne “leverage” eller em-dasher for n-te gang.

Det finnes også en innkjøpsside av dette. Driver en nettside-leverandør en brukerdatabase, må du signere en databehandleravtale og bære revisjonen. Gjør de det ikke, slipper du. Mindre flate, mindre papirarbeid, mindre ansvar.

Vær ærlig om hva slags side du har

Dette bytteforholdet finnes fordi vi valgte et problem med et statisk svar. En konsulentvirksomhets nettside personaliserer ingenting, godtar ingen besøkende-innlogginger, kjører ingen kasse. Innhold flyter sakte nok til at menneskelig review er flaskehalsen, ikke deployen.

En side som personaliserer per besøkende, godtar brukerkontoer eller behandler betalinger er et annet problem. Det blir en kjørende applikasjon. Greit, da bygger du den som det, ikke bolter statisk på toppen.

Poenget er ikke at statiske sider er enklere. Poenget er å skille det som må kjøre på en server fra det som er en fil, og legge autentiseringen ett lag opp i identitetsleverandøren du allerede driver. De fleste B2B-markedssider er filer. Publiseringsflyten er den eneste delen som må autentisere noen, og den autentiseringen må ikke ligge på selve nettsiden.

Eier du en B2B-markedsside på en CMS i dag, er spørsmålet ikke om du skal migrere. Spørsmålet er om driftskostnaden (lisens, patcher, admin-innlogging som identitetsflate, vendor-risiko ved hver CMS-oppdatering) betaler for funksjoner du bruker. Skriv ned funksjonene. Som oftest er listen kortere enn regningen.

• Les vår artikkel om å levere ISO 27001-bevis uten prosess-teater.
• Send dette videre til plattformsjefen og CISO-en din.
• Send meg en melding for en 30-minutters gjennomgang av stacken din.

Skrevet med AI-assistanse, gjennomgått og redigert av Fredrik Standahl og FM-redaksjonen.