Javascript node.js - 代码保护？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5951302/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
node.js - Code Protection?
提问by Van Coding
I want to use node.js in my next project, but my boss does not like that our competitors can read the source code.
我想在我的下一个项目中使用 node.js，但我的老板不喜欢我们的竞争对手可以阅读源代码。
Is there a way to protect the JavaScript code?
有没有办法保护 JavaScript 代码？
回答by Christopher Tarquini
You could accomplish this with a NativeExtension for node
您可以使用节点的 NativeExtension 完成此操作
You'd have a boostrap.jsfile that adds a extension handler for .jse files
您将有一个boostrap.js为 .jse 文件添加扩展处理程序的文件
// register extension
require.extensions[".jse"] = function (m) {
m.exports = MyNativeExtension.decrypt(fs.readFileSync(m.filename));
};
require("YourCode.jse");
YourCode.jsewould be the encrypted version of your source code (the key for decryption wouldn't be anywhere in plain-text because the decryption process takes place in the native extension).
YourCode.jse将是您的源代码的加密版本（解密密钥不会以纯文本形式存在，因为解密过程发生在本机扩展中）。
Now you have your NativeExtensions decryptfunction transform the source back to javascript. Just have your build process create encrypted .jseversions of all your files and release those to your customers. They'd also need the native extension but now you've made it a little harder to modify your code without too much effort. You can even make the native extension call home and check license information to help prevent piracy (keep in mind this won't stop piracy, there's no solution for that).
现在，您的 NativeExtensionsdecrypt函数将源代码转换回 javascript。只需让您的构建过程创建.jse所有文件的加密版本并将其发布给您的客户。他们还需要本机扩展，但现在您在不费力的情况下修改代码变得有点困难。您甚至可以让本地扩展回电并检查许可证信息以帮助防止盗版（请记住，这不会阻止盗版，没有解决方案）。
回答by Mike Blandford
Just include a license agreement and give them the source code. They might want to customize it anyway.
只需包含许可协议并提供源代码即可。无论如何，他们可能想要自定义它。
回答by user2667976
As I have just completed a huge pure Nodejs project in 80+ files I had the same problem as OP. I needed at least a minimal protection for my hard work, but it seems this very basic need had not been covered by the NPMjs OS community. Add salt to injury the JXCore package encryption system was cracked last week in a few hours so back to obfuscation...
由于我刚刚在 80 多个文件中完成了一个巨大的纯 Nodejs 项目，因此我遇到了与 OP 相同的问题。我的辛勤工作至少需要最低限度的保护，但 NPMjs 操作系统社区似乎没有涵盖这个非常基本的需求。雪上加霜 JXCore 包加密系统上周在几个小时内就被破解了，所以回到混淆......
So I created the complete solution, that handles file merging, uglifying. You have the option of leaving out specified files/folders as well from merging. These files are then copied to the new output location of the merged file and references to them are rewritten auto.
所以我创建了完整的解决方案，处理文件合并、丑化。您可以选择不合并指定的文件/文件夹。然后将这些文件复制到合并文件的新输出位置，并自动重写对它们的引用。
Github repo of of node-uglifier
PS: I would be glad if people would contribute to make it even better. This is a war between thieves and hard working coders like yourself. Lets join our forces, increase the pain of reverse engineering!
PS：如果人们愿意做出贡献，让它变得更好，我会很高兴。这是小偷和像你这样努力工作的程序员之间的War。让我们一起加油，增加逆向工程的痛苦！
回答by Rob Raisch
To be very clear, client-side Javascript (as downloaded from a remote server into a standard web browser) cannot be protected from viewing and/or modification no matter how you obfuscate it since reconstruction ("de-obfuscation") of the original source is technically trivial. (Javascript obfuscation is simply another example of the widely used security misnomer "security through obscurity".)
非常清楚，客户端 Javascript（从远程服务器下载到标准 Web 浏览器中）无法防止查看和/或修改，无论您如何混淆它，因为原始源的重建（“去混淆”）在技术上是微不足道的。（Javascript混淆只是广泛使用的安全误称“通过默默无闻的安全”的另一个例子。）
If you wish to use Javascript and Node.js to provide a protected "product" (which in this context is an application or service requiring installation on a server your company does not control), you cannot secure it either as the only option available to you (obfuscation) provides no such protection.
如果您希望使用 Javascript 和 Node.js 来提供受保护的“产品”（在此上下文中是指需要在您的公司无法控制的服务器上安装的应用程序或服务），您也无法将其作为唯一可用的选择您（混淆）不提供此类保护。
It should be noted that even if your product is provided as a binary executable that is no guarantee you can protect the intellectual property it contains as any binary can be decompiled into an understandable format. In this case, we enjoy some level of security based on the excessive resources (time/expertise) required to convert low-level machine code (as provided by decompilation) into the higher-level logic constructs used by modern programming languages. (This from one who once decompiled CP/M into an understanding of its internal design by hand. ;)
应该注意的是，即使您的产品是作为二进制可执行文件提供的，也不能保证您可以保护它包含的知识产权，因为任何二进制文件都可以反编译为可理解的格式。在这种情况下，基于将低级机器代码（由反编译提供）转换为现代编程语言使用的高级逻辑结构所需的过多资源（时间/专业知识），我们享有一定程度的安全性。（这来自一个曾经将 CP/M 反编译成对其内部设计的理解的人。;）
All however is not lost: if we assume that one can protect intellectual property programmatically (the jury is still out on this one), there is a way to provide a Node.js-based product in a secure fashion, but it is not for the technically unadventurous as it would require substantial refactoring of the Node.js source code (to add support for cryptographically secure libraries and remove--or otherwise protect--object reflection for your proprietary libraries.)
然而，一切都没有丢失：如果我们假设可以以编程方式保护知识产权（陪审团仍在此问题上），则有一种方法可以以安全的方式提供基于 Node.js 的产品，但它不适用于技术上不冒险，因为它需要对 Node.js 源代码进行大量重构（以添加对加密安全库的支持，并删除或以其他方式保护您的专有库的对象反射。）
回答by Raynos
Server side javascript code is completely closed source. No-one can read it.
服务器端 javascript 代码是完全闭源的。没有人能读懂。
Client side javascript code is completely open source. Everyone can read it.
客户端 javascript 代码是完全开源的。每个人都可以阅读它。
For the latter you can do nothing but the same applies for RoR, ASP.NET, PHP, etc.
对于后者，您无能为力，但同样适用于 RoR、ASP.NET、PHP 等。
The actual server code is closed unless you publicly make it available.
除非您公开提供，否则实际的服务器代码是关闭的。
If your making a library and trying to sell it as 3rd party source then it's open and can be stolen. Of course you can sue them for copyright breach.
如果您制作了一个库并试图将其作为第 3 方来源出售，那么它是开放的并且可能被盗。当然，您可以起诉他们侵犯版权。
There are various big companies like extjswhich sell libraries which could be stolen that's why what they actually sell you is the code and a support service.
有很多像extjs这样的大公司出售可能被盗的库，这就是为什么他们实际上向您出售的是代码和支持服务。
Most commercial projects build on node are services.
大多数建立在节点上的商业项目都是服务。
回答by Nuray Altin
JXcore(node.js 0.11.X distro) has its own JX packaging feature that secure the source code and assets. You can even select whether that particular package can be used from other applications or not. (standalone OR library)
JXcore（node.js 0.11.X 发行版）有自己的 JX 打包功能，可以保护源代码和资产。您甚至可以选择是否可以从其他应用程序中使用该特定包。（独立的 OR 库）
Let's say you have many JS etc. files and the entry point to your module is something like;
假设您有许多 JS 等文件，并且模块的入口点类似于；
exports.doThis = function() { ...... };
if you simply call the method below and compile it to JX package, the source code will be safe.
如果直接调用下面的方法编译成JX包，源码就安全了。
jxcore.utils.hideMethod(exports.doThis);
this is (method hiding) would only required for the entry file since all the other sub JS files not reachable from the calling application.
这是（方法隐藏）只需要入口文件，因为所有其他子 JS 文件都无法从调用应用程序访问。
You need JXcore to run JX packages.
您需要 JXcore 来运行 JX 包。
More information is available from JXcore
更多信息可从JXcore 获得
回答by Tracker1
Package your core logic into modules.. these modules can be built then run through Google's closure. You could even be able to do this as a Grunt taskas part of your build process.
将你的核心逻辑打包成模块。这些模块可以被构建然后通过谷歌的闭包运行。作为构建过程的一部分，您甚至可以将其作为Grunt 任务来执行。
It's an old question but worth pointing out. Note: nothing you do will truly hide your code, but neither will anything shipped via .Net (C#) or Java for that matter. In general, simply using a tool like uglify, or closure should be enough of an obfuscation point. By being modular and using closure you can actually do a lot of optimizations that otherwise would be difficult.
这是一个老问题，但值得指出。注意：您所做的任何事情都不会真正隐藏您的代码，但也不会通过 .Net (C#) 或 Java 提供任何内容。一般来说，简单地使用像 uglify 或闭包这样的工具就足以成为混淆点。通过模块化和使用闭包，你实际上可以做很多否则会很困难的优化。
回答by Igor Klopov
回答by jwueller
There is no way you can be absolutely sure that nobody will be able to read your code. You could use obfuscation or minification, which can make it significantly harder to decode your code, though. One example of an obfuscator/minifier is Google's Closure Compilerfor JavaScript.
您无法绝对确定没有人能够阅读您的代码。但是，您可以使用混淆或缩小，这会使解码代码变得更加困难。混淆器/压缩器的一个示例是 Google 的JavaScript Closure Compiler。
