zabezpieczanie kodu źródłowego w aplikacji desktop-webkit na komputery stacjonarne

Question

najpierw na pierwszym miejscu, widziałem nwsnapshot. a to nie pomaga.

Buduję system zarządzania zapasami jako aplikację komputerową przy użyciu node-webkit. projekt w trakcie budowy korzysta z compoundjs (biblioteka jvc javascript). które mają określoną strukturę folderów (znasz mvc) i wiele plików javascript w nich.

Problem polega na tym, że nwsnapshot pozwala aplikacji na pojedynczy plik migawki, ale logika aplikacji jest rozłożona na wszystkie foldery w różnych plikach javascript.

więc w jaki sposób zabezpieczyć swój kod źródłowy przed wysłaniem go do klienta? Albo jakikolwiek inny sposób pracy lub mądrzejszy sposób (tak, wiem o zaciemnianiu).

Answer 1

Można użyć nodewebkit polecenie o nazwie nwsnapshot do kompilacji kodu JavaScript do pliku binarnego, który zostanie załadowany do aplikacji bez podania jakichkolwiek js plik

nwsnapshot --extra-code application.js application.bin 

w package.json dodać to:

snapshot: 'application.bin' 

Answer 2

Można rozważyć scalenie plików JS w jeden w procesie kompilacji i skompilowanie go.

Answer 3

To naprawdę zależy od tego, co masz na myśli przez "bezpieczny".

Możesz dość dobrze zaciemnić swój kod javascript (a także potencjalnie poprawić wydajność) za pomocą Google Closure Compiler.

Nie jestem świadomy żadnych gotowych rozwiązań do szyfrowania/odszyfrowywania twojego javascriptu, i szczerze, kwestionowałbym potrzebę tego.

Niektórzy ludzie uważają, że uniemożliwiają wyświetlenie kodu źródłowego, ponieważ są przyzwyczajeni do obsługi języków, w których pliki są wysyłane tylko użytkownikom. Faktem jest, że inżynieria odwrotna, że ​​kod binarny nigdy nie był tak trudny, jak niektórzy myślą, że jest, więc jeśli istnieje jakikolwiek bodziec finansowy, praktycznie nie ma różnicy między kodem źródłowym wysyłki a tradycyjną wysyłką plików binarnych.

Niektóre języki oferują oryginalne szyfrowanie wdrożonych zasobów, takich jak Microsoft SLPS. Wydaje mi się, że rynek tego był tak mały, że Microsoft przekazał go partnerowi (tylko mój pogląd). Prawda jest taka, że ​​większość klientów nie jest zainteresowana przyjęciem kodu źródłowego; są bardziej zainteresowani Twoją zdolnością do obsługi i wsparcia tego kodu w efektywny sposób, podczas gdy oni wykonują swoją pracę.