Opcja browserEnvironment deklaruje fakty o środowisku, w którym serwowana jest produkcyjna kompilacja, dzięki czemu chroniony kod może się z nimi związać lub na nie reagować. To niewielki obiekt, a każde pole działa wyłącznie razem z jedną konkretną ochroną — sama z siebie opcja nic nie robi:

browserEnvironment: { transport: 'https', hosting: 'remote' }

transport

Schemat, przez który produkcja serwuje bundle — 'http' lub 'https'. Działa razem z vmSelfDefending.

Przy 'https' kopia, którą inżynier wsteczny serwuje przez zwykłe HTTP, nie zadziała poprawnie. 'http' lub nieustawione pole nie dodaje takiej ochrony.

hosting

Skąd serwowany jest produkcyjny bundle — 'remote' lub 'local'. Działa razem z vmDebugProtection i wyłącznie dla targetów browser oraz browser-no-eval. Wymaga obfuskatora w wersji 7.14.0 lub nowszej.

Przy 'remote' kopia, którą inżynier wsteczny wyciągnie i uruchomi we własnym lokalnym środowisku, jest traktowana jako niezgodność środowiska uruchomieniowego, a zabezpieczenia przed automatyzacją reagują zgodnie z konfiguracją vmDefenseReaction. 'local' lub nieustawione pole nie dodaje takiej ochrony.

Obsługiwane targety

browserEnvironment dotyczy wyłącznie targetów browser, browser-no-eval i service-worker. Dla node, userscript i bytenode opcja jest odrzucana — obfuskacja kończy się błędem walidacji, zamiast po cichu porzucić ustawienie. hosting jest jeszcze węższe: na service workerze jest akceptowane, ale niczego tam nie wiąże.

Wymagania

• transport działa razem z vmSelfDefending, a hosting z vmDebugProtection; w przeciwnym razie żadne z nich nic nie robi.
• Target browser, browser-no-eval lub service-worker (browser lub browser-no-eval dla hosting).
• Obfuskator w wersji 7.9.0 lub nowszej dla transport, 7.14.0 lub nowszej dla hosting.

Przykład

JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmSelfDefending: true,
    vmDebugProtection: true,
    target: 'browser',
    browserEnvironment: { transport: 'https', hosting: 'remote' }
});