Die Konfiguration beschreibt, was sein soll. Der State merkt sich, was bereits echt existiert.

Beide sind Dateien mit Ressourcen drin, deshalb hält man sie für dasselbe. Doch sie beantworten verschiedene Fragen: den Soll-Zustand und den Ist-Stand.

Die Konfiguration ist der Bauplan: In Terraform-Dateien steht in deklarativer Sprache, was entstehen soll, etwa eine Security-Group, also eine Firewall-Regelgruppe in AWS. Sie beschreibt Eigenschaften, aber keine konkreten Cloud-Objekte. Ein Beispiel: eine Regel, die einen Port für HTTPS freigibt. Terraform liest sie bei jedem Lauf neu ein.

Der State ist das Gedächtnis von Terraform: eine Datei, die für jede Ressource der Konfiguration festhält, welche echte Ressource in der Cloud dazugehört, etwa über deren konkrete ID. Steht dort eine Security-Group mit einer ID, kennt Terraform genau dieses Objekt. Fehlt der State, kann Terraform bestehende Ressourcen nicht mehr verwalten.

Die Konfiguration ist der Wunsch, der State die Zuordnung zur Wirklichkeit. Beim Plan vergleicht Terraform drei Dinge – Konfiguration, State und reale Ressourcen – und leitet daraus die Änderungen ab.

Faustregel: Wer Änderungen plant, braucht zuerst einen aktuellen State, sonst sind Plan und Wirklichkeit auseinander. Deshalb liegt der State zentral in einem Remote-Backend wie S3, einem Speicher, den alle Beteiligten gemeinsam nutzen.

Vorsicht: Der State kann Passwörter im Klartext enthalten und ist wie ein Geheimnis zu schützen. Löschen ist keine Aufräumlösung, sondern verwirft nur das Gedächtnis und erzeugt Duplikate.

Der State ist nicht die Konfiguration, sondern das Gedächtnis, das beide verbindet. Ohne ihn weiß Terraform nicht, was es selbst angelegt hat.

📌 Konfiguration · State · Remote-Backend

📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops #CloudSecurity

Viele geben beiden Sonden denselben Endpunkt und glauben, gut gerüstet zu sein. Dabei verursacht genau das die Neustartschleifen, die eine Anwendung in den Ausfall treiben.

Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.

Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.

Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.

Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.

Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.

Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.

📌 Liveness vs. Readiness · Kubelet · failureThreshold 3

📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre

npm funktioniert wie eine Einkaufsliste, die der Lieferdienst selbst abruft. Dabei schreibt niemand die Bausteine selbst, die das Projekt braucht.

Ein Bauherr plant ein Haus und notiert: sechs Ziegelsteine, eine Tür, vier Wasserhähne. Er legt keine echten Ziegel auf den Tisch, nur die Liste. Der Lieferdienst liest sie und liefert passende Teile ans Grundstück. Das fertige Lager auf dem Grundstück entsteht aus der Liste.

Node.js ist die Laufzeitumgebung, die JavaScript außerhalb des Browsers ausführt. Die Liste ist package.json, das zentrale Dokument jedes Node-Projekts. npm, der Paketmanager von Node.js, liest diese Datei und lädt aus dem zentralen Paketarchiv, der Registry, die nötigen Bausteine herunter. Sie landen im Ordner node_modules, der alle installierten Pakete samt deren eigenen Abhängigkeiten enthält.

Eine Abhängigkeit (Dependency) ist ein fremdes Programmpaket, das der eigene Code zum Laufen braucht, etwa Express für HTTP-Anfragen. In package.json steht unter dependencies der Eintrag "express": "^4.18.0". Das Caret vor der Zahl erlaubt jede 4er-Version ab 4.18.0; die drei Ziffern 1.2.3 bedeuten major.minor.patch – brechende Änderung, neue Funktion, Fehlerbehebung.

Das Bild hat eine Grenze: Eine Einkaufsliste nennt Zutaten meist exakt, "^4.18.0" ist ein erlaubter Bereich. Ohne die Sperrdatei package-lock.json kann npm auf einem Rechner 1.2.3 wählen, auf einem anderen 1.9.0. Die Sperrdatei friert die tatsächlich gewählten Versionen ein.

Deshalb gilt: package.json und package-lock.json gehören in die Versionsverwaltung (Git), node_modules nicht. Die Liste reicht, um überall dieselben Bausteine neu zu bestellen.

📌 Abhängigkeit · Versionsbereich · Sperrdatei

📚 Webentwicklung von Grund auf · Tag 4 von 30
#NodeJS #javascript #webdev

Der Code hängt an einer await-Zeile – oder scheint es zu tun. Dabei wartet dort nur eine einzige Funktion, nicht das ganze Programm.

Symptom kennen viele aus ihren ersten Webprojekten: Eine Variable enthält nach einem Serveraufruf nichts Brauchbares. Stattdessen steckt darin ein Objekt namens Promise, obwohl man doch die Daten erwartet hatte.

Hinter dem Symptom steht ein Grundbegriff: das Promise, ein Behälter für ein Ergebnis, das erst später eintrifft. JavaScript wartet nicht gern: Läuft eine Anfrage an einen Server, gibt der Aufruf sofort das Promise zurück – noch ohne Inhalt. Die Event-Loop, also die zentrale Verwaltung, die Aufgaben nacheinander abarbeitet, läuft währenddessen munter weiter. Würde der Code wirklich anhalten und warten, stünde die gesamte Anwendung still. Das Promise ist der Trick, beides zu vermeiden: Aufrufer bekommen sofort etwas in der Hand, die Daten folgen später.

Konkret: In einer mit async markierten Funktion, die immer ein Promise zurückgibt, schreibt man const antwort = await fetch("/artikel/42"); fetch ist der Browser-Befehl für eine HTTP-Anfrage. Erst nach Ankunft der Serverantwort liefert await das Antwortobjekt mit den Daten. Wichtig: await pausiert allein die umgebende Funktion; andere Aufgaben, etwa weitere eingehende HTTP-Anfragen, laufen weiter. async und await sind also keine Paralleltechnik, sondern eine lesbare Schreibweise für Promise-Ketten.

So prüft man es: Nach dem Aufruf den Inhalt der Variablen ausgeben lassen. Steht dort ein Promise statt der Daten, fehlt await. Und die await-Zeile in try und catch packen, damit eine Ablehnung des Promise, also ein fehlgeschlagenes Ergebnis, nicht als unbehandelter Fehler durchgeht.

await heißt nicht „Programm anhalten“, sondern „nur diese Funktion pausieren, bis das Promise ein Ergebnis liefert“.

📌 Promise · await · Event-Loop

📚 Webentwicklung von Grund auf · Tag 4 von 30
#javascript #typescript #webdev

Die meisten denken, ein Server brauche für jede Anfrage einen eigenen Thread. Dabei kommt Node.js mit einem einzigen Hauptthread aus und steht trotzdem nie still.

Verantwortlich dafür ist die Event-Loop, eine laufende Schleife im Hauptthread. Sie prüft, ob abgeschlossene Hintergrundvorgänge Ergebnisse geliefert haben, und ruft dann die zugehörigen Funktionen auf.

🌐 Eine gestartete Lese- oder Netzwerkoperation gibt den Hauptthread sofort frei. Das nennt man asynchron: Das Programm wartet nicht, sondern arbeitet weiter und kommt später zurück, wenn das Ergebnis bereitliegt. Ein Callback ist eine Funktion, die als Argument mitgegeben und beim Eintritt des Ereignisses aufgerufen wird. Bei await verbirgt der Compiler genau dieses Muster hinter einer scheinbar linearen Schreibweise.

🧩 „Asynchron“ heißt nicht „parallel“. Es gibt nur einen Hauptthread, der nacheinander arbeitet. Liest ein Server eine Datei mit fs.readFile, kann er währenddessen weitere HTTP-Anfragen annehmen; mit fs.readFileSync stehen alle anderen Anfragen still. Der Fortschritt entsteht durch Weiterarbeiten während des Wartens, nicht durch gleichzeitige Ausführung.

