Tests und CI
Verwenden Sie für Funktionstests eine separate Konfiguration, wenn Ihre Testwerkzeuge erweiterte Abwehrmaßnahmen auslösen würden. Es gibt keinen separaten Test-Endpunkt und keine eigene Dashboard-Umgebung.
Warum Tests einen eigenen Build brauchen
Erweiterte Abwehrmaßnahmen (VM Self Defending, VM Debug Protection, VM Domain Lock und ihre Basis-Gegenstücke selfDefending, debugProtection und domainLock) wirken auch gegen Ihre eigenen Agenten, Automatisierungen und Debugger. Sie können die Ausführung stoppen, scheinbar unzusammenhängende Fehler werfen oder falsche Ergebnisse liefern. disableConsoleOutput ersetzt die console-Methoden global durch leere Funktionen, und zwar für jedes Skript auf der Seite, nicht nur für das obfuskierte, sodass Assertions auf Basis von Logs nichts sehen. Führen Sie Funktionstests mit einem separaten Test-Build aus, in dem diese Funktionen ausgeschaltet sind.
Konfiguration für Funktionstests
Leiten Sie die Testkonfiguration aus Ihren gemeinsamen Einstellungen ab und wenden Sie diese Überschreibungen nach der Auswahl einer Voreinstellung an. Sie deaktivieren die VM- und die Basisvarianten von Self Defending, Debug Protection und Domain Lock und schalten disableConsoleOutput aus (die Voreinstellungen Low, Medium und High aktivieren es). Übergeben Sie explizite Werte; wird eine Option weggelassen, kann eine Voreinstellung sie aktivieren.
CI
Führen Sie zuerst den Originalcode aus und lassen Sie anschließend den obfuskierten Test-Build dieselben Prüfungen durchlaufen. Protokollieren Sie Eingabe, wirksame Optionen, Obfuscator-Version und Build-Warnungen, damit sich Fehler reproduzieren lassen. Das Dashboard und direkte API-Antworten melden Warnungen und die aufgelöste Version; das Paket javascript-obfuscator meldet die Version in seiner Fortschrittsmeldung, aber keine Warnungen.
Sobald die Funktionsprüfungen bestanden sind, erzeugen Sie aus den ursprünglichen Produktionseinstellungen ein separates Release-Artefakt. Validieren Sie genau dieses Artefakt in seiner vorgesehenen Laufzeitumgebung, auf einer zugelassenen Domain und ohne Automatisierung oder Debugger, die seine Abwehrmaßnahmen erkennen sollen. Ein bestandener Test-Build validiert das geschützte Release nicht.
Builds über das Dashboard, das Paket javascript-obfuscator (CLI oder Node.js) und die API verwenden dieselben Schutzoptionen. Tests über die API nutzen die üblichen Zugangsdaten und denselben Endpunkt, und es gelten die normalen Nutzungslimits. Legen Sie in CI Test- und Release-Ausgaben in getrennten Pfaden ab und deployen Sie ausschließlich das Release-Artefakt.
Schlägt die Ausführung weiterhin fehl, siehe VM-Laufzeitfehler diagnostizieren.