14

Per prima cosa, ho visto nwsnapshot. e non sta aiutando.protezione del codice sorgente in un'applicazione desktop node-webkit

sto costruendo un sistema di gestione dell'inventario come applicazione desktop utilizzando node-webkit. il progetto in fase di costruzione utilizza compoundjs (libreria javascript di mvc). che hanno una struttura definita delle cartelle (conosci mvc) e più file javascript al loro interno.

il problema è nwsnapshot consente all'app di avere solo un singolo file di snapshot ma la logica dell'applicazione è distribuita su tutte le cartelle in diversi file javascript.

così come posso proteggere il mio codice sorgente prima di spedirlo al cliente? O qualsiasi altro work-around o modo più intelligente (sì, so di offuscamento).

risposta

20

È possibile utilizzare nodewebkit comando chiamato nwsnapshot per compilare il codice javascript in binario, che verrà caricato in app senza specificare qualsiasi file js

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

nel vostro package.json aggiungere questo:

snapshot: 'application.bin' 
+3

Questa dovrebbe essere la risposta accettata. nwsnapshot compila js source in bytecode e lo inserisce nel processo del nodo. La risposta accettata utilizza un minificatore del codice e un obfuscater che sono abbastanza facili da superare. –

+0

È possibile convertire altre risorse in binario come i file di font? Aggiornamento –

+0

: utilizzare [nwjc] (https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot). crea file binari molto più piccoli rispetto a nwsnapshot – sunnyvilles

0

Si può considerare di unire i file JS in uno nel processo di compilazione e compilarlo.

+0

qualsiasi riferimento o esempio o strumento>? – sunnyvilles

+1

http://requirejs.org/docs/optimization.html – pfried

+0

non è ancora quello che mi aspettavo, ma _requirejs_ è sufficiente per ora. grazie @pfried. – sunnyvilles

2

Dipende davvero da cosa intendi per "sicuro".

È possibile offuscare discretamente il codice javascript (oltre a migliorare potenzialmente le prestazioni) utilizzando lo Google Closure Compiler.

Non sono a conoscenza di soluzioni off-the-shelf per crittografare/decrittografare il tuo javascript e onestamente mi metterei in dubbio la necessità.

Alcune persone pensano di dover rendere impossibile la visualizzazione del codice sorgente, perché sono abituate a gestire le lingue compilate in cui vengono spediti solo i binari agli utenti. Il fatto è che la retroingegnerizzazione del codice binario non è mai stata così difficile come alcune persone pensano che sia così, quindi se c'è qualche incentivo finanziario, non c'è praticamente alcuna differenza tra il codice sorgente di spedizione e la spedizione tradizionale dei binari.

Alcune lingue hanno offerto la crittografia autentica delle risorse distribuite, come Microsoft SLPS. Mi sembra che il mercato per questo fosse così piccolo che Microsoft lo ha dato ad un partner (solo la mia opinione). La verità è che la maggior parte dei clienti non è interessata a prendere il codice sorgente; sono molto più interessati alla tua capacità di assistere e supportare quel codice in modo efficiente, mentre continuano il loro lavoro.