🔒 Eine blockierte Event-Loop ist kein Leistungsproblem, sondern ein Stillstand. Auch JSON.parse und JSON.stringify sind synchron; sehr große Dokumente halten die Schleife für die Dauer der Verarbeitung an. Dann steht jede Anfrage still, weil schlicht nichts mehr ausgeführt wird. Node.js empfiehlt daher, CPU-intensive Arbeit in Worker Threads auszulagern, eigene Threads mit eigenem Event-Loop und Nachrichtenaustausch.

Asynchron heißt nicht „schneller rechnen“, sondern „weiterarbeiten, während gewartet wird“.

📌 Event-Loop · Asynchron · Hauptthread

📚 Webentwicklung von Grund auf · Tag 4 von 30
#NodeJS #javascript #webdev

Die meisten Einsteiger sehen einen roten Lauf und drücken sofort auf Wiederholen. Dabei verraten Fehlermeldung und betroffener Schritt fast immer, wo der Fehler wirklich liegt.

Ein abgebrochener Lauf ist eine Ortsangabe, nicht nur ein Alarm. Die Ausführungsliste (das Protokoll aller Durchläufe) zeigt zuerst, welcher Schritt abbrach. Erst danach lohnt die Fehlermeldung selbst.

🔗 Ein Netzfehler betrifft die Verbindung, nicht den Inhalt. Meldungen wie Timeout, DNS-Fehler oder Connection refused sagen: Die Anfrage kam beim fremden Dienst nie an. HTTP-Statuscodes, die Antwortcodes einer Schnittstelle, sind in Klassen eingeteilt: 2xx Erfolg, 4xx Fehler beim Client, 5xx Fehler beim Server. 429 heißt Too Many Requests und meldet ein überschrittenes Anfragelimit je Zeitraum (Rate-Limit), oft mit einem Retry-After-Header, der angibt, wie lange der Aufruf warten soll.

🔁 Ein Datenfehler betrifft den Inhalt, nicht den Transport. Meldungen wie ungültiges Feld oder falsches Format bedeuten: Die Anfrage kam an, aber der Inhalt genügt nicht, etwa ein leeres Pflichtfeld. Typisch sind 400 oder 422. Eine Automation, die zweihundert Kontakte pro Durchlauf bei einem Limit von hundert Anfragen pro Minute abholt, liefert dagegen viele 429 – ein Limitproblem, kein Datenproblem.

🧭 Die erste Prüfung richtet sich nach dem Fehlerort. Bei Netzverdacht dieselbe Anfrage direkt mit curl, einem Kommandozeilen-Testwerkzeug, wiederholen und ein Timeout setzen – sonst blockiert ein hängender Dienst alles. Bei Datenverdacht den konkreten Datensatz aus der Ausführung und das Feld-Mapping prüfen.

Ein Fehler heißt nicht „irgendwas kaputt“, sondern „an genau einer Stelle kaputt“. Wer Netz, Daten und Zielsystem trennt, wiederholt nur, was sich lohnt: Netz, 429 und 5xx ja, ungültige Daten nie.

📌 Fehlermeldung lesen · Fehlerort bestimmen · gezielt prüfen

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #workflow #api

Viele Einsteiger halten JavaScript für eine Browsersprache. Dabei läuft dieselbe Sprache auch auf Servern und Build-Werkzeugen.

Die Annahme klingt plausibel: JavaScript entstand für Webseiten, und dort sieht man es auch. Wer Buttons, Formulare und Animationen kennt, verbindet die Sprache fest mit Browser und Frontend.

Tatsächlich ist der Browser nur eine Laufzeitumgebung – also das Programm, das die Sprache überhaupt ausführen kann. Es enthält die Sprach-Engine und Bibliotheken, über die der Code sein Betriebssystem erreicht. Die Sprache selbst definiert die ECMAScript-Norm, und jede Umgebung legt fest, was sie darf. Node.js ist eine solche Umgebung und führt JavaScript außerhalb des Browsers aus, etwa auf einem Server. Sie ergänzt die Sprache um Module für Dateizugriffe und um eines, das einen HTTP-Server startet, der Anfragen entgegennimmt und antwortet.

Der Irrtum entsteht, weil Einsteiger JavaScript fast ausschließlich im Frontend erleben. Dort laufen die Sprache und der Browser scheinbar immer gemeinsam auf.

Ein kleines Skript zeigt den Unterschied: Unter Node.js liest es eine Datei ein und zählt Wörter. Genau dieses JavaScript hat vorher vielleicht einen Button im Browser verarbeitet. Wird daraus ein Server, beantwortet er etwa die Anfrage GET /artikel/42 mit einem Datensatz im JSON-Format.

Woran man es erkennt: Läuft Code ohne geöffnetes Browserfenster, ist er nicht im Frontend, sondern im Backend unterwegs. Frontend und Backend sind keine Ordner, sondern Lauforte derselben Sprache.

JavaScript heißt nicht „die Browsersprache“, sondern eine Sprache mit wechselnden Lauforten. Wer Werkzeuge wie npm nutzt, fährt bereits Node.js, ohne es zu bemerken.

📌 Laufzeitumgebung · Node.js · Frontend und Backend als Lauforte

📚 Webentwicklung von Grund auf · Tag 4 von 30
#javascript #NodeJS #webdev

Wer die Eintrittskarte in der Hand hat, kommt rein. Genau so prüft ein Server ein Bearer-Token – und das hat Folgen.

Erklärt wird hier, wie eine authentifizierte Anfrage über das Netz läuft. Die Situation kennt jeder, der einmal eine API oder eine App mit Login benutzt hat.

Zuerst sendet der Client beim Einloggen seine Zugangsdaten, etwa E-Mail und Passwort, an den Server. Der prüft sie und stellt im Erfolgsfall ein Zugriffstoken aus, also eine Art digitale Eintrittskarte. HTTP selbst ist zustandslos: Jede Anfrage steht für sich, und der Server erkennt einen Nutzer nur wieder, wenn Daten wie ein Token mitgesendet werden.

Dann schickt der Client das Token bei jeder weiteren Anfrage im Authorization-Header mit, nach dem Schema „Authorization: Bearer“ gefolgt vom Tokenwert. Bearer ist Englisch für Inhaber. Der Server prüft nur, ob ein gültiges Token vorliegt – nicht, wer die Anfrage eigentlich stellt.

Danach entscheidet der Server allein auf Basis dieses Headers. Wer das Token besitzt, darf damit arbeiten, wie ein Gast mit Garderobenmarke. Ein solches Token ist meist zeitlich begrenzt; anders als ein Passwort läuft es also bald ab.

Zuletzt kommt die Übertragung: Sie muss über TLS laufen, also über die verschlüsselte Variante von HTTP namens HTTPS. Nur dann ist der Header vor dem Mitlesen geschützt. Über offenes HTTP kann jeder im Netzpfad, etwa in einem offenen WLAN, das Token abfangen und anschließend selbst verwenden. Der Besitz allein reicht ja aus.

Bearer heißt nicht „berechtigte Person“, sondern „Inhaber“. Ohne HTTPS trägt jede Anfrage das Token offen im Klartext mit.

📌 Bearer-Token · Authorization-Header · TLS

📚 Webentwicklung von Grund auf · Tag 4 von 30
#HTTP #WebSecurity #webdev #api

Wer bei Statuscode 429 sofort die Automation abschaltet, handelt voreilig. Dabei meldet die API nur eine zeitweise Grenze, kein dauerhaftes Verbot.

Viele Einsteiger lesen eine 429-Antwort als „Zugriff entzogen“. Das klingt plausibel, weil Fehlermeldungen normalerweise ein Problem anzeigen, das man selbst beheben muss.

