2 Tage vor
Die Antwort der API kommt zurück, aber das Frontend zeigt nichts an. Der Grund ist oft ein einziges falsches Komma im JSON.
Das Symptom: Der Browser meldet einen Fehler beim Auslesen der Daten. Die Anfrage selbst war erfolgreich; nur der Text der Antwort lässt sich nicht in ein Objekt umwandeln.
Dahinter steckt JSON, das JavaScript Object Notation, ein reines Textformat und der verbreitete Standard für Daten von Web-APIs. JSON kennt Objekte mit Schlüssel-Wert-Paaren, Listen, Zeichenketten, Zahlen sowie true, false und null. Der Browser fragt etwa per GET /artikel/42 einen Datensatz an, und der Server antwortet im Body, dem Teil der Antwort mit den eigentlichen Nutzdaten. Ein Header wie Content-Type: application/json kündigt dabei das Format an.
Ein typischer Fehler: einfache statt doppelter Anführungszeichen oder ein Komma nach dem letzten Paar. Beides macht das JSON ungültig, und der Empfänger verweigert das Lesen. Korrekt verschachtelt kombiniert eine Antwort beides: ein Objekt mit Metadaten wie der Gesamtzahl 2 sowie eine Liste in eckigen Klammern mit zwei Artikeln, den Nummern 42 und 43 und den Titeln „Neu“ und „Alt“ – Objekte und Listen lassen sich beliebig ineinander verschachteln.
So prüft man es: Die Antwort in einen JSON-Validator kopieren, der ungültige Stellen markiert. In JavaScript prüft JSON.parse den Text und meldet die Stelle, an der etwas fehlt; JSON.stringify wandelt ein Objekt wieder in Text um.
Wer null sieht, sollte zudem wissen: Das heißt, ein Wert fehlt bewusst – anders als die Zahl 0 oder eine leere Zeichenkette, bei denen ein Wert vorhanden ist.
JSON heißt nicht „irgendein Textformat“, sondern Objekte, Listen und Werte in exakter Schreibweise – doppelte Anführungszeichen, kein Schlusskomma.
📌 JSON-Objekt · Listen · null statt 0
📚 Webentwicklung von Grund auf · Tag 3 von 30
#webdev #api #javascript #frontend
Das Symptom: Der Browser meldet einen Fehler beim Auslesen der Daten. Die Anfrage selbst war erfolgreich; nur der Text der Antwort lässt sich nicht in ein Objekt umwandeln.
Dahinter steckt JSON, das JavaScript Object Notation, ein reines Textformat und der verbreitete Standard für Daten von Web-APIs. JSON kennt Objekte mit Schlüssel-Wert-Paaren, Listen, Zeichenketten, Zahlen sowie true, false und null. Der Browser fragt etwa per GET /artikel/42 einen Datensatz an, und der Server antwortet im Body, dem Teil der Antwort mit den eigentlichen Nutzdaten. Ein Header wie Content-Type: application/json kündigt dabei das Format an.
Ein typischer Fehler: einfache statt doppelter Anführungszeichen oder ein Komma nach dem letzten Paar. Beides macht das JSON ungültig, und der Empfänger verweigert das Lesen. Korrekt verschachtelt kombiniert eine Antwort beides: ein Objekt mit Metadaten wie der Gesamtzahl 2 sowie eine Liste in eckigen Klammern mit zwei Artikeln, den Nummern 42 und 43 und den Titeln „Neu“ und „Alt“ – Objekte und Listen lassen sich beliebig ineinander verschachteln.
So prüft man es: Die Antwort in einen JSON-Validator kopieren, der ungültige Stellen markiert. In JavaScript prüft JSON.parse den Text und meldet die Stelle, an der etwas fehlt; JSON.stringify wandelt ein Objekt wieder in Text um.
Wer null sieht, sollte zudem wissen: Das heißt, ein Wert fehlt bewusst – anders als die Zahl 0 oder eine leere Zeichenkette, bei denen ein Wert vorhanden ist.
JSON heißt nicht „irgendein Textformat“, sondern Objekte, Listen und Werte in exakter Schreibweise – doppelte Anführungszeichen, kein Schlusskomma.
📌 JSON-Objekt · Listen · null statt 0
📚 Webentwicklung von Grund auf · Tag 3 von 30
#webdev #api #javascript #frontend
3 Tage vor
Der Schlüssel in der Konfigurationsdatei funktioniert monatelang, ohne dass jemand ihn prüft. Genau das ist das Problem.
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Viele vergeben Administratorrechte, weil es schnell geht. Dabei macht genau das einen Angriff zum Totalausfall.
Viele Einsteiger denken: Volle Rechte sparen Nachfragen und Fehlermeldungen. Wer alles darf, muss nie darauf warten, dass jemand ein fehlendes Recht nachreicht – das klingt vernünftig.
Tatsächlich gilt das Gegenteil. Das Prinzip der geringsten Rechte (Least Privilege) besagt: Jedes Benutzerkonto, jeder Dienst und jede Programmierschnittstelle (API, also eine definierte Stelle, über die Software Daten austauscht) erhält nur die Rechte, die seine Aufgabe erfordert. Wird ein Konto kompromittiert (also von Angreifern übernommen), kann der Angreifer nur das tun, was das Konto darf. Der Schaden bleibt auf diese Rechte begrenzt.
Der Irrtum entsteht, weil Bequemlichkeit sofort spürbar ist, der Schadensfall nicht. Einmal großzügig vergebene Rechte verschwinden außerdem selten von selbst.
Als Beispiel dient ein Skript, das jede Nacht eine Datensicherung kopieren soll. Es braucht nur Leserechte auf den Quellordner und Schreibrechte auf das Backup-Ziel. Die Administratorenrolle des ganzen Systems ist dafür nicht nötig – sie verwandelt einen kleinen Fehlgriff in eine Katastrophe.
Woran man es erkennt: Rechtevergabe ist kein einmaliger Vorgang, sondern wird regelmäßig geprüft. Jede Rolle muss sich durch eine konkrete, beschriebene Aufgabe begründen lassen; Rechte ohne Begründung werden weggenommen.
Least Privilege heißt nicht, Angriffe zu verhindern. Es heißt, die Schadenshöhe im Ernstfall zu begrenzen – und damit das Risiko zu senken, bevor etwas passiert.
📌 Zugriffsrechte · Rollen · Schadensbegrenzung
📚 Zukunftstechnologien verstehen · Tag 2 von 30
#zerotrust #Cybersicherheit #architektur
Viele Einsteiger denken: Volle Rechte sparen Nachfragen und Fehlermeldungen. Wer alles darf, muss nie darauf warten, dass jemand ein fehlendes Recht nachreicht – das klingt vernünftig.
Tatsächlich gilt das Gegenteil. Das Prinzip der geringsten Rechte (Least Privilege) besagt: Jedes Benutzerkonto, jeder Dienst und jede Programmierschnittstelle (API, also eine definierte Stelle, über die Software Daten austauscht) erhält nur die Rechte, die seine Aufgabe erfordert. Wird ein Konto kompromittiert (also von Angreifern übernommen), kann der Angreifer nur das tun, was das Konto darf. Der Schaden bleibt auf diese Rechte begrenzt.
Der Irrtum entsteht, weil Bequemlichkeit sofort spürbar ist, der Schadensfall nicht. Einmal großzügig vergebene Rechte verschwinden außerdem selten von selbst.
Als Beispiel dient ein Skript, das jede Nacht eine Datensicherung kopieren soll. Es braucht nur Leserechte auf den Quellordner und Schreibrechte auf das Backup-Ziel. Die Administratorenrolle des ganzen Systems ist dafür nicht nötig – sie verwandelt einen kleinen Fehlgriff in eine Katastrophe.
Woran man es erkennt: Rechtevergabe ist kein einmaliger Vorgang, sondern wird regelmäßig geprüft. Jede Rolle muss sich durch eine konkrete, beschriebene Aufgabe begründen lassen; Rechte ohne Begründung werden weggenommen.
Least Privilege heißt nicht, Angriffe zu verhindern. Es heißt, die Schadenshöhe im Ernstfall zu begrenzen – und damit das Risiko zu senken, bevor etwas passiert.
📌 Zugriffsrechte · Rollen · Schadensbegrenzung
📚 Zukunftstechnologien verstehen · Tag 2 von 30
#zerotrust #Cybersicherheit #architektur
4 Tage vor
Die meisten Teams halten Eigenbau für die günstigere Option. Dabei werden Wartung, Personal und Updates oft erst später sichtbar.
Make-or-Buy ist die Grundsatzentscheidung, ob eine Funktion im eigenen Haus entwickelt oder als fertige Lösung zugekauft wird. Sie begegnet einem überall: bei Login, Bezahlung, Suche oder E-Mail-Infrastruktur.
Zuerst wird jede Funktion danach bewertet, ob sie Kernkompetenz oder Standard ist. Eine Kernkompetenz ist eine Fähigkeit, die das eigene Angebot im Wettbewerb sichtbar von anderen unterscheidet. Eine Standardfunktion bieten viele Anbieter gleichartig an, und jeder Betrieb braucht sie ohnehin.
Dann werden für beide Wege die Gesamtkosten über die Laufzeit geschätzt (Total Cost of Ownership). Beim Eigenbau zählen nicht nur Entwicklung, sondern Dauerkosten: Jede selbst gebaute Funktion muss gepflegt, dokumentiert, aktualisiert und über Personalausfälle hinweg betrieben werden. Beim Zukauf kommen Betrieb, Lizenzen, Schulung, Integration und Migration hinzu.
Danach wird der Lock-in geprüft, also wie teuer und aufwendig ein späterer Ausstieg wäre. Entscheidend sind exportierbare Daten, offene Formate und Schnittstellen sowie alternative Anbieter. Ein typisches Beispiel: Ein Onlinehändler entwickelt seine Produktsuche selbst, weil sie den Umsatz unterscheidet, kauft aber Login, Bezahlung und E-Mail-Infrastruktur als Standarddienst ein.
Zuletzt wird die Entscheidung schriftlich dokumentiert und begründet. So bleibt später nachvollziehbar, welche Annahmen über Kosten, Nutzen und Risiko ihr zugrunde lagen.
Eigenbau heißt nicht sparsam, sondern eine zweite Produktlinie: gebaut, gepflegt und verantwortet. Gekauft wird alles, was den Unterschied im Wettbewerb nicht ausmacht.
📌 Kernkompetenz · Total Cost of Ownership · Lock-in
📚 Zukunftstechnologien verstehen · Tag 1 von 30
#strategie #architektur #TCO
Make-or-Buy ist die Grundsatzentscheidung, ob eine Funktion im eigenen Haus entwickelt oder als fertige Lösung zugekauft wird. Sie begegnet einem überall: bei Login, Bezahlung, Suche oder E-Mail-Infrastruktur.
Zuerst wird jede Funktion danach bewertet, ob sie Kernkompetenz oder Standard ist. Eine Kernkompetenz ist eine Fähigkeit, die das eigene Angebot im Wettbewerb sichtbar von anderen unterscheidet. Eine Standardfunktion bieten viele Anbieter gleichartig an, und jeder Betrieb braucht sie ohnehin.
Dann werden für beide Wege die Gesamtkosten über die Laufzeit geschätzt (Total Cost of Ownership). Beim Eigenbau zählen nicht nur Entwicklung, sondern Dauerkosten: Jede selbst gebaute Funktion muss gepflegt, dokumentiert, aktualisiert und über Personalausfälle hinweg betrieben werden. Beim Zukauf kommen Betrieb, Lizenzen, Schulung, Integration und Migration hinzu.
Danach wird der Lock-in geprüft, also wie teuer und aufwendig ein späterer Ausstieg wäre. Entscheidend sind exportierbare Daten, offene Formate und Schnittstellen sowie alternative Anbieter. Ein typisches Beispiel: Ein Onlinehändler entwickelt seine Produktsuche selbst, weil sie den Umsatz unterscheidet, kauft aber Login, Bezahlung und E-Mail-Infrastruktur als Standarddienst ein.
Zuletzt wird die Entscheidung schriftlich dokumentiert und begründet. So bleibt später nachvollziehbar, welche Annahmen über Kosten, Nutzen und Risiko ihr zugrunde lagen.
Eigenbau heißt nicht sparsam, sondern eine zweite Produktlinie: gebaut, gepflegt und verantwortet. Gekauft wird alles, was den Unterschied im Wettbewerb nicht ausmacht.
📌 Kernkompetenz · Total Cost of Ownership · Lock-in
📚 Zukunftstechnologien verstehen · Tag 1 von 30
#strategie #architektur #TCO
8 Monate vor
OTA-Updates für unsere ESP32-Flotte implementiert: 30 Geräte gleichzeitig updaten, ohne ein einziges USB-Kabel. Der ESP32 prüft beim Boot ob eine neue Firmware auf dem Server liegt, lädt sie im Hintergrund, validiert die Checksumme und bootet neu.
Wichtig: Rollback-Partition für den Fall dass ein Update fehlschlägt. Ein Gerät hat sich nach einem fehlerhaften Update automatisch zurückgesetzt. Ohne Rollback wäre es ein Briefbeschwerer geworden. Skalierbare IoT-Wartung braucht OTA von Tag 1. #ota #esp32 #iot #firmware
Wichtig: Rollback-Partition für den Fall dass ein Update fehlschlägt. Ein Gerät hat sich nach einem fehlerhaften Update automatisch zurückgesetzt. Ohne Rollback wäre es ein Briefbeschwerer geworden. Skalierbare IoT-Wartung braucht OTA von Tag 1. #ota #esp32 #iot #firmware
10 Monate vor
Maker Faire Vortrag über IoT-Sicherheit: 85% der IoT-Geräte im Publikum hatten keine Firmware-Verschlüsselung, 60% sendeten Credentials im Klartext. Meine Checkliste für sichere IoT-Devices: TLS für alle Verbindungen, Secure Boot mit signierter Firmware, verschlüsselte OTA-Updates, keine Default-Passwörter, automatische Certificate-Rotation. Sicherheit muss beim Sensor anfangen, nicht erst in der Cloud. #iotsecurity #makerfaire #security
10 Monate vor
Kubernetes 1.32 Gateway API jetzt in Produktion - endlich ein standardisierter Ingress-Ersatz. Auto-Skalierung bei Traffic-Spitzen funktioniert brillant - Black Friday mit 10x Traffic ohne Ausfallzeit überstanden. Aber die Komplexität ist real.
Was wir unterschätzt haben: Persistent Volumes und StatefulSets sind deutlich trickreicher als Stateless-Deployments. Unsere PostgreSQL-Migration auf K8s hat 3 Anläufe gebraucht. Lesson learned: Datenbanken gehören (noch) nicht in Kubernetes, es sei denn man hat dediziertes DB-Ops-Know-how.
Was sich gelohnt hat: GitOps-Workflow mit ArgoCD, automatische Rollbacks bei fehlgeschlagenen Health-Checks, und Resource-Quotas die verhindern dass ein Team den gesamten Cluster lahmlegt. #kubernetes #devops #cloudnative
Was wir unterschätzt haben: Persistent Volumes und StatefulSets sind deutlich trickreicher als Stateless-Deployments. Unsere PostgreSQL-Migration auf K8s hat 3 Anläufe gebraucht. Lesson learned: Datenbanken gehören (noch) nicht in Kubernetes, es sei denn man hat dediziertes DB-Ops-Know-how.
Was sich gelohnt hat: GitOps-Workflow mit ArgoCD, automatische Rollbacks bei fehlgeschlagenen Health-Checks, und Resource-Quotas die verhindern dass ein Team den gesamten Cluster lahmlegt. #kubernetes #devops #cloudnative
