Вобщем сабж. Планирую с коллегами создать веб сервис, основной функционал будет на ява скрипте, увы на php, python-е, там организационно не получится. Есть ли эффективные способы защиты ява скриптов? Раньше гуглил тему, встречал различные обфускаторы и крипторы, но защита весьма хилая. Может появились продвинутые компоненты для браузеров или фреймворки?
Как помне так вряд ли, все что будет будет емкое и тяжелое. Ведь проблема в том что бы клиент не смог распарсить клиентскую часть. А ее он Не прочитать не сможет. Так что вот так. Мое ИМХО
А, собственно, зачем? Что в этом коде такого уникального? Если там какие-то хитрые алгоритмы, то большой вопрос: зачем это делать на js? Это типично серверная задача. Чтобы клиент не мог украсть скрипт и перенести на другой сайт? Так после обфускатора сложность сопровождения такого кода уже сопоставима с написанием нового. А может модель более правильно построить? Сайт без поддержки загнется или устареет через полгода. Более правильно продавать поддержку.
sigma 06.09.2017 10:47 пишет: А, собственно, зачем? Что в этом коде такого уникального? Если там какие-то хитрые алгоритмы, то большой вопрос: зачем это делать на js? Это типично серверная задача. Чтобы клиент не мог украсть скрипт и перенести на другой сайт? Так после обфускатора сложность сопровождения такого кода уже сопоставима с написанием нового. А может модель более правильно построить? Сайт без поддержки загнется или устареет через полгода. Более правильно продавать поддержку.
Вероятность утащить логику существует зная что делает жабаскрипт. Я так сливаю некоторые данные с сайтов периодический. Но вот реально сколько таких как я и нужно ли это вообще кому-то кроме меня думаю процент не большой. Это как с кражей картинок с сайта. Вроде на жабе код написан но украсть всеравно можно Так и тут. А серверную часть гадать алгоритм ещё то занятие. Я бы забил на это.
Странньій вопрос у вас как разработчиков на жс Нет, нельзя его защитить, вьі его передаете браузеру для того что-бьі он прочитал и вьіполнил его. Вариант, как уже сказали, обфускатор, нубов отобьет, ну а остальньім... кто захочет - тот прочтет. К слову рнр, питон и прочее с разной степенью удачи, но декриптуют.
perldoc -qhide
В ответ на: How can I hide the source for my Perl program? Delete it. :-) Seriously
sigma 06.09.2017 10:47 пишет: А, собственно, зачем? Что в этом коде такого уникального? Если там какие-то хитрые алгоритмы, то большой вопрос: зачем это делать на js?
есть 2 архи важные причины почему алгоритмы должны быть на js, озвучивать их бы не хотел, но поверьте если бы не эти причины то 100 процентов сделали бы на пхп. Нужно чтобы код работал на стороне клиента.
я всё равно не пойму что можно спереть на фронтэнде. код делается нечитаемый минимализаторами, а больше и не надо. всё равно всё логика в базе или около неё, а в броуезере восновном квадратики, кружочки рисуют.
Я конечно не телепат, но учитывая, что ТС занимается торговыми роботами, то предполагаю, что задача сделать так, чтобы запросы на API уходили от клиента. При этом, ничего не мешает вынести логику на бэкенд.
codex 07.09.2017 11:17 пишет: Я конечно не телепат, но учитывая, что ТС занимается торговыми роботами, то предполагаю, что задача сделать так, чтобы запросы на API уходили от клиента. При этом, ничего не мешает вынести логику на бэкенд.
ну вы батенька Шерлок Холмс Все верно, запросы должны уходить от клиента, с их айпишнков и так званные secret для АПИ биржи тоже должны уходить с их компа напрямую на биржу, минуя мой сервер.
А что мешает на сях сделать апу? Сам балуюсь написанием торгового бота для полоникса, написал апи на перле, а там уже логику заворачивай как хочешь. С другой стороньі снифать все можно, и в запросах как раз и будет вся логика как на ладони, прячь код или не прячь.
Я так понял робот коммуницирует прямо с сервером минуя сервер разработчика, как обычное приложение. Значит весь код хранится непосредственно на клиенте, а значит любая логика будет де-факто открыта.
Вопрос только в том, разрешено или нет передавать ключи на сервер разработчика?
Если нет, то решений особо не существует. Если есть - то можно проксировать запросы от клиента, бавляя ключ или OAuth токен, который пришел от клиента. От клиента только идут сырые данные и токен. Ничего кроме логики на сервере не хранится.
Если в оферте использования службы обязательна коммуникация с айпи клиента, но нет запрета использования ключей клиента сервером, то можно коммуникацию проксировать через клиента, открывая реверсный туннель. Самое примитивное - сам клиент будет дописывать ключ и посылать дальше. Саму службу в облаке можно будет масштабировать динамически по количеству подключенных клиентов и временным затратам на проксирование. Проблема ддоса останется, так как служба ТС, вероятно, платная. И ее надо решать отдельно, создавая полноценную CDN
Вообще сложно сказать что нужно получить в результате, не видя общей картинки.
kvadjagan 06.09.2017 10:23 пишет: Вобщем сабж. Планирую с коллегами создать веб сервис, основной функционал будет на ява скрипте, увы на php, python-е, там организационно не получится. Есть ли эффективные способы защиты ява скриптов? Раньше гуглил тему, встречал различные обфускаторы и крипторы, но защита весьма хилая. Может появились продвинутые компоненты для браузеров или фреймворки?
вгадайте з трьох разів, чому у додатків на js при підключенні до того ж гугл API немає secret А для інших варіантів - є
Tibor 08.09.2017 10:44 пишет: Я так понял робот коммуницирует прямо с сервером минуя сервер разработчика, как обычное приложение. Значит весь код хранится непосредственно на клиенте, а значит любая логика будет де-факто открыта.
Вопрос только в том, разрешено или нет передавать ключи на сервер разработчика?
на мой сервер не будут передаватся не апи кей не секрет. Хочу чтобы все крутилось у пользователя в браузере. Чтобы если у пользователя спионерят ключи я был не виноват. Ну и пользователи понимали что отвественность только на них. Общение идет напрямую между их компами и биржей в браузере. Биржевой робот в виде отдельной экзешной софтины уже есть, но часть клиентов говорят что хотят веб сервис, им ломово ставить прогу и они хотят управлять роботом в андродидовых приложений или яблочных. Мы пока не можем понять услуг толковых кодеров мобильного софта. Сошлись на идее веб приложения.
kvadjagan 06.09.2017 10:23 пишет: Вобщем сабж. Планирую с коллегами создать веб сервис, основной функционал будет на ява скрипте, увы на php, python-е, там организационно не получится. Есть ли эффективные способы защиты ява скриптов? Раньше гуглил тему, встречал различные обфускаторы и крипторы, но защита весьма хилая. Может появились продвинутые компоненты для браузеров или фреймворки?
вгадайте з трьох разів, чому у додатків на js при підключенні до того ж гугл API немає secret А для інших варіантів - є
ну мне в чистом виде js сто процентов не подойдет, я его даже и не рассматриваю, все возможные варианты конвертации его в нечто более защищенное мне подойдут. Пока два кодера которые хорошо знают node.js отвалились.
на мой сервер не будут передаватся не апи кей не секрет. Хочу чтобы все крутилось у пользователя в браузере. Чтобы если у пользователя спионерят ключи я был не виноват. Ну и пользователи понимали что отвественность только на них. Общение идет напрямую между их компами и биржей в браузере. Биржевой робот в виде отдельной экзешной софтины уже есть, но часть клиентов говорят что хотят веб сервис, им ломово ставить прогу и они хотят управлять роботом в андродидовых приложений или яблочных. Мы пока не можем понять услуг толковых кодеров мобильного софта. Сошлись на идее веб приложения.