Tatsächlich ist 429 nur die Antwort auf zu viele Anfragen in kurzer Zeit. Ein Rate-Limit begrenzt, wie viele Anfragen ein Client in einem Zeitraum stellen darf. Der Betreiber einer API, also einer festgelegten Schnittstelle zwischen Programmen, schützt so den Dienst: ein einzelner Client soll nicht alle anderen blockieren. HTTP-Statuscodes, die standardisierten Antwortnummern, ordnen 429 den Client-Fehlern zu; der Client war zu schnell, der Server funktioniert.

Der Irrtum entsteht, weil 429 im Workflow-Protokoll wie jeder andere Fehler aussieht. Besonders in n8n bricht eine Node dann den Durchlauf ab, wenn keine Fehlerbehandlung konfiguriert ist.

Ein Beispiel: eine Automation holt zweihundert Kontakte aus einer Adress-API, einzeln je Datensatz. Das Limit liegt bei hundert Anfragen pro Minute; ab der einhundertundersten Anfrage kommt 429 zurück. Bewährt hat sich, Sammelanfragen zu nutzen und Wartezeiten einzubauen.

Woran man es erkennt: Die Antwort trägt den Status 429 Too Many Requests. Oft nennt ein Retry-After-Header, wie lange der Client warten soll, bevor dieselbe Anfrage erneut läuft.

429 heißt nicht „verboten“, sondern „zu schnell“. Nach der Wartezeit erneut senden, mit wachsender Pause, statt aufzugeben.

📌 Rate-Limit · Statuscode 429 · Retry-After

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #api #n8n #workflow

Authentifizierung klärt, wer jemand ist. Autorisierung klärt, was diese Person darf.

Beide laufen direkt hintereinander ab und landen oft in einem Topf namens „Login“. Dabei können sie unabhängig scheitern – und der Server antwortet dann mit unterschiedlichen Fehlercodes.

Bei der Authentifizierung gleicht der Server eine Angabe wie Passwort oder Token (ein Ausweis-Datenstück aus Buchstaben und Zahlen) mit seinen gespeicherten Daten ab. Daraus ermittelt er eine Identität, etwa die Nutzer-ID 42. Das ist der erste Schritt: Ohne feststehende Identität kann keine Rechteprüfung folgen.

Bei der Autorisierung prüft der Server für jede einzelne Anfrage, ob diese Identität die angefragte Aktion ausführen darf. Konkret: Nutzer 42 meldet sich mit Passwort an. Beim Aufruf von DELETE /artikel/7 prüft der Server zusätzlich, ob 42 die Rolle Redakteur hat. Ohne diese Rolle folgt der Statuscode 403.

Scheitert die Authentifizierung, antwortet der Server mit 401 (nicht authentifiziert). Scheitert nur die Autorisierung, folgt 403 (verboten) – die Identität ist bekannt, aber die Rechte fehlen.

Weil HTTP zustandslos ist – jede Anfrage steht für sich –, muss jede Anfrage die Identität erneut belegen, etwa durch ein Cookie, ein Name-Wert-Paar, das der Server setzt und der Browser zurücksendet, mit einer Sitzungs-ID als Verweis auf die serverseitig gespeicherte Anmeldung. Der Server authentifiziert also bei jeder Anfrage von Neuem. Und weil der Browser-Seite nicht vertraut werden kann, gehört jede dieser Prüfregeln zusätzlich ins Backend.

Faustregel: Erst die Identität feststellen, dann je Anfrage die Rechte prüfen – beide Prüfungen niemals nur im Browser.

Authentifizierung heißt nicht „eingeloggt und alles erlaubt“, sondern nur „erkannt“. Was jemand darf, entscheidet die Autorisierung – separat und bei jedem Zugriff neu.

📌 Identität · Rechte · 401 vs. 403

📚 Webentwicklung von Grund auf · Tag 4 von 30
#WebSecurity #backend #HTTP

Viele halten doppelte Webhooks für einen Bug. Dabei steckt dahinter eine bewusste Zustellungsgarantie.

Warum man sie verwechselt: Ein Webhook ist ein HTTP-Aufruf, meist POST mit JSON-Body, den ein System bei einem Ereignis an eine hinterlegte URL sendet. Kommt derselbe Aufruf zweimal an, sieht das nach einem Fehler des Absenders aus.

Genau einmal: Bei exactly-once garantiert der Sender, dass jedes Ereignis genau eintrifft, also weder mehrfach noch gar nicht. Das klingt ideal, ist aber über offene Netze kaum zusicherbar. Der Sender weiß oft nicht, ob die Zustellung ankam.

Mindestens einmal: Bei at-least-once garantiert der Sender nur, dass ein Ereignis ankommt, und nimmt dafür zusätzliche Kopien in Kauf. Bleibt die Bestätigung aus, wiederholt er die Zustellung. Ein Zahlungsdienst sendet den Webhook für eine Buchung, der Empfänger verarbeitet sie, doch die Antwort geht verloren. Sekunden später trifft derselbe Vorgang mit derselben Ereignis-ID erneut ein.

Exactly-once verschiebt die Schwierigkeit zum Sender, at-least-once zum Empfänger. Der Empfänger muss idempotent sein, also jedes Ereignis an seiner eindeutigen ID erkennen und überspringen. Die ID wirkt wie ein Kassenbon, der zeigt, dass der Vorgang schon abgearbeitet ist.

Faustregel: In einer Automation mit Webhook-Trigger gehört die Duplikatprüfung an den Anfang des Workflows, vor jedem Schritt, der Daten anlegt oder versendet. Denn nach der zweiten Buchung ist ein Zurücknehmen kaum noch möglich. Zusätzlich zügig mit einem 2xx-Status (HTTP-Erfolgscodes wie 200) antworten und die eigentliche Arbeit entkoppelt erledigen, sonst erzeugt man selbst weitere Wiederholungen.

At-least-once heißt nicht, dass der Sender defekt ist, sondern dass er lieber doppelt sendet als gar nicht.

📌 At-least-once · Idempotenz · Ereignis-ID

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #Webhooks #Integration

Eine Webhook-URL funktioniert wie ein Türspalt ohne Schloss: Wer die Adresse kennt, kommt herein. Niemand meldet sich an, niemand fragt nach dem Ausweis.

Vorstellen lässt sich eine Hinterwerkstattür, die ein zustellender Bote regelmäßig nutzt. Der Bote kennt die Tür, schiebt Pakete durch und geht wieder. Ein Fremder, der die Adresse der Tür einmal gesehen hat, kann dieselbe Tür genauso benutzen. Er wirft dann keine echten Pakete hinein, sondern ausgedachte.

Die Tür ist die Webhook-URL, die Adresse, unter der ein Workflow auf Anfragen wartet. Ein Webhook ist ein HTTP-Aufruf, meist POST mit JSON-Body, den ein System bei einem Ereignis an genau diese URL sendet. Der Riegel fehlt: Ohne weitere Prüfung genügt die Kenntnis der Adresse, um eine Anfrage abzusetzen, ganz ohne Anmeldung. HTTPS verschlüsselt zwar die Verbindung auf dem Weg, sagt aber nichts darüber, wer gesendet hat.

Konkret sieht das so aus: In n8n richtet man einen Webhook-Trigger über den Webhook Node ein, der eine URL bereitstellt. Wer diese URL kennt, kann mit einem einfachen HTTP-POST-Programm eine ausgedachte Bestellung senden und den Workflow starten, als wäre das Ereignis echt.

Das Bild hat eine Grenze: Eine Tür kann man abschließen, eine bloße URL nicht. Das Schloss ist eine Signaturprüfung mit einem gemeinsamen Geheimnis, etwa per HMAC-SHA256; nur wer das Geheimnis kennt, erzeugt eine gültige Signatur.

Deshalb: Die Webhook-URL wie ein Passwort behandeln, nur über HTTPS erreichbar machen und bei Kündigung oder Verdacht auf Bekanntwerden neu vergeben. Nicht in Repositorien, Screenshots, Dokumentationen oder Logs veröffentlichen.

