узел.защита js-кода?
Я хочу использовать node.js в моем следующем проекте, но моему боссу не нравится, что наши конкуренты могут читать исходный код.
есть ли способ защитить код JavaScript?
12 ответов
вы можете выполнить это с помощью NativeExtension для node
ты boostrap.js
файл, который добавляет обработчик расширения для .файлы JSE
// register extension
require.extensions[".jse"] = function (m) {
m.exports = MyNativeExtension.decrypt(fs.readFileSync(m.filename));
};
require("YourCode.jse");
YourCode.jse
будет зашифрованной версией вашего исходного кода (ключ для дешифрования не будет нигде в обычном тексте, потому что процесс дешифрования происходит в собственном расширении).
теперь у вас есть ваши NativeExtensions decrypt
функция преобразует источник обратно в javascript. Просто ... процесс сборки create encrypted .jse
версии всех ваших файлов и освободить их для ваших клиентов. Им также понадобится собственное расширение, но теперь вам стало немного сложнее изменить свой код без особых усилий. Вы даже можете сделать собственный вызов расширения домой и проверить информацию о лицензии, чтобы помочь предотвратить пиратство (имейте в виду, что это не остановит пиратство, для этого нет решения).
просто включите лицензионное соглашение и дайте им исходный код. Они могут захотеть настроить его в любом случае.
поскольку я только что завершил огромный чистый проект Nodejs в 80 + файлах, у меня была та же проблема, что и OP. Мне нужна была хотя бы минимальная защита для моей тяжелой работы, но, похоже, эта самая основная потребность не была покрыта сообществом ОС NPMjs. Добавьте соль к травме система шифрования пакета JXCore была взломана на прошлой неделе через несколько часов, чтобы вернуться к запутыванию...
Итак, я создала комплексное решение, который обрабатывает слияние файла, уродуя. У вас есть возможность оставить указанный файлы/папки, а также от слияния. Эти файлы затем копируются в новое расположение вывода объединенного файла и ссылки на них автоматически переписываются.
PS: Я был бы рад, если бы люди вносят свой вклад, чтобы сделать его еще лучше. Это война между ворами и трудолюбивыми программистами вроде тебя. Давай объединим наши силы, увеличим боль обратного хода. инженерия!
чтобы быть очень ясным, клиентский Javascript (загруженный с удаленного сервера в стандартный веб-браузер) не может быть защищен от просмотра и/или модификации независимо от того, как вы его запутываете, так как реконструкция ("де-запутывание") исходного источника технически тривиальна. (JavaScript obfuscation-это просто еще один пример широко используемого неправильного определения безопасности "безопасность через неизвестность".)
Если вы хотите использовать Javascript и Node.js для обеспечения защищенного " продукта" (который в этом контексте является приложением или службой, требующей установки на сервере, который ваша компания не контролирует), вы не можете защитить его, поскольку единственный доступный вам вариант (обфускация) не обеспечивает такой защиты.
следует отметить, что даже если ваш продукт предоставляется как двоичный исполняемый файл, который не гарантирует, что вы можете защитить интеллектуальную собственность, которую он содержит, поскольку любой двоичный файл может быть декомпилирован в понятный формат. В этом случае мы наслаждаемся некоторым уровнем безопасность, основанная на избыточных ресурсах (время/опыт), необходимых для преобразования низкоуровневого машинного кода (как это предусмотрено декомпиляцией) в логические конструкции более высокого уровня, используемые современными языками программирования. (Это от того, кто однажды декомпилировал CP/M в понимание его внутреннего дизайна вручную. ;)
все, однако, не потеряно: если мы предположим, что можно защитить интеллектуальную собственность программно (жюри все еще на этом), есть способ обеспечить Узел.продукт на основе js в безопасном режиме, но это не для технически unadventurous, поскольку это потребует существенного рефакторинга узла.исходный код js (чтобы добавить поддержку криптографически защищенных библиотек и удалить-или иным образом защитить-отражение объекта для ваших собственных библиотек.)
код javascript на стороне сервера полностью закрыт. Никто не может его прочесть.
код javascript на стороне клиента полностью открыт. Все могут прочесть.
для последнего вы ничего не можете сделать, но то же самое относится к RoR, ASP.NET, PHP, etc.
фактический код сервера закрыт, если вы публично не сделаете его доступным.
Если вы делаете библиотеку и пытаетесь продать ее как сторонний источник, то она открыта и может быть украдена. Конечно вы можете подать на них в суд за нарушение авторских прав.
существуют различные крупные компании, такие как в ExtJS которые продают библиотеки, которые могут быть украдены, поэтому они на самом деле продают вам код и службу поддержки.
большинство коммерческих проектов, построенных на узле, являются службами.
можно использовать EncloseJS - компилятор для узла.проекты js. Он действительно компилирует JavaScript в собственный код, а ваши источники не включены в двоичный файл.
JXcore (узел.js 0.11.X distro) имеет свою собственную функцию упаковки JX, которая защищает исходный код и активы. Вы даже можете выбрать, можно ли использовать этот конкретный пакет из других приложений или нет. (автономный или библиотека)
допустим, у вас много JS и т. д. файлы и точка входа в ваш модуль-это что-то вроде;
exports.doThis = function() { ...... };
Если вы просто вызовете метод ниже и скомпилируете его в пакет JX, исходный код будет безопасный.
jxcore.utils.hideMethod(exports.doThis);
это (метод скрытия) требуется только для файла записи, так как все остальные файлы sub JS недоступны из вызывающего приложения.
вам нужно jxcore для запуска пакетов JX.
дополнительная информация JXcore
упакуйте свою основную логику в модули.. эти модули могут быть построены затем запустить через закрытие Google. Вы могли бы даже быть в состоянии сделать это как задач хрюкать как часть процесса построения.
Это старый вопрос, но стоит отметить. Примечание: ничто из того, что вы делаете, не скроет ваш код, но и ничего не будет отправлено через .Net (C#) или Java, если на то пошло. В общем, просто используя такой инструмент, как uglify, или закрытие должно быть достаточно точка помутнения рассудка. Будучи модульным и используя закрытие, вы можете сделать много оптимизаций, которые в противном случае были бы трудными.
можно использовать упаковщик для nodejs для запутывания вашего скрипта...
вы не можете быть абсолютно уверены, что никто не сможет прочитать ваш код. Вы можете использовать обфускацию или минификацию, что может значительно затруднить декодирование вашего кода. Один из примеров обфускатор/английское сокращение Cups компании Google Компилятора для JavaScript.
у меня есть идея.
Защитить cpp
или java
приложение вместо js.
- оберните код в формат шифрования и скомпилируйте его как
utf-8
файловые ресурсы. - использовать
cpp
илиjava
приложение для загрузки всего файла вlinux pc
илиarm computer
убедитесь, что у вас есть надежный пароль или закрытьssh port
или отключить видеопорт и просматривать ПК linux только по интернету. - существует программа cpp для расшифровки файла в linux pc.
- Разработка веб-сервера для управления ПК linux.
так что это очень похоже на черный ящик, клиенты ничего не могут сделать с вашим кодом.