Eksternalizacja klucza kodowania tablicy bajtkodu

Co robią te opcje

vmBytecodeArrayEncoding szyfruje tablicę bajtkodu VM, dzięki czemu nie znajduje się ona w kodzie wynikowym jako zwykły tekst. Domyślnie klucz szyfrowania jest wyprowadzany ze środowiska i rekonstruowany po stronie klienta, więc nigdy nie masz z nim do czynienia. Jest to wygodne, ale materiał klucza wciąż znajduje się w bundlu.

Dwie opcje pozwalają wyjąć klucz z bundla i kontrolować go samodzielnie:

• vmBytecodeArrayEncodingKey - klucz, który podajesz w czasie kompilacji. Gdy jest ustawiony, jest używany zamiast domyślnego klucza wyprowadzanego ze środowiska i nie jest osadzany w zaciemnionym kodzie wynikowym.
• vmBytecodeArrayEncodingKeyGetter - wyrażenie JavaScript, które zwraca ten sam klucz w czasie działania. Jest osadzane dosłownie i wykonywane w przeglądarce, gdy ładowany jest zaciemniony kod.

Chodzi o rozdzielenie: ponieważ klucz nie znajduje się w kodzie, czysto statyczne skanowanie bundla nie jest w stanie go odzyskać. Klucz musi jednak być obecny w czasie działania, aby kod mógł się wykonać, więc nie jest naprawdę tajny - ale to Ty decydujesz, skąd pochodzi i kto może go zobaczyć.

Te dwie opcje stanowią parę. vmBytecodeArrayEncodingKey bez gettera pozostawia zaciemniony kod bez żadnego sposobu na uzyskanie klucza w czasie działania, a getter bez odpowiadającego mu klucza z czasu kompilacji nie ma z czym się zgadzać. Ustaw obie, razem z vmBytecodeArrayEncoding: true.

Jak łączą się oba klucze

Twój klucz nigdy nie jest używany samodzielnie - po obu stronach jest mieszany z wewnętrznym kluczem kontrolowanym przez obfuskator:

• Czas kompilacji. vmBytecodeArrayEncodingKey jest łączony z wewnętrznym kluczem wyprowadzanym przez obfuskator, a tablica bajtkodu jest kodowana wynikowym kluczem mieszanym.
• Czas działania. Wartość, do której rozwiązuje się Twój vmBytecodeArrayEncodingKeyGetter, jest łączona z tym samym wewnętrznym kluczem, rekonstruowanym po stronie klienta na podstawie różnych czynników czasu działania, aby zdekodować bajtkod.

Ponieważ obie strony mieszają Twój klucz z kluczem wewnętrznym, getter musi rozwiązywać się do dokładnie tego samego ciągu znaków, który przekazałeś jako vmBytecodeArrayEncodingKey. Żaden z tych elementów nie wystarcza sam z siebie: Twój klucz bez klucza wewnętrznego nie zdekoduje bajtkodu, a klucz wewnętrzny jest bezużyteczny bez Twojego - dlatego to kontrola nad tym, kto otrzymuje Twój klucz, faktycznie chroni kod.

Dostarczanie klucza w czasie działania

Domyślnie getter jest synchroniczny: wyrażenie musi zwrócić klucz natychmiast, gdy ładowany jest zaciemniony kod. Odczytaj go z dowolnego źródła, które jest już obecne po stronie klienta - z ciasteczka, localStorage, zmiennej globalnej lub elementu DOM wstrzykniętego przez serwer.

Klucz musi istnieć zanim uruchomi się zaciemniony kod:

Inne synchroniczne źródła działają tak samo - wybierz to, które Twoja aplikacja już wypełnia:

Trzymaj klucz poza tym samym plikiem lub skryptem co zaciemniony kod. Umieszczenie go tam bezpośrednio niweczy cały sens - statyczne skanowanie bundla odzyskałoby zarówno kod, jak i jego klucz. Przechowuj go w osobnym źródle, a klucz z czasu kompilacji vmBytecodeArrayEncodingKey wstrzykuj ze zmiennej środowiskowej lub sekretu, zamiast umieszczać go w repozytorium.

Pobieranie klucza z Twojego backendu (asynchronicznie)

Wymaga vmAsyncExecutor · v7.3.0+

Synchroniczny getter może odczytać tylko to, co już znajduje się po stronie klienta. Aby pobrać klucz z Twojego serwera - tak abyś mógł ograniczyć do niego dostęp za pomocą uwierzytelniania i go unieważnić - getter musi być asynchroniczny, a to wymaga vmAsyncExecutor. Po włączeniu asynchronicznego executora getter może zwrócić Promise, a VM czeka na niego przed uruchomieniem.

Getter zwracający Promise wymaga vmAsyncExecutor. Nie można tego sprawdzić w czasie budowania, więc getter zwracający Promise przy wyłączonym vmAsyncExecutor zawodzi w czasie działania - dekoder otrzymuje obiekt Promise zamiast ciągu znaków klucza.

Autoryzuj wydanie klucza zweryfikowaną sesją i wymaganymi kontrolami licencji. Sam Origin lub Referer nie uwierzytelnia klienta; żądanie GET same-origin może nie zawierać Origin. Wyłącz cache. Powiąż klucze z wersją buildu i wdrażaj je razem z pakietami. Klient otrzymujący klucz może badać go podczas działania.

Gdy klucz nie pasuje

Zaciemniony kod działa tylko wtedy, gdy getter zwraca dokładnie ten sam klucz, który został użyty podczas zaciemniania. Jeśli klucze się różnią - lub getter zwraca undefined, null albo pusty ciąg znaków - deszyfrowanie wytwarza błędny strumień klucza, a kod zawodzi w czasie działania, dając bezsensowny wynik lub zwykły błąd czasu wykonania.

Celowo nie ma osobnego, specyficznego dla klucza komunikatu o błędzie: nieudany klucz jest nie do odróżnienia od jakiejkolwiek innej awarii w czasie działania. Dlatego gdy chroniony przez VM bundle zgłasza błąd dopiero wtedy, gdy ta opcja jest w użyciu, sprawdź najpierw ścieżkę klucza - czy getter rozwiązuje się na stronie, zwraca niepusty ciąg znaków i zwraca tę samą wartość, z którą zbudowałeś kod.