Wer die Adresse kennt, kann senden. Die URL schützt niemanden, sie benennt nur die Tür.

📌 HTTPS · Vertraulichkeit · Signaturprüfung

📚 Automatisierung von Grund auf · Tag 3 von 30
#Webhooks #n8n #Automatisierung #datenschutz

Die meisten Einsteiger bauen Aktionen in den Pfad ein: /getOrders, /deleteUser. Dabei sagt der Pfad nur, um welches Ding es geht – die Aktion steckt in der HTTP-Methode.

Eine saubere REST-Schnittstelle braucht weniger Adressen und ist leichter zu lesen. Wer Ressourcen und Methoden trennt, kann jede Adresse mit vier Methoden nutzen.

🌐 Eine REST-Schnittstelle benennt Dinge, keine Tätigkeiten. REST ist ein Stil, Web-Schnittstellen über HTTP zu bauen, das Übertragungsprotokoll des Webs. Eine Ressource ist dabei ein benanntes Ding: ein Kunde, eine Bestellung oder die Liste aller Bestellungen. Eine HTTP-Anfrage besteht aus Methode, Ziel, Headern und optionalem Body; der Pfad im Ziel adressiert die Ressource, etwa /bestellungen.

🧩 Der Pfad benennt Substantive, die Methode wirkt darauf. GET /bestellungen liest die Liste, GET /bestellungen/42 liest genau eine Bestellung, POST /bestellungen legt eine neue an, DELETE /bestellungen/42 löscht sie. Dieselbe Adresse kann je nach Methode Verschiedenes bedeuten: Der Pfad /bestellungen/42 bleibt gleich, nur die Wirkung ändert sich. PUT /bestellungen/42 ersetzt dagegen die Daten dieser Bestellung.

🔒 Verben im Pfad wie /deleteUser verwirren, weil sie die Ordnung brechen. Der Server müsste für jede Aktion eine eigene Adresse verwalten, und GET /deleteUser würde beim bloßen Aufruf löschen. Mit Substantiv und Methode gelten vier klare Verben für alle Ressourcen; der Server antwortet mit Statuscode und meist JSON, dem Datenformat mit Schlüssel-Wert-Paaren.

REST heißt nicht „Befehle in URLs schreiben“, sondern „Dinge benennen und mit Methoden darauf wirken“.

📌 Ressourcen · Substantive im Pfad · HTTP-Methoden

📚 Webentwicklung von Grund auf · Tag 3 von 30
#REST #api #HTTP #webdev

Viele setzen Cache-Control: no-cache, wenn sie „nicht speichern“ meinen. Genau dann speichert der Browser die Antwort trotzdem.

Ein Cache ist eine gespeicherte Kopie einer HTTP-Antwort, die wiederverwendet wird, statt sie jedes Mal neu vom Server zu laden. Ob und wie lange eine gespeicherte Kopie wiederverwendet werden darf, steuert der Server über den Header Cache-Control in der Antwort selbst. Wer no-cache falsch versteht, verschickt versehentlich vertrauliche Daten in Caches – oder wundert sich, dass die Rückfrage trotzdem kommt.

no-cache heißt nicht „nicht speichern“, sondern „vor jeder Wiederverwendung beim Server validieren“. Die Antwort darf also im Cache liegen. Bevor der Browser sie erneut anzeigt, muss er aber beim Server nachfragen, ob sie sich verändert hat.

Konkret läuft diese Nachfrage als bedingter Request: Der Browser sendet einen gespeicherten ETag – einen vom Server vergebenen Prüfwert für eine Darstellung – im Header If-None-Match mit. Ist die Ressource unverändert, antwortet der Server nur mit 304 Not Modified und leerem Body. Der Browser nutzt dann seine gespeicherte Kopie weiter. Eine HTML-Seite mit no-cache und ETag bleibt so immer aktuell, während nur wenige Bytes über die Leitung gehen. Wer dagegen aktuelle Daten ohne Rückfrage zulassen will, setzt max-age=N: Dann darf der Cache die Antwort N Sekunden lang ausliefern, ohne zu fragen.

Verwechselt wird no-cache vor allem mit no-store. Letzteres verbietet jede Speicherung und gehört zu persönlichen Daten wie Bankauszügen oder Sitzungsdaten. no-cache hält eine Seite dagegen aktuell, ohne sie jedes Mal komplett neu zu laden – ein Geschwindigkeitsgewinn, kein Nachteil.

no-cache ist nicht „nicht speichern“, sondern „speichern, aber vorher fragen“. Wer nichts gespeichert haben will, schreibt no-store.

📌 Cache-Control · no-cache · no-store

📚 Webentwicklung von Grund auf · Tag 3 von 30
#webdev #HTTP #backend #performance

Viele denken, der Browser hole jede Seite komplett neu vom Server. Dabei ist das zweite Laden einer Seite oft viel schneller – und das liegt selten am schnellen Internet, sondern am Zwischenspeicher.

Viele Einsteiger glauben, der Browser hole jedes Bild und jede Seite komplett neu vom Server. Das klingt plausibel, weil man ja jedes Mal eine Adresse aufruft. Auch verwechselt man den Cache, also den Zwischenspeicher, gern mit dem Cookie, der einen Nutzer bei künftigen Anfragen identifiziert.

Tatsächlich ist ein Cache eine gespeicherte Kopie einer HTTP-Antwort, die wiederverwendet wird, statt sie jedes Mal neu zu laden. Speichern können mehrere Stellen zwischen Browser und Server: der Browser selbst, ein Proxy als Vermittler im Netz und ein CDN, ein Netz aus Servern näher beim Nutzer. Ob und wie lange gespeichert werden darf, steuert der Server über den Header Cache-Control – etwa mit max-age, das die Sekunden ohne Rückfrage festlegt.

Der Irrtum entsteht, weil das Speichern unsichtbar im Hintergrund passiert. Man sieht nur, dass die Seite dargestellt wird, nicht woher sie kommt.

Ein konkretes Beispiel: Beim ersten Laden einer Seite muss jede Ressource vom Ursprungsserver geholt werden. Beim zweiten Besuch sendet der Browser das ETag in If-None-Match zurück; ist die Darstellung unverändert, antwortet der Server mit 304 Not Modified ohne Body – die Seite lädt spürbar schneller.

Woran man es erkennt: In der Netzwerk-Ansicht der Browser-Entwicklerwerkzeuge zeigen manche Einträge statt 200 OK einen 304 Not Modified. Der Server bestätigt damit nur: Die gespeicherte Kopie ist noch gültig.

Cache heißt nicht „Speicher für Nutzerdaten“, sondern „Vorrat an Antworten“. Wer Anfragen ersparen will, steuert das mit Cache-Control – nicht mit Cookies.

📌 Cache-Control · Zwischenspeicher · 304 Not Modified

📚 Webentwicklung von Grund auf · Tag 3 von 30
#HTTP #webdev #performance

Die meisten Automationen fragen regelmäßig nach, ob etwas passiert ist. Dabei kann sich die Quelle auch von selbst melden – per Webhook.

Wer Formulare, Shops oder Ticketsysteme verbindet, trifft früh auf Webhooks. Wer sie nicht kennt, baut Abfragen, die Minuten verspätet liefern und unnötige Last erzeugen.

Ein Webhook ist ein HTTP-Aufruf, meist ein POST mit JSON-Daten, den ein System bei einem Ereignis automatisch an eine hinterlegte URL schickt. HTTP ist das Standardprotokoll des Webs; JSON ist ein einfaches Textformat für strukturierte Daten. Der Empfänger legt also nur eine Adresse beim absendenden System fest – mehr nicht.

In n8n, einem Werkzeug für Automationen, fügt man dafür den Webhook Node hinzu. Dieser Node stellt eine URL bereit, etwa eine Test-URL während der Einrichtung. Diese URL trägt man im absendenden System als Webhook-Adresse ein. Danach startet der Workflow nicht mehr zeitgesteuert, sondern genau dann, wenn das Ereignis eintritt. Im Gegensatz dazu fragt ein Polling-Trigger die Quelle regelmäßig ab.

