OSTRELLE · LERNEN · MIT ÜBUNGEN

4. APIgrenzen und Abnahme verstehen

Du prüfst Berechtigungsgrenzen und belegst sichtbares Verhalten mit passenden Werkzeugen. Mit konkreten Schritten, eigener Übung, Musterlösung und Erfolgskontrolle.

Ostrelle für Entwickler · Lektion 4 von 4 · Quellstand 3. November 2026

Das lernst du

Du prüfst Berechtigungsgrenzen und belegst sichtbares Verhalten mit passenden Werkzeugen.

Die Verwaltungs-API ist eine geschützte Cookie-/Origin-/CSRF-Schnittstelle. Eine erfolgreiche Authchallenge ist keine angemeldete Sitzung. Schreibende Inhaltsanfragen benötigen die aktuelle Version über If-Match. Bei 428 oder Konflikt wird die Grundlage korrigiert, nicht die Schutzprüfung entfernt.

Ein grüner Test sagt nur etwas über seinen tatsächlichen Scope aus. Ein Fixture mit kontrollierter API ist kein Produktionsnachweis; ein lokaler Renderlauf ist kein öffentlicher HTTPSnachweis. Zu einer sichtbaren Änderung gehören echte Browserbilder, Tastaturprüfung und die angebotenen Linkwege.

Schritt für Schritt

Rufe GET /api/v1/me ohne Sitzung an deiner isolierten Instanz ab. Bei aktivierter Verwaltung muss die geschützte Ressource unautorisiert bleiben; bei bewusst deaktivierter API kann sie 404 liefern.
Für berechtigte APIarbeit verwende ausschließlich die eigene Testsession. Übernimm aktuelle Origin-, CSRF- und Versionswerte aus dem vorgesehenen Vertrag; schreibe keine Cookie- oder TOTPwerte in ein Beispiel.
Führe tools/product-check/check.mjs gegen deinen tatsächlich gestarteten Produktserver aus. Die vorhandenen Node-/Chromium-/axevoraussetzungen stehen in dessen README.
Prüfe deine neue Seite zusätzlich auf Desktop und Mobil und bei ausgeschaltetem JavaScript. Öffne die native Navigation und die Lösungsdetails mit Tastatur.
Kontrolliere ausgelieferte Ressourcen: keine Editor-/Kollaborationsbibliothek auf Informationsseiten, keine ungewollten Fremdressourcen und korrekt gehashte kritische Styles.
Dokumentiere Commit, geprüfte URLs, Scope und konkrete Fehler. Führe die vereinbarte unabhängige Prüfung durch, bevor ein Hostdeploy erwogen wird.

PRODUCT_URL=http://ostrelle.localhost:18580 \
OUTPUT_DIR=/tmp/ostrelle-produktkurs-browser \
  node tools/product-check/check.mjs
# Das Werkzeug braucht den aktuellen importierten Manifeststand,
# Chromium und die installierte axe-core-Testabhängigkeit.

Deine Übung

Ein Test gibt 200 auf / und ein anderes Skript findet deinen Satz im JSON. Genügt das als Abnahme deiner neuen Seite? Ergänze die fehlenden Prüfungen.

Musterlösung und Erklärung

Nein. Du brauchst den echten Abruf von /lernprobe/ auf deiner importierten Runtime, korrekte Metadaten und Linkziele, eine echte 404-Gegenprobe sowie lesbare Desktop-/Mobil-/NoJSausgabe. Axe und Tastatur ergänzen sich; kein Werkzeug allein beweist vollständige Zugänglichkeit.

Der Bericht bezeichnet diese Ergebnisse ausdrücklich als lokalen Source-/SSRnachweis. Ein Deployment, eine öffentliche Releasefreigabe oder ein Kunde wurden dadurch nicht geprüft. Ein roter Test wird nicht gelöscht, um den Abschluss grün zu färben.

So prüfst du dein Ergebnis

Anonyme APIzugriffe überschreiten keine Rechte.
Die vollständige tatsächliche Produktoberfläche wurde geprüft.
Der Abschluss nennt den gemessenen Scope und hält Zugangsdaten privat.