Защита компонентов и модулей от вареза - Флейм

Всем привет, интересует такой вопрос: допустим, написал я связку компонент\модуль, допустим на заказ, конкретному заказчику под конкретный сайт. Можно ли как то защитить это хозяйство от распространения? Посредством IonCube, например? Чтобы административная часть без ввода лицензионного ключа была недоступна. Фронт защищать не нужно, дефолтные настройки минимальны. Кто знает, пните в каком направлении поизучать.
Заранее спасибо!

А вы сколько раз хотите сделанное на заказ продавать? И каждый раз - как эксклюзив?
Если сделали по заказу, то вам должно быть всё равно, что потом заказчик с ним сделает. Пусть хоть даром раздаёт - вы свои деньги уже получили.

Ну пусть будет не на заказ, пусть будет на продажу, я описал гипотетическую ситуацию, вопрос то в целом понятен - есть ли возможность защиты приложения от копирования? Просто в OpenCart так делается, и защищено именно посредством IonCube, а вот для Joomla я такого нигде не нашел.

надежных защит нет.
вскрывается все.
ионкуб не проблема тоже.

сколько раз вы собрались продавать не важно. и даже каждый раз как эксклюзив, это не плохо. если конечно цена не как за разработку
только если вы собрались серийно продавать расширение/я, то важно оказывать саппорт. за него платят в основном, а не за расширение.

nevigen, мне просто интересно как можно было бы защитить например модуль, допустим тем же ионкубом, так чтобы доступ к настройкам модуля был только по лицензионному ключу. Сам механизм защиты не суть важен, а вот какой файл кодировать? mod_modname.php ? или helper.php ? и как реализовать проверку ключа, так чтобы, например, после установки модуля кроме поля ввода ключа и кнопки "Проверить ключ" настроек никаких не было, а когда ключ введен и он верный уже открывались бы все настройки модуля. В общем то в этом был вопрос.

А вы сколько раз хотите сделанное на заказ продавать? И каждый раз - как эксклюзив?
Если сделали по заказу, то вам должно быть всё равно, что потом заказчик с ним сделает. Пусть хоть даром раздаёт - вы свои деньги уже получили.

Оочень спорная постановка вопроса 

nevigen, мне просто интересно как можно было бы защитить например модуль, допустим тем же ионкубом, так чтобы доступ к настройкам модуля был только по лицензионному ключу. Сам механизм защиты не суть важен, а вот какой файл кодировать? mod_modname.php ? или helper.php ? и как реализовать проверку ключа, так чтобы, например, после установки модуля кроме поля ввода ключа и кнопки "Проверить ключ" настроек никаких не было, а когда ключ введен и он верный уже открывались бы все настройки модуля. В общем то в этом был вопрос.

насчет модуля не скажу.
там настройки в XML по сути.
можете только логику закрыть - хелпер.
и внутри него проверять ключ введенный из поля настроек.
а настройки будут видны все время. просто логика работать не будет.
либо настйроки выводить как-то нестандартным способ.
например формировать XML со всеми настройками, после ввода ключа в поставляемом XML по дефолту, с одним только полем
но это такой себе вариант

Всем привет, интересует такой вопрос: допустим, написал я связку компонент\модуль, допустим на заказ, конкретному заказчику под конкретный сайт. Можно ли как то защитить это хозяйство от распространения? Посредством IonCube, например? Чтобы административная часть без ввода лицензионного ключа была недоступна. Фронт защищать не нужно, дефолтные настройки минимальны. Кто знает, пните в каком направлении поизучать.
Заранее спасибо!

Не как. Любой метод который ты сможешь придумать, можно обойти. От IonCube это требования к серверу, которое многим не понравится.
К тому же вы скорее продаете поддержку и обновление, чем код.

Не как. Любой метод который ты сможешь придумать, можно обойти. От IonCube это требования к серверу, которое многим не понравится.
К тому же вы скорее продаете поддержку и обновление, чем код.

По этому же принципу работает замок на двери, любой можно взломать, но вы же закрываете дверь на ключ когда уходите. Любая защита она, скажем так, от "честных людей", кому надо те понятное дело раскодируют.

IonCube... которое многим не понравится

Тоже так думаю. Не понравится ни покупателям, ни антивирусным сканерам, которые часто есть на хостингах и уведомляют клиентов о возможных угрозах.
Сам не беру расширения с IonCube, без самой крайней необходимости..

Да мне тоже не нравится особо ионкуб, тем более что фишка то вообще то платная

Самый банальный, но распространенный способ - обфускация. Любой замок можно взломать, но важно, какие ресурсы будут потрачены на это. Если взлом будет стоить больше, чем условная тыща рублей, еще и без поддержки, то зачем он нужен?