Verwechselt wird der Webhook gern mit einer API. Eine API wird aufgerufen und liefert auf Anfrage; ein Webhook ruft selbst auf und liefert ohne Anfrage. Deshalb muss der Empfänger auch bestätigen: Er antwortet schnell mit einem 2xx-Status und verarbeitet die Daten entkoppelt in einer Warteschlange, in der Aufgaben warten, bis sie abgearbeitet werden. Und da Sender mindestens einmal zustellen, prüft der Empfänger die Ereignis-ID und überspringt bereits verarbeitete Nachrichten.

Ein Webhook fragt also nicht nach, er wird benachrichtigt. Wer abfragt, ist Empfänger; wer benachrichtigt, ist Quelle.

📌 Webhook · POST mit JSON · Trigger statt Polling

📚 Automatisierung von Grund auf · Tag 3 von 30
#Webhooks #Automatisierung #n8n #api

JavaScript kann Bilder von fremden Servern laden, aber nicht deren pixelgenaue Daten auslesen. Dieser Unterschied ist die Same-Origin-Policy – und sie erklärt, warum fetch-Aufrufe scheitern können, obwohl die Anfrage beim Server ankam.

Der Browser vergleicht bei jeder Antwort, ob sie von derselben Origin (der Kombination aus Schema, Host und Port) stammt wie die Seite, deren JavaScript sie lesen will. Das begegnet Einsteigern sofort, sobald Frontend und Backend getrennt laufen.

Zuerst lädt der Browser die Seite, etwa eine gewöhnliche Dokumentseite unter https. JavaScript auf dieser Seite ruft dann Daten ab, zum Beispiel von einer API unter einem anderen Host. Die Anfrage geht ganz normal raus; der Server antwortet, ohne zu prüfen, wer sie liest.

Dann zählt der Browser Schema, Host und Port, nicht den Pfad: Zwei Adressen wie /seite1 und /api/daten auf demselben Host mit demselben Port teilen sich eine Origin. Aber ein API-Host und ein www-Host derselben Domain sind verschiedene Hosts, und derselbe Host mit abweichendem Port wie 8443 ist eine andere Origin. Ein fehlender Port bedeutet den Standardport, also 443 bei https.

Danach hält der Browser die Antwort zurück, wenn die Origins verschieden sind. Der Browser schickt die Anfrage, gibt die Antwort aber nicht an JavaScript weiter, solange der Server sie nicht per CORS (einem Header-Mechanismus zur Freigabe) erlaubt. Bilder und Stylesheets fremder Origins erscheinen trotzdem, weil kein Skript ihren Inhalt liest.

Zuletzt gilt die Grenze nur im Browser. curl (ein Kommandozeilenwerkzeug für HTTP-Anfragen) sendet und liest ohne Sandbox alles; die Same-Origin-Policy schützt den Server nicht, nur die Seite im Browser.

Gleiche Origin heißt also nicht gleicher Host, und fremde Origin heißt nicht blockierte Anfrage – sondern unlesbare Antwort.

📌 Origin · Same-Origin-Policy · CORS

📚 Webentwicklung von Grund auf · Tag 3 von 30
#WebSecurity #webdev #javascript

Die meisten denken, eine Webadresse sei ein einziger unteilbarer String. Dabei vergleicht der Browser nur drei Bestandteile, um Herkünfte zu unterscheiden.

Die Verwechslung ist naheliegend: URL und Origin sehen fast gleich aus, und die Origin ist der vordere Teil der URL. Wer beides gleichsetzt, wundert sich später, warum eine Anfrage blockiert wird.

Die URL (Uniform Resource Locator, eine komplette Webadresse) besteht aus Schema, Host, optionalem Port, Pfad, optionaler Query nach dem Fragezeichen und optionalem Fragment nach der Raute. Sie benennt eine konkrete Ressource wie eine Seite oder ein Bild. Schema https, Pfad /orders und Query id=7 zeigen vier dieser Bestandteile in einer Adresse.

Die Origin besteht nur aus Schema, Host und Port; der Rest zählt nicht mit. Der Browser vergleicht zwei Adressen, indem er genau diese drei Teile gegenüberstellt; eine Abweichung ergibt eine andere Origin. Zwei Adressen mit gleichem Host sind darum verschieden, sobald der Port abweicht (Standardport gegenüber 8443) oder das Schema (http gegenüber https).

Pfad, Query und Fragment dürfen beliebig abweichen, ohne die Origin zu ändern. Ein fehlender Port bedeutet zudem den Standardport des Schemas – bei https der 443, bei http der 80; eine Adresse mit und ohne diese 443 hat dieselbe Origin.

Faustregel: Beim Aufrufen einer Ressource die volle URL angeben, beim Prüfen von Herkunft und Zugriff nur Schema, Host und Port vergleichen. Auch Unterdomänen wie api und www desselben Namens sind verschiedene Hosts und damit verschiedene Origins; die Same-Origin-Policy, eine Browser-Regel, gibt JavaScript nur Antworten derselben Origin frei, fremde Origins brauchen eine CORS-Freigabe des Servers.

Die Origin heißt nicht Adresse, sondern Herkunft: Schema, Host und Port – und sonst nichts.

📌 Origin · Same-Origin-Policy · URL-Bestandteile

📚 Webentwicklung von Grund auf · Tag 3 von 30
#webdev #WebSecurity #HTTP

HTTPS funktioniert wie ein Geldtransporter mit beglaubigtem Fahrer. Der Wagen schützt die Ladung auf der Fahrt, und der Dienstausweis belegt, dass der Fahrer wirklich beim Unternehmen angestellt ist.

Der Transporter fährt durch offenes Gelände. Beobachter sehen den Wagen, erkennen aber keinen Inhalt. Wird eine Kiste unterwegs aufgebrochen, fällt der Eingriff sofort auf.

Technisch ist HTTPS HTTP über TLS, also das normale Web-Protokoll über eine verschlüsselte Verbindung. Der TLS-Handshake, die Verbindungsaufnahme, einigt sich auf einen Schlüssel und prüft das Zertifikat: ein digitaler Ausweis, den eine Zertifizierungsstelle als anerkannte Vertrauensinstanz signiert hat. Der Browser vergleicht den Domainnamen im Zertifikat mit dem Host der URL, also dem Domainnamen in der Adresse; danach laufen alle Anfragen und Antworten als Chiffretext, also unlesbarer Geheimtext.

Beim Aufruf ist das Schema der URL der Teil vor dem Doppelpunkt: Es sagt dem Client, welches Protokoll er nutzt. Aus http wird damit https: verschlüsselte Übertragung mit Geheimhaltung, statt Klartext. Das Schloss im Browser bedeutet also nicht „sicherer Server“, sondern belegt nur zwei Eigenschaften des Wegs: verschlüsselte Übertragung und geprüfte Identität.

Das Bild hat eine Grenze: Der Transporter schützt weder das Lager noch die Ware nach der Abladung. Nach dem Entschlüsseln liegen die Daten auf dem Server im Klartext vor; Angriffe im Backend liegen außerhalb der Zuständigkeit der Verbindung.

HTTPS heißt nicht „dieser Server ist gut“, sondern „dieser Weg ist verschlüsselt, und dieser Ausweis passt zur Domain“.

📌 TLS-Verschlüsselung · Zertifikat · Schloss-Symbol

📚 Webentwicklung von Grund auf · Tag 3 von 30
#WebSecurity #HTTP #webdev

Eine neue Regel in der Security Group setzen, und trotzdem kommt kein Traffic durch. Meistens fehlt nicht die Regel, sondern sie zeigt auf die falsche Quelle.

