3 Std vor
Der Workflow läuft monatelang unauffällig durch. Bei der ersten Prüfung stellen viele fest: Der ganze Prozess war von Anfang an datenschutzrechtlich relevant.
In der Fehlersuche wird der komplette Datensatz durchgereicht, weil das Mapping so bequemer ist. Später stehen dann Namen und Kundennummern in Protokollen, die nur der Fehleranalyse dienen sollten.
Personenbezogene Daten sind nach Artikel 4 DSGVO alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, etwa Name, E-Mail-Adresse oder Kundennummer. Identifizierbar heißt dabei: Die Person muss nicht namentlich genannt sein. Es genügt, wenn sie sich mit verhältnismäßigen Mitteln ermitteln lässt, etwa über ein CRM-System mit der Kundennummer. Auch scheinbar neutrale Daten wie IP-Adressen, Telefonnummern oder pseudonyme Nutzer-IDs gelten als personenbezogen, solange die Zuordnung mit vertretbarem Aufwand möglich ist.
Ein typischer Fall: Ein Formular-Trigger nimmt Supportanfragen entgegen und übergibt die Felder an ein Ticket-System. Der Bearbeitungsschritt dort braucht nur die Frage und eine Kundennummer. Weil beim Mapping der komplette Datensatz übernommen wird, wandert auch die private E-Mail-Adresse in jedes Folgeprotokoll.
So prüft man es: Erst jeden Schritt des Workflows durchgehen und notieren, welche Felder hinein- und wieder herausfließen. Dann prüfen, ob jedes Feld allein schon einer Person zugeordnet werden kann, etwa über ein Kundenverzeichnis.
Datenminimierung heißt nicht, weniger zu automatisieren. Sie heißt, pro Schritt nur die Felder weiterzugeben, die dort wirklich gebraucht werden.
📌 Personenbezogene Daten · Datenminimierung · Ausführungsprotokolle
📚 Automatisierung von Grund auf · Tag 6 von 30
#Automatisierung #datenschutz #workflow #n8n
In der Fehlersuche wird der komplette Datensatz durchgereicht, weil das Mapping so bequemer ist. Später stehen dann Namen und Kundennummern in Protokollen, die nur der Fehleranalyse dienen sollten.
Personenbezogene Daten sind nach Artikel 4 DSGVO alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, etwa Name, E-Mail-Adresse oder Kundennummer. Identifizierbar heißt dabei: Die Person muss nicht namentlich genannt sein. Es genügt, wenn sie sich mit verhältnismäßigen Mitteln ermitteln lässt, etwa über ein CRM-System mit der Kundennummer. Auch scheinbar neutrale Daten wie IP-Adressen, Telefonnummern oder pseudonyme Nutzer-IDs gelten als personenbezogen, solange die Zuordnung mit vertretbarem Aufwand möglich ist.
Ein typischer Fall: Ein Formular-Trigger nimmt Supportanfragen entgegen und übergibt die Felder an ein Ticket-System. Der Bearbeitungsschritt dort braucht nur die Frage und eine Kundennummer. Weil beim Mapping der komplette Datensatz übernommen wird, wandert auch die private E-Mail-Adresse in jedes Folgeprotokoll.
So prüft man es: Erst jeden Schritt des Workflows durchgehen und notieren, welche Felder hinein- und wieder herausfließen. Dann prüfen, ob jedes Feld allein schon einer Person zugeordnet werden kann, etwa über ein Kundenverzeichnis.
Datenminimierung heißt nicht, weniger zu automatisieren. Sie heißt, pro Schritt nur die Felder weiterzugeben, die dort wirklich gebraucht werden.
📌 Personenbezogene Daten · Datenminimierung · Ausführungsprotokolle
📚 Automatisierung von Grund auf · Tag 6 von 30
#Automatisierung #datenschutz #workflow #n8n
6 Std vor
Terraform apply läuft, und plötzlich legt es eine zweite EC2-Instanz neben der bestehenden an. Das Symptom kennen viele bei ihren ersten Cloud-Projekten.
Trotz unveränderter Konfiguration entstehen doppelte Ressourcen in der Cloud. Die alten Instanzen laufen weiter und verursachen weiterhin Kosten.
Terraform hält in einer State-Datei fest, welche echten Cloud-Ressourcen zu welchem Konfigurationseintrag gehören. Dieser State ist Terraforms Gedächtnis: Er speichert den Zustand, den Terraform beim letzten apply beobachtet hat. Bei jedem Lauf vergleicht Terraform den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und die reale Cloud.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply liegt die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform bei einer späteren Änderung, dieselbe Instanz zu aktualisieren statt eine neue zu bauen. Ohne State entsteht beim nächsten apply eine doppelte Instanz.
So prüft man es: Nach terraform apply die Ausgabe darauf prüfen, ob sie nur beabsichtigte Änderungen zeigt. Erscheinen Ressourcen als komplett neu, fehlt vermutlich die Zuordnung im State.
Der State ist kein Protokoll, sondern ein Abbuchungsregister: Er entscheidet, welche echte Ressource beim Abbau entfernt wird. Deshalb gehört er geschützt in ein Remote-Backend, ein zentraler Ablageort für den State, etwa ein S3-Bucket; dort verhindert State-Locking, dass zwei Läufe gleichzeitig denselben State überschreiben. Weil der State Klartext wie Passwörter enthalten kann, hat er nichts in Git verloren.
Ein verlorener State lässt sich über Import-Werkzeuge teilweise zurückholen. Einfacher ist es, ihn nie zu verlieren.
State heißt nicht Nebenprodukt, sondern Gedächtnis ohne Rückversicherung.
📌 State-Datei · Remote-Backend · State-Locking
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
Trotz unveränderter Konfiguration entstehen doppelte Ressourcen in der Cloud. Die alten Instanzen laufen weiter und verursachen weiterhin Kosten.
Terraform hält in einer State-Datei fest, welche echten Cloud-Ressourcen zu welchem Konfigurationseintrag gehören. Dieser State ist Terraforms Gedächtnis: Er speichert den Zustand, den Terraform beim letzten apply beobachtet hat. Bei jedem Lauf vergleicht Terraform den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und die reale Cloud.
In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply liegt die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform bei einer späteren Änderung, dieselbe Instanz zu aktualisieren statt eine neue zu bauen. Ohne State entsteht beim nächsten apply eine doppelte Instanz.
So prüft man es: Nach terraform apply die Ausgabe darauf prüfen, ob sie nur beabsichtigte Änderungen zeigt. Erscheinen Ressourcen als komplett neu, fehlt vermutlich die Zuordnung im State.
Der State ist kein Protokoll, sondern ein Abbuchungsregister: Er entscheidet, welche echte Ressource beim Abbau entfernt wird. Deshalb gehört er geschützt in ein Remote-Backend, ein zentraler Ablageort für den State, etwa ein S3-Bucket; dort verhindert State-Locking, dass zwei Läufe gleichzeitig denselben State überschreiben. Weil der State Klartext wie Passwörter enthalten kann, hat er nichts in Git verloren.
Ein verlorener State lässt sich über Import-Werkzeuge teilweise zurückholen. Einfacher ist es, ihn nie zu verlieren.
State heißt nicht Nebenprodukt, sondern Gedächtnis ohne Rückversicherung.
📌 State-Datei · Remote-Backend · State-Locking
📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops
14 Std vor
LoRaWAN funktioniert wie ein Briefkasten am Feldweg: weit entfernt, aber nur für kurze Notizen.
Vorstellbar ist ein Bauer, der seinem Nachbarn kilometerweit drüben winkt. Bei Wind und Distanz versteht der Nachbar kein ganzes Wort. Aber ein einziges kurz signalisiertes „Alles gut!“ kommt an. Der Bauer schreit nicht lange durcheinander, sondern sendet ein knappes Zeichen und schweigt dann.
Genauso funktioniert das LoRaWAN-Netz, ein Funkprotokoll für kleine Sensornachrichten über viele Kilometer. Ein Sensor sendet nur wenige Bytes und verstummt dann lange. Die Reichweite entsteht nicht durch lautes Senden, sondern durch langsames, geduldiges Sprechen.
Fachlich entspricht das Schweigen dem Duty Cycle: In den meisten Teilbändern des EU868-Bands um 868 MHz darf ein Gerät im Mittel höchstens 1 % der Zeit senden. Das langsame, geduldige Sprechen ist der Spreading Factor (SF7 bis SF12): Er zieht jedes Datenbit über viele Chips, also kurze Funkimpulse, auseinander. Das kurz gesprochene Zeichen selbst sind die wenigen Bytes Nutzdaten. Höherer SF heißt mehr Reichweite, aber auch längere Airtime, also die Zeit, die eine Nachricht den Kanal belegt. In The Things Network darf ein Gerät daher nur 30 Sekunden Uplink-Airtime pro Tag (Uplink: Richtung vom Gerät zum Netz) nutzen.
Konkret meldet etwa ein Bodenfeuchtesensor auf dem Feld zweimal täglich Temperatur und Luftfeuchte als binär kodierte Werte. Ein Füllstandsmesser im Brunnen passt ebenso; ein Feldbus oder Videostream niemals.
Das Bild hat eine Grenze: Der Bauer muss nicht nach dem Winken lauschen. Ein Klasse-A-Gerät öffnet nur zwei kurze Empfangsfenster nach dem eigenen Uplink, Klasse C hört dauernd und verbraucht mehr Strom.
LoRaWAN erkauft Reichweite also mit schmaler Bandbreite und kurzen Nachrichten, nicht mit schnellem Datentransport.
📌 Airtime · Duty Cycle · Spreading Factor
📚 IoT von Grund auf · Tag 5 von 30
#lorawan #iot #sensorik
Vorstellbar ist ein Bauer, der seinem Nachbarn kilometerweit drüben winkt. Bei Wind und Distanz versteht der Nachbar kein ganzes Wort. Aber ein einziges kurz signalisiertes „Alles gut!“ kommt an. Der Bauer schreit nicht lange durcheinander, sondern sendet ein knappes Zeichen und schweigt dann.
Genauso funktioniert das LoRaWAN-Netz, ein Funkprotokoll für kleine Sensornachrichten über viele Kilometer. Ein Sensor sendet nur wenige Bytes und verstummt dann lange. Die Reichweite entsteht nicht durch lautes Senden, sondern durch langsames, geduldiges Sprechen.
Fachlich entspricht das Schweigen dem Duty Cycle: In den meisten Teilbändern des EU868-Bands um 868 MHz darf ein Gerät im Mittel höchstens 1 % der Zeit senden. Das langsame, geduldige Sprechen ist der Spreading Factor (SF7 bis SF12): Er zieht jedes Datenbit über viele Chips, also kurze Funkimpulse, auseinander. Das kurz gesprochene Zeichen selbst sind die wenigen Bytes Nutzdaten. Höherer SF heißt mehr Reichweite, aber auch längere Airtime, also die Zeit, die eine Nachricht den Kanal belegt. In The Things Network darf ein Gerät daher nur 30 Sekunden Uplink-Airtime pro Tag (Uplink: Richtung vom Gerät zum Netz) nutzen.
Konkret meldet etwa ein Bodenfeuchtesensor auf dem Feld zweimal täglich Temperatur und Luftfeuchte als binär kodierte Werte. Ein Füllstandsmesser im Brunnen passt ebenso; ein Feldbus oder Videostream niemals.
Das Bild hat eine Grenze: Der Bauer muss nicht nach dem Winken lauschen. Ein Klasse-A-Gerät öffnet nur zwei kurze Empfangsfenster nach dem eigenen Uplink, Klasse C hört dauernd und verbraucht mehr Strom.
LoRaWAN erkauft Reichweite also mit schmaler Bandbreite und kurzen Nachrichten, nicht mit schnellem Datentransport.
📌 Airtime · Duty Cycle · Spreading Factor
📚 IoT von Grund auf · Tag 5 von 30
#lorawan #iot #sensorik
15 Std vor
Die meisten Einsteiger ändern beim ersten Fehler sofort den Workflow. Dabei steht die Antwort längst im Protokoll des gescheiterten Laufs.
Jede Ausführung eines Workflows, in n8n „Execution“ genannt, wird vom Werkzeug automatisch aufgezeichnet. Auch Zapier führt ein solches Protokoll, in dem steht, was ein Lauf wann getan hat und wo er scheiterte.
Zuerst läuft der Workflow einmal vollständig durch: Ein Webhook, also ein automatischer Anruf von außen, oder ein Zeitplan startet die Verarbeitung. n8n speichert für diesen Lauf die Ein- und Ausgaben jedes einzelnen Nodes, also jedes Verarbeitungsschritts. Was gespeichert wird und wie lange, ist konfigurierbar und betrifft Speicherplatz und Datenschutz.
Dann notiert das Werkzeug für jeden Lauf drei Kernangaben: den Zeitstempel, also wann der Lauf begann, den Status, etwa „erfolgreich“ oder „fehlgeschlagen“, und die verarbeiteten Datenwerte. Zusammen ergeben sie das Gedächtnis des Laufs.
Danach öffnet man bei einem Fehlschlag zuerst die Datenanzeige unter dem betroffenen Node. Sie zeigt, welche Elemente hineingekommen sind und was der Node daraus gemacht hat. Sind die Eingaben lückenhaft, liegt ein Datenfehler vor, etwa ein fehlendes oder falsch benanntes Feld. Antwortet das Zielsystem mit einem Statuscode wie 503 aus der Klasse 5xx, hat es die Anfrage erhalten und selbst versagt; die Ursache liegt beim Anbieter.
Zuletzt hilft die Unterscheidung, dass ein Lauf an drei Orten scheitern kann: am eigenen Netz, an den übergebenen Daten oder am fremden Zielsystem. Erst danach wird der Workflow geändert und zur Versionierung als JSON exportiert.
Der Fehlerlauf ist die Diagnose, nicht der Verdächtige: erst lesen, dann ändern. Enthält der Lauf personenbezogene Daten, ist die Speicherdauer eine bewusste Datenschutz-Entscheidung, kein Zufall.
📌 Zeitstempel · Status · Ein- und Ausgaben je Node
📚 Automatisierung von Grund auf · Tag 5 von 30
#n8n #Automatisierung #nocode
Jede Ausführung eines Workflows, in n8n „Execution“ genannt, wird vom Werkzeug automatisch aufgezeichnet. Auch Zapier führt ein solches Protokoll, in dem steht, was ein Lauf wann getan hat und wo er scheiterte.
Zuerst läuft der Workflow einmal vollständig durch: Ein Webhook, also ein automatischer Anruf von außen, oder ein Zeitplan startet die Verarbeitung. n8n speichert für diesen Lauf die Ein- und Ausgaben jedes einzelnen Nodes, also jedes Verarbeitungsschritts. Was gespeichert wird und wie lange, ist konfigurierbar und betrifft Speicherplatz und Datenschutz.
Dann notiert das Werkzeug für jeden Lauf drei Kernangaben: den Zeitstempel, also wann der Lauf begann, den Status, etwa „erfolgreich“ oder „fehlgeschlagen“, und die verarbeiteten Datenwerte. Zusammen ergeben sie das Gedächtnis des Laufs.
Danach öffnet man bei einem Fehlschlag zuerst die Datenanzeige unter dem betroffenen Node. Sie zeigt, welche Elemente hineingekommen sind und was der Node daraus gemacht hat. Sind die Eingaben lückenhaft, liegt ein Datenfehler vor, etwa ein fehlendes oder falsch benanntes Feld. Antwortet das Zielsystem mit einem Statuscode wie 503 aus der Klasse 5xx, hat es die Anfrage erhalten und selbst versagt; die Ursache liegt beim Anbieter.
Zuletzt hilft die Unterscheidung, dass ein Lauf an drei Orten scheitern kann: am eigenen Netz, an den übergebenen Daten oder am fremden Zielsystem. Erst danach wird der Workflow geändert und zur Versionierung als JSON exportiert.
Der Fehlerlauf ist die Diagnose, nicht der Verdächtige: erst lesen, dann ändern. Enthält der Lauf personenbezogene Daten, ist die Speicherdauer eine bewusste Datenschutz-Entscheidung, kein Zufall.
📌 Zeitstempel · Status · Ein- und Ausgaben je Node
📚 Automatisierung von Grund auf · Tag 5 von 30
#n8n #Automatisierung #nocode
17 Std vor
Der Lichtbefehl kommt per App an, der Sensorwert aber fehlt. Beides lief über denselben Broker, doch nur eine Nachricht hat überlebt.
Ein Temperatursensor meldet Lücken im Verlauf, etwa wenn die WLAN-Verbindung kurz abbricht. Der Schaltbefehl an die Steckdose kommt dagegen zuverlässig an, manchmal sogar doppelt.
MQTT heißt das Protokoll, über das IoT-Geräte Nachrichten austauschen. Geräte senden und empfangen dabei nicht direkt untereinander, sondern immer über einen zentralen Broker, der alle Nachrichten annimmt und verteilt. Jede Nachricht bekommt eine QoS-Stufe mit: QoS steht für Quality of Service und legt fest, wie stark sich Absender und Broker um die Zustellung bemühen. Der Unterschied zwischen Sensorwert und Befehl entsteht also schon beim Senden, nicht zufällig unterwegs.
Ein Sensor veröffentlicht alle paar Minuten den Wert im Topic wohnzimmer/temperatur, etwa mit QoS 0. QoS 0 sendet die Nachricht und vergisst sie: Ohne Bestätigung bleibt eine verlorene Nachricht verloren. Weil die nächste Messung bald folgt, ist das verschmerzbar. Der Schaltbefehl an die Steckdose geht mit QoS 1: Der Broker bestätigt jede Nachricht, und fehlt die Bestätigung, sendet der Client erneut. So kommt der Befehl mindestens einmal an, Duplikate sind möglich. Damit ein Duplikat nicht doppelt schaltet, setzt der Empfänger einen Zielszustand statt eines Zählschritts. QoS 2 liefert genau einmal, braucht dafür aber einen vierstufigen Handshake mit mehr Zeit und Volumen.
So prüft man es: Im Log des Clients die QoS-Stufe neben jedem Publish und Subscribe nachsehen. Dann gezielt die Verbindung unterbrechen und zählen, welche Nachrichten ankommen.
QoS heißt nicht „besser ist immer höher“, sondern „passend zum Inhalt“. Messwerte dürfen fehlen, Befehle müssen ankommen.
📌 QoS 0/1/2 · Broker · Duplikate
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
Ein Temperatursensor meldet Lücken im Verlauf, etwa wenn die WLAN-Verbindung kurz abbricht. Der Schaltbefehl an die Steckdose kommt dagegen zuverlässig an, manchmal sogar doppelt.
MQTT heißt das Protokoll, über das IoT-Geräte Nachrichten austauschen. Geräte senden und empfangen dabei nicht direkt untereinander, sondern immer über einen zentralen Broker, der alle Nachrichten annimmt und verteilt. Jede Nachricht bekommt eine QoS-Stufe mit: QoS steht für Quality of Service und legt fest, wie stark sich Absender und Broker um die Zustellung bemühen. Der Unterschied zwischen Sensorwert und Befehl entsteht also schon beim Senden, nicht zufällig unterwegs.
Ein Sensor veröffentlicht alle paar Minuten den Wert im Topic wohnzimmer/temperatur, etwa mit QoS 0. QoS 0 sendet die Nachricht und vergisst sie: Ohne Bestätigung bleibt eine verlorene Nachricht verloren. Weil die nächste Messung bald folgt, ist das verschmerzbar. Der Schaltbefehl an die Steckdose geht mit QoS 1: Der Broker bestätigt jede Nachricht, und fehlt die Bestätigung, sendet der Client erneut. So kommt der Befehl mindestens einmal an, Duplikate sind möglich. Damit ein Duplikat nicht doppelt schaltet, setzt der Empfänger einen Zielszustand statt eines Zählschritts. QoS 2 liefert genau einmal, braucht dafür aber einen vierstufigen Handshake mit mehr Zeit und Volumen.
So prüft man es: Im Log des Clients die QoS-Stufe neben jedem Publish und Subscribe nachsehen. Dann gezielt die Verbindung unterbrechen und zählen, welche Nachrichten ankommen.
QoS heißt nicht „besser ist immer höher“, sondern „passend zum Inhalt“. Messwerte dürfen fehlen, Befehle müssen ankommen.
📌 QoS 0/1/2 · Broker · Duplikate
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
1 Tag vor
Terraform funktioniert wie ein Stadtplaner mit einem Grundbuch. Ohne das Grundbuch wüsste er nicht, welche Grundstücke ihm überhaupt gehören.
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
1 Tag vor
Ein Sensor schickt Temperaturwerte, und das Display zeigt trotzdem Schaltbefehle mit an. Beides landet in einem einzigen Thema, das keiner sauber abonnieren kann.
Viele denken, ein Topic sei nur eine Beschriftung und die Auswahl der Nachrichten erledigt man am besten selbst. Das klingt plausibel, weil ein flacher Name wie messwerte einfacher wirkt als eine verschachtelte Adresse.
Tatsächlich ist ein Topic die Adresse einer Nachricht im MQTT-System, dem Nachrichtenprotokoll, mit dem Geräte Daten austauschen; sie ist ähnlich aufgebaut wie ein Ordnerpfad im Dateisystem. Der Schrägstrich trennt Ebenen, und die Reihenfolge geht vom Allgemeinen zum Besonderen: haus/wohnzimmer/temperatur. Beim Abonnieren erlaubt MQTT Wildcards: das Plus steht für genau eine Ebene, die Raute für alle folgenden Ebenen und darf nur am Ende stehen.
Der Irrtum entsteht, weil Einsteiger die Hierarchie nicht gliedern und dann jede Nachricht mitlesen. Die gewünschten Werte per Textfilter selbst herauszusuchen wirkt schnell, liest dann aber jede Nachricht mit und belastet den Mikrocontroller unnötig.
Ein Sensor schreibt in haus/wohnzimmer/temperatur und haus/kueche/temperatur. Ein Display abonniert haus/+/temperatur und erhält beide Werte mit einem Abonnement. Befehle liegen getrennt in haus/wohnzimmer/relay/gesetzt, damit das Display keine Schaltbefehle empfängt.
Woran man es erkennt: Stehen Messgröße und Befehl in verschiedenen Zweigen, ist die Struktur richtig. Läuft alles durch ein flaches Topic, fehlt die Gliederung.
Topic heißt nicht eine Beschriftung für alles, sondern eine Adresse mit Ebenen. Wer gut gliedert, wählt mit Plus und Raute aus, statt selbst zu filtern.
📌 Schrägstrich als Ebene · Plus für eine Ebene · Raute für alles darunter
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
Viele denken, ein Topic sei nur eine Beschriftung und die Auswahl der Nachrichten erledigt man am besten selbst. Das klingt plausibel, weil ein flacher Name wie messwerte einfacher wirkt als eine verschachtelte Adresse.
Tatsächlich ist ein Topic die Adresse einer Nachricht im MQTT-System, dem Nachrichtenprotokoll, mit dem Geräte Daten austauschen; sie ist ähnlich aufgebaut wie ein Ordnerpfad im Dateisystem. Der Schrägstrich trennt Ebenen, und die Reihenfolge geht vom Allgemeinen zum Besonderen: haus/wohnzimmer/temperatur. Beim Abonnieren erlaubt MQTT Wildcards: das Plus steht für genau eine Ebene, die Raute für alle folgenden Ebenen und darf nur am Ende stehen.
Der Irrtum entsteht, weil Einsteiger die Hierarchie nicht gliedern und dann jede Nachricht mitlesen. Die gewünschten Werte per Textfilter selbst herauszusuchen wirkt schnell, liest dann aber jede Nachricht mit und belastet den Mikrocontroller unnötig.
Ein Sensor schreibt in haus/wohnzimmer/temperatur und haus/kueche/temperatur. Ein Display abonniert haus/+/temperatur und erhält beide Werte mit einem Abonnement. Befehle liegen getrennt in haus/wohnzimmer/relay/gesetzt, damit das Display keine Schaltbefehle empfängt.
Woran man es erkennt: Stehen Messgröße und Befehl in verschiedenen Zweigen, ist die Struktur richtig. Läuft alles durch ein flaches Topic, fehlt die Gliederung.
Topic heißt nicht eine Beschriftung für alles, sondern eine Adresse mit Ebenen. Wer gut gliedert, wählt mit Plus und Raute aus, statt selbst zu filtern.
📌 Schrägstrich als Ebene · Plus für eine Ebene · Raute für alles darunter
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
1 Tag vor
Viele Teams wollen eine Blockchain, weil sie „manipulationssicher“ klingt. Dann wundern sie sich, warum Schreibvorgänge langsamer sind als in ihrer gewohnten Datenbank.
Das Register schreibt träger als geplant, und der Betrieb kostet mehr. Zudem fehlt eine zentrale Stelle, die bei Streit einfach entscheidet.
Eine Blockchain ist ein verteiltes, manipulationsresistentes Register: Transaktionen werden in verketteten Blöcken ohne zentrale Instanz festgehalten. Viele Teilnehmer halten identische Kopien vor, und die Mehrheit muss jede Änderung anerkennen. Ein Konsensverfahren legt fest, wie die Teilnehmer sich auf den nächsten Block einigen, etwa Proof of Work oder Proof of Stake. Genau diese Verteilung macht Schreiben langsamer, nicht schneller.
Jeder Block enthält einen Hash, also eine kryptografische Prüfsumme, des vorherigen Blocks. Ein Hash ist ein digitaler Fingerabdruck fester Länge, der sich bei kleinster Änderung komplett ändert. Wird ein früherer Block verändert, bricht die Verkettung zu allen Folgeblöcken erkennbar auf.
Mehrere Parteien ohne gegenseitiges Vertrauen führen so ein gemeinsames Register. Hyperledger Fabric ist ein solches geschlossenes Netz mit bekannten Teilnehmern, Zugriffskontrolle und ohne eigene Kryptowährung; die Konsensverfahren sind dort abstimmungsbasiert. Gibt es eine vertrauenswürdige Instanz oder nur eine schreibende Partei, ist eine klassische Datenbank mit Protokollierung einfacher, schneller und günstiger.
So prüft man es: Vor jedem Einsatz klären, wer schreibt, wer liest und warum keine zentrale Stelle gewünscht ist. Lässt sich das nicht begründen, fällt die Entscheidung auf eine Datenbank.
Eine Blockchain heißt nicht schnell, sondern gemeinsam geführt und kaum nachträglich änderbar. Ihre Stärke ist Manipulationssicherheit ohne zentrale Instanz.
📌 Blockchain · Hash · Konsens
📚 Zukunftstechnologien verstehen · Tag 5 von 30
#architektur #DigitaleTransformation
Das Register schreibt träger als geplant, und der Betrieb kostet mehr. Zudem fehlt eine zentrale Stelle, die bei Streit einfach entscheidet.
Eine Blockchain ist ein verteiltes, manipulationsresistentes Register: Transaktionen werden in verketteten Blöcken ohne zentrale Instanz festgehalten. Viele Teilnehmer halten identische Kopien vor, und die Mehrheit muss jede Änderung anerkennen. Ein Konsensverfahren legt fest, wie die Teilnehmer sich auf den nächsten Block einigen, etwa Proof of Work oder Proof of Stake. Genau diese Verteilung macht Schreiben langsamer, nicht schneller.
Jeder Block enthält einen Hash, also eine kryptografische Prüfsumme, des vorherigen Blocks. Ein Hash ist ein digitaler Fingerabdruck fester Länge, der sich bei kleinster Änderung komplett ändert. Wird ein früherer Block verändert, bricht die Verkettung zu allen Folgeblöcken erkennbar auf.
Mehrere Parteien ohne gegenseitiges Vertrauen führen so ein gemeinsames Register. Hyperledger Fabric ist ein solches geschlossenes Netz mit bekannten Teilnehmern, Zugriffskontrolle und ohne eigene Kryptowährung; die Konsensverfahren sind dort abstimmungsbasiert. Gibt es eine vertrauenswürdige Instanz oder nur eine schreibende Partei, ist eine klassische Datenbank mit Protokollierung einfacher, schneller und günstiger.
So prüft man es: Vor jedem Einsatz klären, wer schreibt, wer liest und warum keine zentrale Stelle gewünscht ist. Lässt sich das nicht begründen, fällt die Entscheidung auf eine Datenbank.
Eine Blockchain heißt nicht schnell, sondern gemeinsam geführt und kaum nachträglich änderbar. Ihre Stärke ist Manipulationssicherheit ohne zentrale Instanz.
📌 Blockchain · Hash · Konsens
📚 Zukunftstechnologien verstehen · Tag 5 von 30
#architektur #DigitaleTransformation
2 Tage vor
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
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
2 Tage vor
Die meisten Docker-Neulinge wundern sich, warum jeder Build Minuten dauert. Dabei entscheidet oft weniger die Größe des Projekts über die Bauzeit, sondern die Reihenfolge der Zeilen im Dockerfile.
Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.
📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.
🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.
📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.
Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.
📌 Schichten · Build-Cache · Anweisungsreihenfolge
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.
📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.
🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.
📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.
Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.
📌 Schichten · Build-Cache · Anweisungsreihenfolge
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
2 Tage vor
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
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
2 Tage vor
Viele Dockerfiles beginnen damit, das gesamte Projekt per COPY zu kopieren. Dabei zerstört jede Quellcode-Änderung den gesamten Build-Cache.
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
Wer ein Dockerfile schreibt, begegnet sofort dem Build-Cache. Wer ihn nicht kennt, wartet bei jedem Neubau Minuten statt Sekunden.
Ein Dockerfile ist eine Liste von Anweisungen, die mit docker build zu einem Image (einer startfertigen Vorlage für Container) verarbeitet wird. Jede Anweisung erzeugt eine Schicht, also das Änderungsprotokoll dieser einen Zeile im Dateisystem. Das Image ist ein Stapel dieser Schichten; docker run startet daraus den Container.
Der Cache prüft beim Neubau jede Anweisung von oben nach unten. Ist eine Zeile unverändert, wird ihre Schicht samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Zeile wird alles Folgende neu gebaut, auch wenn es sich gar nicht verändert hat.
Konkret: Zuerst FROM, also die Wahl des Basis-Images als Startpunkt, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes und der Startbefehl. Ändert sich nur der Quellcode, bleibt die teure Installation im Cache. Steht die Quellcode-Zeile dagegen oben, läuft RUN bei jeder kleinen Änderung erneut.
Verwechselt wird der Cache gern mit dem Build-Kontext, also dem Verzeichnis, das dem Build als Quelle dient. Der Kontext bestimmt, welche Dateien überhaupt an COPY übergeben werden; der Cache bestimmt, welche Schichten wiederverwendet werden. Eine .dockerignore-Datei hält Unnötiges wie .git aus dem Kontext fern und beschleunigt den Build zusätzlich.
Der Build-Cache belohnt nicht die schönste Zeile, sondern die stabilste Reihenfolge: Selten Geändertes nach oben, Häufig Geändertes nach unten.
📌 Layer · Build-Cache · Reihenfolge im Dockerfile
📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting
3 Tage vor
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
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
3 Tage vor
Die Automation läuft, aber die Bestätigungs-E-Mail kommt erst Minuten später an. Wer „jede Minute prüfen" eingestellt hat, hält das für Echtzeit – ist es aber nicht.
Der Zeitplan-Trigger (der startet einen Workflow, also eine automatisierte Ablaufkette, nach einem festen Zeitplan) läuft im Minutentakt, trotzdem landen neue Ereignisse verspätet im Workflow. Gleichzeitig sammeln sich viele Läufe ohne neues Ergebnis im Ausführungsprotokoll.
Der Grundbegriff dahinter ist der Unterschied zwischen Polling und Webhook. Beim Polling fragt ein System eine Quelle in festen Abständen ab, ob es Neues gibt – meist mit einer GET-Anfrage, also einer reinen Leseanfrage an die API (die Schnittstelle eines fremden Systems). Ein Webhook meldet sich selbst: Das fremde System schickt eine POST-Anfrage mit den Ereignisdaten an eine vorher hinterlegte URL. Polling ist so aktuell wie der Abstand zwischen zwei Abfragen; ein Webhook trifft im Moment des Ereignisses ein.
Ein Bestellsystem soll bei jeder neuen Bestellung automatisch eine Rechnung anlegen. Bietet es einen Webhook für neue Bestellungen, meldet es sich selbst. Bietet es nur eine API, fragt ein Zeitplan-Trigger etwa alle fünf Minuten nach – die Bestellung landet je nach Takt erst Minuten später im Workflow. Ein enger Takt erzeugt zudem unnötige Anfragen und kann ein Rate-Limit auslösen, also die erlaubte Höchstzahl an Anfragen; dann antwortet die API mit dem Statuscode 429.
So prüft man es: Zuerst in der Dokumentation des Systems nach „Webhooks" suchen und prüfen, welche Ereignisse es meldet. Fehlt ein Webhook, bleibt Polling – dann den größten Takt wählen, den die Verzögerung noch erlaubt.
Polling heißt nicht schlechter, sondern Nachschlagen auf Abruf. Wer Ereignisse ohne Verzögerung braucht, verlangt eine Meldung statt einer Frage.
📌 Polling · Webhook · Rate-Limit
📚 Automatisierung von Grund auf · Tag 3 von 30
#Automatisierung #Webhooks #workflow
Der Zeitplan-Trigger (der startet einen Workflow, also eine automatisierte Ablaufkette, nach einem festen Zeitplan) läuft im Minutentakt, trotzdem landen neue Ereignisse verspätet im Workflow. Gleichzeitig sammeln sich viele Läufe ohne neues Ergebnis im Ausführungsprotokoll.
Der Grundbegriff dahinter ist der Unterschied zwischen Polling und Webhook. Beim Polling fragt ein System eine Quelle in festen Abständen ab, ob es Neues gibt – meist mit einer GET-Anfrage, also einer reinen Leseanfrage an die API (die Schnittstelle eines fremden Systems). Ein Webhook meldet sich selbst: Das fremde System schickt eine POST-Anfrage mit den Ereignisdaten an eine vorher hinterlegte URL. Polling ist so aktuell wie der Abstand zwischen zwei Abfragen; ein Webhook trifft im Moment des Ereignisses ein.
Ein Bestellsystem soll bei jeder neuen Bestellung automatisch eine Rechnung anlegen. Bietet es einen Webhook für neue Bestellungen, meldet es sich selbst. Bietet es nur eine API, fragt ein Zeitplan-Trigger etwa alle fünf Minuten nach – die Bestellung landet je nach Takt erst Minuten später im Workflow. Ein enger Takt erzeugt zudem unnötige Anfragen und kann ein Rate-Limit auslösen, also die erlaubte Höchstzahl an Anfragen; dann antwortet die API mit dem Statuscode 429.
So prüft man es: Zuerst in der Dokumentation des Systems nach „Webhooks" suchen und prüfen, welche Ereignisse es meldet. Fehlt ein Webhook, bleibt Polling – dann den größten Takt wählen, den die Verzögerung noch erlaubt.
Polling heißt nicht schlechter, sondern Nachschlagen auf Abruf. Wer Ereignisse ohne Verzögerung braucht, verlangt eine Meldung statt einer Frage.
📌 Polling · Webhook · Rate-Limit
📚 Automatisierung von Grund auf · Tag 3 von 30
#Automatisierung #Webhooks #workflow
3 Tage vor
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
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
3 Tage vor
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
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
3 Tage vor
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
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
4 Tage vor
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
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
4 Tage vor
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
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
4 Tage vor
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
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
4 Tage vor
Die meisten Dateien landen in der Cloud auf einem von zwei ganz verschiedenen Wegen. Dabei entscheidet die Wahl des Wegs, wie schnell eine Anwendung läuft und wie teuer das Speichern wird.
Wer eine virtuelle Maschine startet, also einen nachgebildeten Rechner mit eigenem Betriebssystem wie Linux oder Windows, trifft die Entscheidung sofort: Das System braucht ein Laufwerk. Wer den Unterschied nicht kennt, mountet den Objektspeicher wie ein Netzlaufwerk und wundert sich, warum zeichenweises Bearbeiten nicht funktioniert.
Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten in Buckets ab. Jede Datei wird als abgeschlossenes Ganzes unter einem eindeutigen Schlüssel gespeichert, etwa einem langen Dateinamen; einzelne Bytes lassen sich nicht ändern, sondern nur das ganze Objekt neu schreiben. Blockspeicher wie EBS zerlegt Daten in gleich große Blöcke und blendet sie der virtuellen Maschine als Festplatte ein, auf der das Betriebssystem ein Dateisystem anlegt und Dateien beliebig ändert.
Konkret: Eine EC2-Instanz, so heißt die virtuelle Maschine bei AWS, bootet von ihrem EBS-Laufwerk; dort liegen Betriebssystem und installierte Software, weil viele kleine Dateien schnelle Lese- und Schreibzugriffe brauchen. Ein Upload-Verzeichnis mit Bildern und Videos gehört dagegen in einen S3-Bucket, weil dort unbegrenzt viele Objekte dauerhaft ohne Laufwerksgröße abgelegt werden. Auch Backups und Protokolldateien gehören dorthin. Speicherkosten fallen dabei auch ohne laufende Anwendung an, solange die Daten existieren.
Verwechselt wird der Objektspeicher oft mit einem Netzlaufwerk oder einer Datenbank. Er ist für das Speichern und Abrufen ganzer Dateien gebaut, nicht für zeichenweises Bearbeiten.
📌 Objektspeicher · Blockspeicher · Zuordnung der Daten
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #Backup
Wer eine virtuelle Maschine startet, also einen nachgebildeten Rechner mit eigenem Betriebssystem wie Linux oder Windows, trifft die Entscheidung sofort: Das System braucht ein Laufwerk. Wer den Unterschied nicht kennt, mountet den Objektspeicher wie ein Netzlaufwerk und wundert sich, warum zeichenweises Bearbeiten nicht funktioniert.
Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten in Buckets ab. Jede Datei wird als abgeschlossenes Ganzes unter einem eindeutigen Schlüssel gespeichert, etwa einem langen Dateinamen; einzelne Bytes lassen sich nicht ändern, sondern nur das ganze Objekt neu schreiben. Blockspeicher wie EBS zerlegt Daten in gleich große Blöcke und blendet sie der virtuellen Maschine als Festplatte ein, auf der das Betriebssystem ein Dateisystem anlegt und Dateien beliebig ändert.
Konkret: Eine EC2-Instanz, so heißt die virtuelle Maschine bei AWS, bootet von ihrem EBS-Laufwerk; dort liegen Betriebssystem und installierte Software, weil viele kleine Dateien schnelle Lese- und Schreibzugriffe brauchen. Ein Upload-Verzeichnis mit Bildern und Videos gehört dagegen in einen S3-Bucket, weil dort unbegrenzt viele Objekte dauerhaft ohne Laufwerksgröße abgelegt werden. Auch Backups und Protokolldateien gehören dorthin. Speicherkosten fallen dabei auch ohne laufende Anwendung an, solange die Daten existieren.
Verwechselt wird der Objektspeicher oft mit einem Netzlaufwerk oder einer Datenbank. Er ist für das Speichern und Abrufen ganzer Dateien gebaut, nicht für zeichenweises Bearbeiten.
📌 Objektspeicher · Blockspeicher · Zuordnung der Daten
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #Backup
4 Tage vor
Ein Briefumschlag funktioniert wie eine HTTP-Antwort: Man erkennt am ersten Blick, wie er ausgegangen ist. Bei Statuscodes verrät die erste Ziffer diese Richtung.
Stellen Sie sich die Poststelle einer Behörde vor. Der Sachbearbeiter prüft den Antrag und stempelt ihn: grüner Stempel bedeutet erledigt, ein gelber bedeutet „woanders vorstellig werden“, ein roter mit Ihrer Nummer bedeutet Fehler im Antrag, ein roter mit seiner Nummer bedeutet Störung im Amt. Wer den Stempel sieht, weiß sofort, wo die Suche beginnt. Die Nummer auf dem Stempel nennt das genaue Büro. Der Farbcode aber nennt die Richtung.
So arbeitet HTTP, das Protokoll (Regelwerk) des Webs. Jede Serverantwort beginnt mit einem Statuscode, einer dreistelligen Nummer, die das Ergebnis der Anfrage ausdrückt. Die erste Ziffer bestimmt die Klasse: 2xx Erfolg, 3xx Umleitung an eine andere Adresse, 4xx Fehler in der Anfrage des Clients, 5xx Problem auf dem Server. Der Rumpf der Nummer unterscheidet dann innerhalb der Klasse.
Typisches Beispiel: Eine Anfrage liefert 404 Not Found, also Klasse 4xx. Dann zuerst die eigene Anfrage prüfen: URL, mitgesendete Daten, Anmeldung. Liefert sie stattdessen 500, liegt der unerwartete Serverfehler auf der Gegenseite; die Anfrage kann oft später unverändert erneut gesendet werden.
Das Bild hat eine Grenze: Der Stempel der Post nennt meist die genaue Ursache, ein Statuscode nur die Richtung. Zwei 4xx-Antworten können völlig verschiedene Probleme bedeuten. Die Nummer ist ein Wegweiser, keine Diagnose.
4xx heißt nicht „Server kaputt“, sondern „Anfrage prüfen“ – 5xx zeigt auf die Gegenseite.
📌 Erste Ziffer · 4xx Client · 5xx Server
📚 Webentwicklung von Grund auf · Tag 2 von 30
#HTTP #webdev #api #NodeJS
Stellen Sie sich die Poststelle einer Behörde vor. Der Sachbearbeiter prüft den Antrag und stempelt ihn: grüner Stempel bedeutet erledigt, ein gelber bedeutet „woanders vorstellig werden“, ein roter mit Ihrer Nummer bedeutet Fehler im Antrag, ein roter mit seiner Nummer bedeutet Störung im Amt. Wer den Stempel sieht, weiß sofort, wo die Suche beginnt. Die Nummer auf dem Stempel nennt das genaue Büro. Der Farbcode aber nennt die Richtung.
So arbeitet HTTP, das Protokoll (Regelwerk) des Webs. Jede Serverantwort beginnt mit einem Statuscode, einer dreistelligen Nummer, die das Ergebnis der Anfrage ausdrückt. Die erste Ziffer bestimmt die Klasse: 2xx Erfolg, 3xx Umleitung an eine andere Adresse, 4xx Fehler in der Anfrage des Clients, 5xx Problem auf dem Server. Der Rumpf der Nummer unterscheidet dann innerhalb der Klasse.
Typisches Beispiel: Eine Anfrage liefert 404 Not Found, also Klasse 4xx. Dann zuerst die eigene Anfrage prüfen: URL, mitgesendete Daten, Anmeldung. Liefert sie stattdessen 500, liegt der unerwartete Serverfehler auf der Gegenseite; die Anfrage kann oft später unverändert erneut gesendet werden.
Das Bild hat eine Grenze: Der Stempel der Post nennt meist die genaue Ursache, ein Statuscode nur die Richtung. Zwei 4xx-Antworten können völlig verschiedene Probleme bedeuten. Die Nummer ist ein Wegweiser, keine Diagnose.
4xx heißt nicht „Server kaputt“, sondern „Anfrage prüfen“ – 5xx zeigt auf die Gegenseite.
📌 Erste Ziffer · 4xx Client · 5xx Server
📚 Webentwicklung von Grund auf · Tag 2 von 30
#HTTP #webdev #api #NodeJS
4 Tage vor
Die meisten Einsteiger denken, eine Webseite sei ein einziger Ort. Dabei läuft sie an zwei Orten: im Browser und auf dem Server.
Wer nicht weiß, welcher Baustein wo läuft, baut Prüfregeln an den falschen Ort. Und der falsche Ort ist der, den jeder Besucher verändern kann.
🌐 Frontend und Backend sind keine Ordner, sondern Lauforte. Das Frontend ist der Teil, der im Browser läuft: HTML beschreibt die Struktur, CSS das Aussehen, JavaScript das Verhalten auf der Seite. Das Backend läuft auf dem Server, speichert Daten und stellt Schnittstellen bereit. Dieselbe Sprache JavaScript kann an beiden Orten laufen: im Browser oder mit Node.js auf dem Server.
🧩 Der Browser spricht mit dem Backend über HTTP, das Anfrage-Antwort-Protokoll des Webs. Eine Schnittstelle (API) liefert etwa mit GET /artikel/42 einen Datensatz, oft als JSON, einem einfachen Textformat für Daten. Der Server kann dieselbe Adresse unterschiedlich beantworten: dem Browser eine HTML-Seite, einem Programm JSON-Daten. Er weiß dabei nie, was gerade angezeigt wird; jede Anfrage muss alles enthalten, was er zum Prüfen braucht.
🔒 Sensible Daten und alle Prüfregeln gehören immer ins Backend. Der JavaScript-Code im Browser ist sichtbar und veränderbar. Ein Kontaktformular prüft dort per JavaScript, ob das E-Mail-Feld ausgefüllt ist, und markiert den Fehler sofort. Das Backend prüft dieselbe Eingabe trotzdem erneut, weil die Frontend-Prüfung mit den Entwicklerwerkzeugen abgeschaltet sein kann.
Frontend heißt nicht „der sichere Teil der Anwendung“, sondern der Teil auf dem Gerät des Besuchers. Deshalb gilt: Ob eine Eingabe gilt, prüft der Server, nicht der Browser.
📌 Frontend · Backend · Serverprüfung
📚 Webentwicklung von Grund auf · Tag 2 von 30
#frontend #backend #webdev
Wer nicht weiß, welcher Baustein wo läuft, baut Prüfregeln an den falschen Ort. Und der falsche Ort ist der, den jeder Besucher verändern kann.
🌐 Frontend und Backend sind keine Ordner, sondern Lauforte. Das Frontend ist der Teil, der im Browser läuft: HTML beschreibt die Struktur, CSS das Aussehen, JavaScript das Verhalten auf der Seite. Das Backend läuft auf dem Server, speichert Daten und stellt Schnittstellen bereit. Dieselbe Sprache JavaScript kann an beiden Orten laufen: im Browser oder mit Node.js auf dem Server.
🧩 Der Browser spricht mit dem Backend über HTTP, das Anfrage-Antwort-Protokoll des Webs. Eine Schnittstelle (API) liefert etwa mit GET /artikel/42 einen Datensatz, oft als JSON, einem einfachen Textformat für Daten. Der Server kann dieselbe Adresse unterschiedlich beantworten: dem Browser eine HTML-Seite, einem Programm JSON-Daten. Er weiß dabei nie, was gerade angezeigt wird; jede Anfrage muss alles enthalten, was er zum Prüfen braucht.
🔒 Sensible Daten und alle Prüfregeln gehören immer ins Backend. Der JavaScript-Code im Browser ist sichtbar und veränderbar. Ein Kontaktformular prüft dort per JavaScript, ob das E-Mail-Feld ausgefüllt ist, und markiert den Fehler sofort. Das Backend prüft dieselbe Eingabe trotzdem erneut, weil die Frontend-Prüfung mit den Entwicklerwerkzeugen abgeschaltet sein kann.
Frontend heißt nicht „der sichere Teil der Anwendung“, sondern der Teil auf dem Gerät des Besuchers. Deshalb gilt: Ob eine Eingabe gilt, prüft der Server, nicht der Browser.
📌 Frontend · Backend · Serverprüfung
📚 Webentwicklung von Grund auf · Tag 2 von 30
#frontend #backend #webdev
5 Tage vor
„Ein Server im Internet“ – für viele reicht das als Cloud. Genau dieser Irrtum führt zu Rechnungen für Maschinen, die niemand nutzt.
Wer eine Anwendung erstmals ins Internet stellt, mietet oft einen dedizierten Server, also einen fest zugewiesenen physischen Rechner. Der Vertrag läuft monatlich, ob die Maschine arbeitet oder leer läuft.
Hinter dem Symptom stehen die fünf Merkmale der Cloud, wie sie das US-Institut NIST in SP 800-145 definiert. Cloud Computing ist demnach bedarfsgerechter Netzzugriff auf einen gemeinsamen Pool konfigurierbarer Rechenressourcen, schnell bereitgestellt und wieder freigegeben. Fehlt eines der Merkmale, liegt Servermiete oder Hosting vor, keine echte Cloud.
Selbstbedienung heißt: Ressourcen über eine Weboberfläche oder Programmierschnittstelle (API) bestellen, ohne Vertrieb. Breiter Netzzugriff: erreichbar über Standardprotokolle wie HTTPS, nicht nur von einer festen Leitung. Pooling: viele Kunden teilen sich dieselben physischen Rechner und Speicher, getrennt nur durch Virtualisierung, also durch Software statt eigener Hardware. Elastizität: bei Lastanstieg starten zusätzliche Maschinen, bei Ruhe verschwinden sie. Gemessener Dienst: Nutzung wird automatisch erfasst und ausgewiesen.
Um drei Uhr nachts wird in der Konsole mit wenigen Klicks eine virtuelle Maschine gestartet und nach einer Stunde wieder gelöscht. Bezahlt wird genau diese eine Stunde Laufzeit. Der dedizierte Server wird stattdessen monatlich abgerechnet, ob er läuft oder nicht.
So prüft man es: Ein Angebot an den fünf Merkmalen messen und nachfragen, was bei einer nicht mehr gebrauchten Ressource passiert. Echt ist die Cloud erst, wenn Freigeben sofort und ohne Restkosten möglich ist.
Cloud ist nicht Server im Internet, sondern ein Pool, aus dem man sich bedient und zurückgibt.
📌 NIST SP 800-145 · fünf Merkmale · nutzungsbasierte Abrechnung
📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops
Wer eine Anwendung erstmals ins Internet stellt, mietet oft einen dedizierten Server, also einen fest zugewiesenen physischen Rechner. Der Vertrag läuft monatlich, ob die Maschine arbeitet oder leer läuft.
Hinter dem Symptom stehen die fünf Merkmale der Cloud, wie sie das US-Institut NIST in SP 800-145 definiert. Cloud Computing ist demnach bedarfsgerechter Netzzugriff auf einen gemeinsamen Pool konfigurierbarer Rechenressourcen, schnell bereitgestellt und wieder freigegeben. Fehlt eines der Merkmale, liegt Servermiete oder Hosting vor, keine echte Cloud.
Selbstbedienung heißt: Ressourcen über eine Weboberfläche oder Programmierschnittstelle (API) bestellen, ohne Vertrieb. Breiter Netzzugriff: erreichbar über Standardprotokolle wie HTTPS, nicht nur von einer festen Leitung. Pooling: viele Kunden teilen sich dieselben physischen Rechner und Speicher, getrennt nur durch Virtualisierung, also durch Software statt eigener Hardware. Elastizität: bei Lastanstieg starten zusätzliche Maschinen, bei Ruhe verschwinden sie. Gemessener Dienst: Nutzung wird automatisch erfasst und ausgewiesen.
Um drei Uhr nachts wird in der Konsole mit wenigen Klicks eine virtuelle Maschine gestartet und nach einer Stunde wieder gelöscht. Bezahlt wird genau diese eine Stunde Laufzeit. Der dedizierte Server wird stattdessen monatlich abgerechnet, ob er läuft oder nicht.
So prüft man es: Ein Angebot an den fünf Merkmalen messen und nachfragen, was bei einer nicht mehr gebrauchten Ressource passiert. Echt ist die Cloud erst, wenn Freigeben sofort und ohne Restkosten möglich ist.
Cloud ist nicht Server im Internet, sondern ein Pool, aus dem man sich bedient und zurückgibt.
📌 NIST SP 800-145 · fünf Merkmale · nutzungsbasierte Abrechnung
📚 Cloud von Grund auf · Tag 1 von 30
#CloudHosting #devops
5 Tage vor
Viele halten den Pfad einer URL für einen Ordner auf dem Server. Dabei ist er nur ein Bezeichner, den der Server frei interpretiert.
Einsteiger denken so, weil Adressen wie /artikel/42 wie Dateipfade aussehen. Das klingt plausibel, schließlich arbeitet man im Betriebssystem tagtäglich mit Ordnern.
Tatsächlich besteht eine URL aus mehreren Teilen: Schema, Host, optionalem Port, Pfad, optionaler Query und optionalem Fragment. Das Schema etwa https sagt dem Client, also dem Browser, welches Protokoll er für die Verbindung nutzt. Der Host nennt den Server, und der Pfad benennt die Ressource, die angefragt wird. Der Server vergleicht den Pfad mit seinen hinterlegten Routen und antwortet mit 404, wenn keine passt.
Der Irrtum entsteht, weil URLs oft so aussehen wie Dateipfade. Server dürfen den Pfad aber beliebig deuten; eine Ordnung dahinter ist reine Konvention.
Nehmen wir eine Adresse mit dem Pfad /artikel/42 und der Query ?sort=neu&page=2. Der Browser baut daraus die Anfrage an den Server des Hosts, über HTTPS verschlüsselt. Der Pfad wählt die Ressource, die Query-Parameter als Name-Wert-Paare liefern zusätzliche Angaben wie Filter oder Sortierung. Passt keine Route, antwortet der Server mit 404 statt 200.
Woran man es erkennt: Der Server antwortet auf jeden Pfad nach eigenen Regeln, nicht nach Dateisystem-Lookup. Ein Fragment nach der Raute wird gar nicht erst mitgesendet, weil es eine Stelle innerhalb der Seite bezeichnet.
Der Pfad heißt nicht Ordnerstruktur auf dem Server, sondern ein Bezeichner für die Ressource, deren Deutung beim Server liegt.
📌 Schema · Host · Pfad · Query-Parameter
📚 Webentwicklung von Grund auf · Tag 1 von 30
#webdev #HTTP #backend
Einsteiger denken so, weil Adressen wie /artikel/42 wie Dateipfade aussehen. Das klingt plausibel, schließlich arbeitet man im Betriebssystem tagtäglich mit Ordnern.
Tatsächlich besteht eine URL aus mehreren Teilen: Schema, Host, optionalem Port, Pfad, optionaler Query und optionalem Fragment. Das Schema etwa https sagt dem Client, also dem Browser, welches Protokoll er für die Verbindung nutzt. Der Host nennt den Server, und der Pfad benennt die Ressource, die angefragt wird. Der Server vergleicht den Pfad mit seinen hinterlegten Routen und antwortet mit 404, wenn keine passt.
Der Irrtum entsteht, weil URLs oft so aussehen wie Dateipfade. Server dürfen den Pfad aber beliebig deuten; eine Ordnung dahinter ist reine Konvention.
Nehmen wir eine Adresse mit dem Pfad /artikel/42 und der Query ?sort=neu&page=2. Der Browser baut daraus die Anfrage an den Server des Hosts, über HTTPS verschlüsselt. Der Pfad wählt die Ressource, die Query-Parameter als Name-Wert-Paare liefern zusätzliche Angaben wie Filter oder Sortierung. Passt keine Route, antwortet der Server mit 404 statt 200.
Woran man es erkennt: Der Server antwortet auf jeden Pfad nach eigenen Regeln, nicht nach Dateisystem-Lookup. Ein Fragment nach der Raute wird gar nicht erst mitgesendet, weil es eine Stelle innerhalb der Seite bezeichnet.
Der Pfad heißt nicht Ordnerstruktur auf dem Server, sondern ein Bezeichner für die Ressource, deren Deutung beim Server liegt.
📌 Schema · Host · Pfad · Query-Parameter
📚 Webentwicklung von Grund auf · Tag 1 von 30
#webdev #HTTP #backend
10 Tage vor
Die meisten KI-Assistenten fragen um Vertrauen. Unserer fragt um Erlaubnis.
Neue Version von sepp mini dem KI-Assistenten, der in einer einzigen Datei steckt. 19 MB. Kein Konto, kein Cloud-Zwang, keine node_modules. Kopieren, ausführbar machen, starten. Auf Linux, macOS, Windows, Embedded oder vom USB-Stick, ohne Admin-Rechte.
🛡 Sepp Guard - erlaubt ist nur, was freigegeben wurde. Der Assistent sieht das laufende Projekt, sonst nichts vom Rechner. Kein Internet, kein Zugriff auf sensible Daten ohne Erlaubnis. Und entscheidend: Die Grenze zieht das Betriebssystem, nicht das Programm. Eine Zusage im Prompt ist keine Sicherheitsarchitektur.
📋 Audit Nachweis - jeder Schritt bleibt nachlesbar. Wer wann was getan hat. Und was abgelehnt wurde. Auch das Erlaubte steht in der Spur, Teilaufgaben eingerückt unter ihrem Auftrag, maschinell auswertbar. Kein Gedächtnisprotokoll, sondern eine prüfbare Aufzeichnung verwertbar für Revision, ISO-Audit und Datenschutzprüfung.
🔑 Ihr Modell, Ihre Entscheidung. Großer Anbieter, eigener Server im Firmennetz oder lokal am Arbeitsplatz. Umgestellt wird mit einer Angabe beim Start. Vertrauliches bleibt drin, Aufwendiges darf raus. Kein Anbieter bindet Sie.
Souveränität heißt nicht, auf KI zu verzichten. Sie heißt, die Bedingungen selbst zu setzen.
Eine Binary. Eine Haltung. Souveränität. Entwickelt und gebaut in Deutschland.
👉 https://sepp.kionova.de/
🦀 Rust · 🔒 Sandboxed · 🌐 Made in Germany
Welcher Prozess bei Ihnen läuft heute noch von Hand?
#ki #Souveränität #MadeInGermany #compliance #Rust #DigitaleSouveränität
Neue Version von sepp mini dem KI-Assistenten, der in einer einzigen Datei steckt. 19 MB. Kein Konto, kein Cloud-Zwang, keine node_modules. Kopieren, ausführbar machen, starten. Auf Linux, macOS, Windows, Embedded oder vom USB-Stick, ohne Admin-Rechte.
🛡 Sepp Guard - erlaubt ist nur, was freigegeben wurde. Der Assistent sieht das laufende Projekt, sonst nichts vom Rechner. Kein Internet, kein Zugriff auf sensible Daten ohne Erlaubnis. Und entscheidend: Die Grenze zieht das Betriebssystem, nicht das Programm. Eine Zusage im Prompt ist keine Sicherheitsarchitektur.
📋 Audit Nachweis - jeder Schritt bleibt nachlesbar. Wer wann was getan hat. Und was abgelehnt wurde. Auch das Erlaubte steht in der Spur, Teilaufgaben eingerückt unter ihrem Auftrag, maschinell auswertbar. Kein Gedächtnisprotokoll, sondern eine prüfbare Aufzeichnung verwertbar für Revision, ISO-Audit und Datenschutzprüfung.
🔑 Ihr Modell, Ihre Entscheidung. Großer Anbieter, eigener Server im Firmennetz oder lokal am Arbeitsplatz. Umgestellt wird mit einer Angabe beim Start. Vertrauliches bleibt drin, Aufwendiges darf raus. Kein Anbieter bindet Sie.
Souveränität heißt nicht, auf KI zu verzichten. Sie heißt, die Bedingungen selbst zu setzen.
Eine Binary. Eine Haltung. Souveränität. Entwickelt und gebaut in Deutschland.
👉 https://sepp.kionova.de/
🦀 Rust · 🔒 Sandboxed · 🌐 Made in Germany
Welcher Prozess bei Ihnen läuft heute noch von Hand?
#ki #Souveränität #MadeInGermany #compliance #Rust #DigitaleSouveränität
sepp mini — KI-Assistent in einer Datei. Souverän. Made in Germany | KIONOVA®
KI-Assistent in einer Datei: läuft in Ihrem Netz, darf nur, was Sie freigeben, protokolliert jeden Schritt. Ohne Cloud-Zwang, ohne Konto. Made in Germany.
https://sepp.kionova.de/
8 Monate vor
14
Menschen haben abgestimmt
8 Monate vor
Industrielle Temperaturüberwachung für eine Bäckerei: 50 PT100-Sensoren an RS485-Bus, Messwerte in Echtzeit auf Shopfloor-Displays. Alarm bei Abweichung, Protokollierung für HACCP-Konformität. Das System hat letzte Woche einen defekten Kühlschrank erkannt bevor die Ware verdarb - geschätzter Warenwert: 3.000 EUR. ROI des gesamten Systems nach 2 Monaten erreicht. #industrie40 #sensorik #haccp
8 Monate vor
Meeting-Audit: 2 Wochen lang jedes Meeting protokolliert - Teilnehmer, Dauer, Output. Ergebnis: 40% aller Meetings konnten durch asynchrone Loom-Videos oder Slack-Threads ersetzt werden. Die restlichen 60% wurden um durchschnittlich 15 Minuten gekürzt durch klare Agenden und Timer.
Freigewordene Zeit pro Woche: 12 Stunden für das gesamte Team. Die Zufriedenheit im nächsten Pulse-Survey ist um 23 Punkte gestiegen. Weniger Meetings heißt nicht weniger Kommunikation - sondern bessere. #meetings #produktivitaet #async
Freigewordene Zeit pro Woche: 12 Stunden für das gesamte Team. Die Zufriedenheit im nächsten Pulse-Survey ist um 23 Punkte gestiegen. Weniger Meetings heißt nicht weniger Kommunikation - sondern bessere. #meetings #produktivitaet #async