Если честно не вижу смысла в платных расширениях, если конечно это не студия, которая выпускает их пачками.
Любое расширение требует, постоянной поддержки. Помощи в настройки, добавление хотелок и т.д. В случае с бесплатным распространением, все это можно делать в свободное время. Если же расширение платное, то люди тебе за это платят и послать куда подальше уже не выйдет.
Так что стоит сначала задуматься, а стоит ли оно того. Ибо можно просто подавать различные кастомные доработки.

Самый банальный, но распространенный способ - обфускация. Любой замок можно взломать, но важно, какие ресурсы будут потрачены на это. Если взлом будет стоить больше, чем условная тыща рублей, еще и без поддержки, то зачем он нужен?

Обфускацию пробовал, да, видимо самый простой вариант, но интересно было именно то, что есть ли какое то решение непосредственно для компонентов Joomla

Как-то делал модуль.
файл script.php при установке создавал маленькую таблицу бд
Модуль сделал на локалке, запаковал в архив установил на сервер
Не работает ... Забыл script.php включить в xml-файл ))
в работе сам файл не нужен только при установке

Может можно как то это использовать?

При установке будет создаваться что-то критическое для работы модуля
А файла в модуле не будет. Т.е повторить при повторной запаковке и установке не получится

А если домен меняется?

А если домен меняется?

Не понял ... можно поподробнее

Про ваше приповьорной установке.
Вдруг домен и хостинге меняется
Или восстанавливайте из бэкапа
И надо переустановить

Ну тогда заказчик обращается к разработчику и тот переустанавливает модуль))
делов-то 5 мин.

Ну тогда заказчик обращается к разработчику и тот переустанавливает модуль))
делов-то 5 мин.

Кстати как вариант, только зачем скрипту создавать таблицу? можно просто пустой файл ставить, указав его в манифесте, а потом удалять, скопировать модуль уже будет нельзя, не внеся изменений в манифест. Но этот способ от совсем уж честных людей, которые не лезут в код. А хотелось бы усложнить (хотя бы усложнить) жизнь тем, кто в код таки лазиет, потому что честные люди и не будут воровать модуль. Но как дополнительная "цепочка к дверному замку" вариант подойдет.

Самый банальный, но распространенный способ - обфускация.

В некоторых платных решениях, которыми я пользуюсь, применяется именно это.

Любой замок можно взломать, но важно, какие ресурсы будут потрачены на это.

Но, пожалуй, обфускацию стоит применять не для фронтенд расширений, влияющих на скорость загрузки посещаемых страниц.
Для бэкенда, для корзины и т.п. - вполне пригодно, думаю.

Закрывая код Joomla от других разработчиков вы нарушаете лицензию Joomla (GPL)
То есть сами стаете на сторону нарушителей.
Выход не писать используя Joomla, получать деньги за поддержку как вам гооворили выше

Закрывая код Joomla

А закрывая код своего расширения?

Цитата из ссылки..

В общем случае распространитель программы, полученной на условиях GPL, либо программы, основанной на таковой, обязан предоставить получателю возможность получить соответствующий исходный код.

А закрывая код своего расширения?

Сторонний код, к примеру стили js, отдельный библиотеки и т.д

Сторонний код, к примеру стили js, отдельный библиотеки и т.д

@Septdir, то есть, если, к примеру, подключаешь в своё расширение как-то свой фирменный PHP класс, то его (рассматривая как стороннюю библиотеку), можно закрывать и это не нарушает лицензию?

Ну тогда заказчик обращается к разработчику и тот переустанавливает модуль))
делов-то 5 мин.

А разработчик давно забил на проект, поменял контакты и вообще уехал на ПМЖ в Таиланд.

Кстати, с сайта GNU:

то есть, если, к примеру, подключаешь в своё расширение как-то свой фирменный PHP класс, то его (рассматривая как стороннюю библиотеку), можно закрывать и это не нарушает лицензию?

Образование подкласса является созданием производного произведения. Следовательно, условия GPL распространяются на всю программу, в которой вы создаете подкласс класса под GPL. (Отсюда)
Прямой GPL требует, чтобы любой, кто распространяет программное обеспечение, также распространял все источники для всего, что связано с ним. Ваши пользователи не могут этого сделать, поэтому они не смогут распространять информацию. Вы все еще можете распространять свой код, потому что у вас есть авторские права на ваш код, но никто другой не сможет этого сделать.
Из-за этого вы не можете действительно утверждать, что ваша программа является свободным программным обеспечением . (Отсюда)

@Septdir, то есть, если, к примеру, подключаешь в своё расширение как-то свой фирменный PHP класс, то его (рассматривая как стороннюю библиотеку), можно закрывать и это не нарушает лицензию?

Нет. Все, что написано на PHP, должно быть открытым. Кстати, обычная обфускация не является закрытием кода.

Все, что написано на PHP, должно быть открытым.

Ну в целом да, хотя теоретически независимую либу можно под другой лицензией.