Eine Security Group ist eine Firewall, die direkt an der Netzwerkschnittstelle einer Instanz hängt und jeden ein- und ausgehenden Datenverkehr prüft. Sie entscheidet in der Cloud, ob ein Server überhaupt erreichbar ist.

Zuerst denkt man an die Quelle einer Regel, also an die Frage, wer sich verbinden darf. Dort muss keine einzelne IP-Adresse stehen: Wenn die Anwendungsschicht eine eigene Security Group hat, kann genau diese Gruppe als Quelle eingetragen werden. So erhalten nur diese Instanzen Zugriff auf die Datenbank.

Dann wird die Richtung festgelegt. Regeln sind nur Erlaubnisse, nie Verbote. Wer HTTPS von überall erlaubt, lässt genau dieses herein; alles andere bleibt draußen. Die Gruppe gilt je Netzwerkschnittstelle, und Instanzen können mehrere Gruppen haben, deren Regeln sich addieren.

Danach folgt der Punkt, der Einsteiger verwirrt: Security Groups sind zustandsbehaftet. Ruft der Server eine Außenstelle auf, wird die Antwort automatisch eingelassen. Eine zusätzliche Regel für die Rückrichtung ist unnötig und ein häufiger Irrtum.

Zuletzt die Grenze: Öffentlich heißt nicht ungefiltert. Auch in einem öffentlichen Subnetz entscheidet die Security Group, was durchgeht. Eine Adresse gezielt blocken kann sie nicht; dafür braucht es die zustandslose Network ACL auf Subnetzebene.

Security Groups sperren niemanden aus, sondern lassen gewolltes herein. Die Antwort auf eine erlaubte Anfrage läuft immer mit.

📌 Zustandsbehaftet · Nur Erlaubnisregeln · Quelle kann Gruppe sein

📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops

Das Login ist nach dem Neustart des Browsers weg – und niemand weiß, warum. Einsteigern passiert das oft mit dem allerersten Cookie.

Nach dem Schließen und Wiederöffnen des Browsers ist der Nutzer abgemeldet. Beim Klick durch die Seiten ist dagegen alles normal.

Ein Cookie ist ein Name-Wert-Paar, das der Server mit dem Header Set-Cookie setzt und das der Browser bei passenden Anfragen im Header Cookie zurücksendet. Header sind Zeilen, die bei HTTP Daten zwischen Server und Browser austauschen; HTTP selbst ist zustandslos, jede Anfrage steht für sich. Der Server erkennt Nutzer also nur anhand mitgesendeter Werte wie Cookies, etwa als Schlüssel in seiner Session-Tabelle. Ohne Expires und Max-Age entsteht ein Sitzungscookie: Der Browser verwirft es beim Schließen, kann die Sitzung aber wiederherstellen. Mit Expires, einem konkreten Ablaufdatum, oder Max-Age, einer Lebensdauer in Sekunden, entsteht ein dauerhaftes Cookie, das Neustarts überlebt; ist beides gesetzt, gewinnt Max-Age.

Set-Cookie: sessionid=abc123; Path=/; HttpOnly setzt ein Sitzungscookie, das beim Beenden des Browsers verschwindet. Fügt man Max-Age=3600 an, bleibt es eine Stunde lang bestehen. Der Nutzer bleibt dann auch nach einem Neustart angemeldet – bis die Frist abläuft.

So prüft man es: Im Browser-DevTools unter Application die Cookies der Seite ansehen und die Spalten Expires und Max-Age prüfen. Sitzungscookies zeigen dort „Session“ statt eines Datums.

Sitzungscookie meint hier nur die Speicherung im Browser, nicht eine Server-Session; auch ein dauerhaftes Cookie kann einen Sitzungsschlüssel tragen, den der Server jederzeit für ungültig erklärt. Expires und Max-Age sind also die Schalter für die Lebensdauer, nicht für den Inhalt.

📌 Sitzungscookie · Max-Age · dauerhaftes Cookie

📚 Webentwicklung von Grund auf · Tag 3 von 30
#webdev #HTTP #WebSecurity #backend

Die meisten Anfänger denken, der Server müsse das Cookie abfragen oder der Nutzer müsse es eintippen. Dabei übernimmt der Browser den Versand des Cookies, eines kleinen Name-Wert-Paars, vollständig automatisch.

HTTP, das Protokoll hinter Webseiten, ist zustandslos – jede Anfrage steht für sich. Ohne zurückgesendete Daten wüsste der Server nicht, wer fragt. Cookies füllen genau diese Lücke.

🌐 Ein Cookie ist ein Name-Wert-Paar, das der Server setzt. In der Antwort steht etwa: Set-Cookie: sessionid=abc123; Path=/; HttpOnly. Vor dem Semikolon stehen Name und Wert, die Attribute dahinter steuern Speicherung und Versand. Path=/ bedeutet: zu jedem Pfad dieses Hosts mitsenden.

🧩 Der Browser schickt das Cookie automatisch mit, ohne eigenes Programm. Passt die angefragte Adresse zum Cookie, fügt der Browser den Header Cookie: sessionid=abc123 in die Anfrage ein. Die Webanwendung muss nichts dafür tun. Derselbe Datensatz heißt in der Antwort Set-Cookie, in der Anfrage Cookie – zwei Header, ein Inhalt. Nachvollziehen lässt sich das in den Entwicklerwerkzeugen: im Netzwerk-Tab bei einer Antwort den Set-Cookie-Header suchen und bei der nächsten Anfrage an denselben Host den Cookie-Header mit demselben Wert vergleichen.

🔒 HttpOnly schützt den Cookie vor JavaScript im Browser. JavaScript kann ihn dann nicht auslesen, und ein XSS-Angriff (böses Skript auf der Seite) stiehlt ihn nicht direkt. Ohne Expires oder Max-Age gilt das Cookie nur bis zum Schließen des Browsers. Das nennt man Sitzungscookie; der Browser kann die Sitzung aber wiederherstellen.

Ein Cookie heißt nicht Abfrage durch den Server, sondern automatischer Rückversand durch den Browser. Der Server erkennt Nutzer wieder, indem er den Wert etwa in seiner Session-Tabelle nachschlägt.

📌 Name-Wert-Paar · Set-Cookie · automatischer Rückversand

📚 Webentwicklung von Grund auf · Tag 2 von 30
#webdev #HTTP #backend

Der Workflow bricht ab, und die Fehlermeldung zeigt nur „404“. Dabei verrät diese eine Zahl bereits, wo die Ursache liegt.

Gesehen wird das Symptom in n8n oder Zapier meist bei einem HTTP-Node, also dem Baustein, der fremde Dienste aufruft. Das Log zeigt die dreistellige Nummer, der Workflow stoppt, und unklar bleibt, wer den Fehler beheben kann.

Der Grundbegriff dahinter ist der HTTP-Statuscode. Bei HTTP schickt ein Client eine Anfrage mit Methode, Ziel-URL, Headern und optionalem Inhalt; der Server antwortet mit einem Statuscode, Headern und optionalem Inhalt. Der Client ist hier die eigene Plattform, der Server das fremde System mit dessen API, also Schnittstelle für Programme. Die erste Ziffer des Codes nennt die Klasse: 2xx Erfolg, 3xx Umleitung, 4xx Fehler beim Client, 5xx Fehler beim Server.

Ein Workflow ruft etwa eine API mit falsch gesetzter Kundennummer in der URL auf und erhält 404. Die Lösung ist nicht, es erneut zu versuchen, sondern die URL an die dokumentierte Form anzupassen. Wer URLs oder Feldnamen frei erfindet, statt die Dokumentation zu lesen, erhält meist 404 oder 400.

So prüft man es: Erst den Statuscode lesen, dann die Anfrage prüfen. Bei 4xx die eigene Anfrage korrigieren, etwa 401 durch einen gültigen API-Schlüssel; bei 5xx beim Anbieter warten oder eine Fehlerbenachrichtigung einrichten.

Der Statuscode heißt nicht „irgendein Fehler“, sondern eine Zuordnung: 4xx gehört zur eigenen Anfrage, 5xx zum fremden System. Ein 429 zeigt zudem ein überschrittenes Rate-Limit, also ein Anfragelimit pro Zeitraum.

📌 Statuscode · Fehlerklassen · Fehlerbehandlung

📚 Automatisierung von Grund auf · Tag 2 von 30
#api #Automatisierung #n8n #workflow

Der Browser zeigt den Login an, doch der Server kennt den Nutzer nicht. Dabei ist das kein Fehler: HTTP vergisst absichtlich.

Wer das erste Mal eine Anmeldung baut, stolpert fast immer hier. Wer nicht weiß, dass HTTP zustandslos ist, wundert sich, warum der Nutzer nach einem Klick wieder ausgeloggt ist.

Zustandslos heißt: Jede HTTP-Anfrage (die Nachricht, die der Browser an den Server schickt) steht für sich allein. Sie besteht aus Methode, Ziel, Headern und optionalem Body. Das Protokoll kennt keine Verbindung zwischen zwei Anfragen. Aus Sicht des Servers ist jede Anfrage die erste. Zustandslos heißt also nicht, dass der Server kein Gedächtnis haben darf. Nur das Protokoll selbst verknüpft nichts.

Die Erinnerung liefert der Client mit: eine Kennung, die bei jeder Anfrage mitgeschickt wird. Nach dem Login antwortet der Server etwa mit dem Header Set-Cookie: session=abc123. Der Browser speichert dieses Name-Wert-Paar und sendet es bei passenden Anfragen im Header Cookie: session=abc123 zurück. Der Server findet dazu die Sitzung mit dem Login-Zustand. Fehlt die Kennung, etwa weil Cookies gelöscht wurden, gilt die nächste Anfrage als die eines unbekannten Besuchers. Eine Alternative zum Cookie ist ein Token, eine Zeichenkette, die der Client beim Aufruf einer API selbst in einen Header setzt. Auch sie wirkt nur, weil sie jedes Mal erneut mitgesendet wird.

Verwechselt wird Zustandslosigkeit gern mit fehlender Authentifizierung, der Frage, wer jemand ist. Beides ist unabhängig: Auch nach erfolgreichem Login bleibt jede Anfrage für sich. Die Kennung muss trotzdem überall mitgeschickt werden.

HTTP ist nicht vergesslich, sondern absichtlich gedächtnislos. Die Sitzung entsteht erst durch die Kennung, die jede Anfrage mitbringt.

📌 Zustandslos · Cookie · Session-ID

📚 Webentwicklung von Grund auf · Tag 2 von 30
#webdev #HTTP #backend

Die meisten Einsteiger wählen in n8n oder Zapier die HTTP-Methode nach Gefühl. Dabei verrät die Methode dem Server genau, was mit den Daten passieren soll.

Wer die falsche Methode schickt, bekommt Daten, die keiner wollte – oder löscht einen Eintrag versehentlich. Die richtige Wahl spart Fehlersuche und verhindert doppelte Bestellungen.

🔗 GET liest nur und verändert nichts auf dem Server. Eine Ressource ist dabei alles, was eine eigene URL hat, etwa ein Kundendatensatz unter einer Adresse mit dessen Nummer. Wer Kundendaten abfragen will, schickt eine GET-Anfrage an die dokumentierte URL, hängt einen API-Schlüssel als Ausweis an und erhält Felder wie Name und E-Mail-Adresse. Den Body, also den Inhaltsteil der Anfrage, lässt GET meist leer.

🔁 POST übergibt Daten zur Verarbeitung und legt oft einen neuen Eintrag an, etwa eine Bestellung. Idempotent nennt man einen Vorgang, dessen mehrfache Ausführung dasselbe Ergebnis bringt wie die einmalige; POST ist das nicht. Schickt ein Workflow dieselbe POST-Anfrage zweimal, entstehen zwei Bestellungen. Genau hier beginnt saubere Fehlerbehandlung in Automatisierungen.

🧭 PUT ersetzt einen bestehenden Eintrag vollständig und braucht dessen genaue URL, DELETE löscht ihn. Beide gelten laut RFC 9110 als idempotent: Wiederholung schadet nicht. In n8n und Zapier wählt man die Methode im HTTP-Baustein aus einem Dropdown; vorher die Doku lesen, sonst antwortet der Server mit 404 (Ressource nicht gefunden) oder 400 (fehlerhafte Anfrage).

GET heißt nicht „einfachere POST“, sondern die Aussage: nichts verändern, nur lesen. Die Methode ist die Absicht, die URL das Ziel.

📌 GET lesen · POST übergeben · PUT ersetzen

📚 Automatisierung von Grund auf · Tag 2 von 30
#Automatisierung #n8n #api #Integration

Die Seite ist plötzlich nicht mehr erreichbar, der Browser zeigt eine Warnseite statt der Anwendung. Dabei hat sich am Code nichts geändert – nur ein Zertifikat ist still abgelaufen.

Die Nutzer sehen eine Fehlermeldung, die wie ein Sicherheitsproblem aussieht. Auch API-Aufrufe scheitern, weil Clients die Verbindung verweigern. Abgelaufene Zertifikate gehören zu den häufigsten vermeidbaren Ausfallursachen.

Der Grundbegriff dahinter ist das TLS-Zertifikat: eine digitale Bescheinigung, die eine Domain einem öffentlichen Schlüssel des Servers zuordnet. Sie ist von einer Zertifizierungsstelle unterschrieben, also einer anerkannten Ausstellerin, der der Browser vertraut. Ohne gültiges Zertifikat kann der Browser nicht ausschließen, dass sich ein fremder Server für den echten ausgibt – ein sogenannter Man-in-the-Middle.

Ein konkretes Beispiel: Zertifikate von Lets Encrypt sind 90 Tage gültig; die Erneuerung wird nach 60 Tagen empfohlen. Wer von Hand erneuert, vergisst es irgendwann. Die Erneuerung soll deshalb automatisiert laufen, etwa mit dem ACME-Protokoll (RFC 8555) und einem Client wie certbot. Bei der HTTP-Challenge legt der Client eine vom Server gestellte Datei unter einer bekannten URL auf dem Webserver ab; wer sie liefern kann, beweist die Kontrolle über die Domain.

So prüft man es: Das Monitoring sollte die Restlaufzeit jedes öffentlichen Zertifikats überwachen und Alarm schlagen, bevor sie abläuft. Zusätzlich gehört die Erneuerung in einen Timer oder Cron-Dienst, der automatisch läuft.

Ein Zertifikat beweist dem Browser nicht die Echtheit einer Seite, sondern dass eine anerkannte Stelle die Kontrolle über die Domain geprüft hat. Deshalb gilt: Erneuerung automatisieren, Restlaufzeit überwachen – sonst wird der Ablauf zum Ausfall.

📌 TLS-Zertifikat · Zertifizierungsstelle · Automatische Erneuerung

📚 Cloud von Grund auf · Tag 2 von 30
#CloudSecurity #monitoring #devops

Wer eine Bestellung per GET auslöst, riskiert Doppelkäufe ohne jede Absicht. Dabei sagt der Standard für HTTP längst, welche Methode was darf.

Viele Einsteiger halten GET und POST für zwei gleichwertige Türen: Hauptsache, die Anfrage kommt beim Server an. Das klingt plausibel, weil beide Daten transportieren können.

Tatsächlich unterscheidet RFC 9110, die aktuelle HTTP-Spezifikation, die Methoden nach zwei Eigenschaften. Sicher heißt: Die Methode verändert den Zustand des Servers nicht; GET, HEAD, OPTIONS und TRACE sind sicher. Idempotent heißt: Mehrere identische Anfragen wirken wie eine einzige; das gilt für PUT, DELETE und alle sicheren Methoden. POST und PATCH fallen heraus: Ein wiederholter POST kann eine zweite Ressource anlegen, etwa eine doppelte Bestellung.

Der Irrtum entsteht, weil HTML-Formulare nur GET und POST anbieten. Wer keine anderen Methoden kennt, wählt nach Syntax statt nach Bedeutung.

Eine Bestellung per GET zu senden endet im Browser-Cache: GET-Anfragen dürfen vorabgeladen oder zwischengespeichert werden; das kann unbeabsichtigte Ausführungen auslösen. Korrekt ist POST für die Erzeugung; wer POST wiederholbar machen will, sendet zusätzlich einen Idempotenz-Schlüssel. Das ist ein eindeutiger Wert, etwa eine UUID, im Request-Header; der Server speichert Schlüssel und Antwort und liefert bei Wiederholung dieselbe Antwort zurück.

Woran man es erkennt: Verändert die Anfrage etwas auf dem Server, reicht GET nie aus. Regel: Lesen mit GET, Erzeugen mit POST, vollständiges Ersetzen mit PUT.

Sicher heißt nicht wirkungslos, sondern nebenwirkungsfrei. Idempotent heißt nicht wirkungslos, sondern ohne Doppelwirkung.

📌 Sichere Methoden · Idempotenz · Idempotenz-Schlüssel

📚 Webentwicklung von Grund auf · Tag 2 von 30
#HTTP #REST #webdev #backend

Ein n8n-Schritt scheitert, und die Fehlermeldung sagt nur „400 Bad Request“. Dahinter steckt ein Muster, das jeder Austausch zwischen zwei Systemen gleich durchläuft.

Wer automatisiert, stößt unweigerlich auf HTTP, das Protokoll, mit dem Programme im Netz Nachrichten austauschen. Ohne dessen Aufbau zu kennen, rät man beim Debuggen im Blindflug herum.

Jede HTTP-Kommunikation folgt demselben Muster: Der Client, also das fragende System, schickt eine Anfrage; der Server antwortet einmal darauf. Die Anfrage besteht aus vier Teilen. Die Methode sagt, was geschehen soll: GET fordert eine Ressource an, POST übergibt Daten zur Verarbeitung, PUT ersetzt sie vollständig, DELETE löscht sie. Die Header tragen Zusatzangaben, etwa einen API-Schlüssel – eine geheime Zeichenfolge, mit der sich das Programm gegenüber einer API, der Programmschnittstelle eines Systems, ausweist. Der Body enthält die zu übergebenden Daten; bei GET bleibt er meist leer.

Ein Beispiel: n8n soll Daten an eine Tabellenkalkulation senden. Der Schritt „HTTP Request“ braucht Methode POST, die Ziel-URL aus der Dokumentation, im Header den API-Schlüssel und im Body die Daten. Klappt es nicht, gilt: erst den Statuscode der Antwort lesen. 200 heißt Erfolg, 404, dass es das Ziel nicht gibt, 401, dass der Ausweis fehlt, 500, dass der Server versagte.

Verwechselt wird HTTP gern mit der Schnittstelle selbst. Eine API ist das Angebot eines Systems; HTTP ist nur die Transportart. Auch 4xx und 5xx werden vermischt: 4xx verweist auf die eigene Anfrage, 5xx auf das fremde System – beides braucht unterschiedliche Maßnahmen.

HTTP ist nicht geheimnisvolles Unglück, sondern ein Brief mit Methode, Adresse, Kopfzeilen und Inhalt. Wer die vier Teile kennt, ordnet jeden Fehler einer Ursache zu.

📌 Methode und URL · Header mit Ausweis · Statuscode lesen

📚 Automatisierung von Grund auf · Tag 2 von 30
#Automatisierung #api #n8n #Webhooks

Ein toter Link im Browser – meist zeigt er „404 Not Found“. Dabei sagt diese Zahl weniger, als man denkt.

Jede Serverantwort im Web beginnt mit einem Statuscode, einer dreistelligen Nummer. Sie tritt überall auf: beim Aufruf einer Seite, beim Bookmark im Browser, beim Newsletter-Feed. Die erste Ziffer gibt die Klasse an, hier 4 für einen Fehler des Clients.

Zuerst sendet der Client eine Anfrage an eine URL, also eine Adresse im Web. Der Server sucht die angeforderte Ressource – eine Seite, ein Bild, einen Datensatz. Findet er sie nicht, antwortet er mit 404 Not Found.

Dann entscheidet der Client, was das bedeutet. Die erste Ziffer der Nummer nennt nur die Richtung: Bei 4xx liegt der Fehler meist in der eigenen Anfrage, etwa in einer falschen URL oder fehlender Berechtigung. Der Haken bei 404: Die Nummer sagt nichts über die Zukunft. Die Adresse kann nie existiert haben, vertippt sein oder erst morgen wieder erreichbar sein. Für den Client ist eine Löschung ununterscheidbar von einem Tippfehler in der URL.

Danach gibt es für den Fall der bewussten Löschung eine klarere Antwort: 410 Gone. Sie bedeutet, die Ressource existierte einst, wurde aber absichtlich und dauerhaft entfernt. Der Server weiß das und teilt es ausdrücklich mit.

Zuletzt kann der Client auf 410 höflicher reagieren: Ein Feed-Leser darf den Link als endgültig tot markieren und seine Wiederholungen einstellen. Bei 404 bleibt dagegen nur: immer wieder probieren. Praxisregel für eigene Backends: Nach dem Löschen einer Ressource 410 senden; 404 bleibt für unbekannte oder nie existierte Adressen.

404 heißt also nicht „gelöscht“, sondern „gerade nicht gefunden“ – erst 410 spricht von dauerhaft weg.

📌 Statuscode · 404 Not Found · 410 Gone

📚 Webentwicklung von Grund auf · Tag 2 von 30
#webdev #HTTP #backend

Der erste Workflow läuft nie an – der auslösende Schritt fehlt. Viele Einsteiger bauen zuerst die Verarbeitungsschritte und wundern sich später über die stille Automation.

Viele denken, ein Workflow in n8n starte einfach, sobald er fertig gebaut ist. Das klingt plausibel, weil man ihn beim Bauen manuell ausführen kann.

Tatsächlich braucht jede Automation einen Trigger, also das definierte Ereignis, das sie startet. n8n bietet dazu unter anderem drei Arten: den Schedule Trigger für Zeitpläne, den Webhook Node für HTTP-Aufrufe und Polling-Trigger für regelmäßige Abfragen. Ein Webhook startet den Workflow erst, wenn ein anderes System ihn aktiv aufruft und dabei Daten gleich mitschickt. Polling fragt dagegen in festen Abständen selbst nach, ob es Neues gibt.

Der Irrtum entsteht, weil die Trigger im Editor optisch wie jeder andere Node wirken. Ein Node ist jedoch ein einzelner Verarbeitungsschritt, und der erste davon muss zwingend der Auslöser sein.

Bei jedem Bestelleingang soll sofort eine E-Mail ausgelöst werden. Da die Aktualität wichtig ist und das Bestellsystem HTTP-Aufrufe senden kann, gehört ein Webhook an den Anfang. Die URL wird dort hinterlegt, und der Bestelldatensatz trifft als JSON-Inhalt ein. Ein Polling-Trigger in festen Abständen wäre hier zu langsam.

„Woran man es erkennt:“ Entscheidend ist der Anlass. Startet der Prozess zu einem festen Zeitpunkt unabhängig von Daten, passt der Zeitplan, etwa per Cron-Ausdruck, also einem Zeitplan in fünf Feldern von Minute bis Wochentag. Meldet ein anderes System aktiv ein Ereignis, passt der Webhook; entsteht der Anlass erst mit einem neuen Eintrag in einer Datenquelle, passt die Abfrage.

Trigger heißt nicht „Startknopf im Editor“, sondern definiertes Ereignis, das den Workflow wirklich auslöst.

📌 Schedule Trigger · Webhook · Polling

📚 Automatisierung von Grund auf · Tag 2 von 30
#n8n #Automatisierung #workflow #Webhooks