Мне больше интересно автоматическая отправка ключа после покупки.
Кажется разумным такой вариант:
1. Разработчик придумывает сам, каким образом хранить и программно обрабатывать лицензионные ключи.
2. Вы создании нового товара, продавец самостоятельно отправляет в сервис CODESELLER (далее Сервис) список ключей (например 100 штук, каждый с новой строки).
3. Покупатель оплачивает заказ, и вместе с файлами товара получает ключ (или несколько, если оплачена лицензия на несколько доменов).
4. Покупатель вводит ключ в созданное разработчиком поле. И идет отправка данных в Сервис. Если введенный ключ совпадает, то программный код товара активирует все остальные функции. При этом к этому ключу ставится метка - используется. Если ключ не верен, или стоит метка "используется", активация не происходит.
5. При деактивации, снова отправляется в Сервис команда, убирающая метку "используется". Покупатель может активировать товар на другом домене.
1. Разработчик придумывает сам, каким образом хранить и программно обрабатывать лицензионные ключи.
2. Вы создании нового товара, продавец самостоятельно отправляет в сервис CODESELLER (далее Сервис) список ключей (например 100 штук, каждый с новой строки).
3. Покупатель оплачивает заказ, и вместе с файлами товара получает ключ (или несколько, если оплачена лицензия на несколько доменов).
4. Покупатель вводит ключ в созданное разработчиком поле. И идет отправка данных в Сервис. Если введенный ключ совпадает, то программный код товара активирует все остальные функции. При этом к этому ключу ставится метка - используется. Если ключ не верен, или стоит метка "используется", активация не происходит.
5. При деактивации, снова отправляется в Сервис команда, убирающая метку "используется". Покупатель может активировать товар на другом домене.
Дык при таком раскладе зачем сервис CODESELLER, если сам придумывает, сам обрабатывает и сам хранит. Врубили все это у себя и обрабатывайте метки или как уже придумаете?
Разбираетесь кто диктивировал для отладки, кто переносит, кто спер и стучалка сработала. да и платить не придется серьезные деньги за уже отдельный сервер под ключи, только ваши там разработки будут. А все остальное как и прежде через магазин CODESELLER, только с ключом в комплекте.
Или уже говорить о каком то единообразии методов. Имхо конечно и вообще не задумывался в эту сторону лично я.
Я как-то Андрею предлагал идею на будущее (сам пока активацию ключами у своих продуктов не вводил - так сказать идея на вырост) - на гитхабе есть такое понятие как вебхуки (например срабатывают когда коммит пришел). Вот и я для сервиса кодеселлер примерно подобное озвучивал:
1. Покупают товар.
2. При этом идет пинг моего сервера (секретный урл, адрес к которому я указываю в профиле продавца на кодеселлер) с командой
3. Я на своем серваке принимаю данные и уже сам обрабатываю как надо
4. Если от моего сервера не пришел ответ "принял", то кодеселлер вновь спустя час к примеру меня оповещает.
5. Если снова провал - я вижу это в ЛК в своем аккаунте на кодеселлер и уже обрабатываю ручками - высылая юзеру ключи.
Всё как бы.
Я принимаю на своем серваке, своим скриптом токен и данные платежа (id заказа, товар, мыло юзера)
Дальше все просто: принял данные - кодеселлеру ответ отправил "Принял" и обрабатываю клиента - отправляю автоматом ключи.
Когда юзер активирует - он присылает активацию на мой сервак: совпадает - ок. Не совпадает - провал.
В общем мне такой механизм кажется более правильным. Да и к чему кодеселлеру решать за нас наши активационные проблемы?
Otshelnik-Fm сказал(а)
Я как-то Андрею предлагал идею на будущее (сам пока активацию ключами у своих продуктов не вводил - так сказать идея на вырост) - на гитхабе есть такое понятие как вебхуки (например срабатывают когда коммит пришел). Вот и я для сервиса кодеселлер примерно подобное озвучивал:
1. Покупают товар.
2. При этом идет пинг моего сервера (секретный урл, адрес к которому я указываю в профиле продавца на кодеселлер) с командой
3. Я на своем серваке принимаю данные и уже сам обрабатываю как надо
4. Если от моего сервера не пришел ответ "принял", то кодеселлер вновь спустя час к примеру меня оповещает.
5. Если снова провал - я вижу это в ЛК в своем аккаунте на кодеселлер и уже обрабатываю ручками - высылая юзеру ключи.Всё как бы.
Я принимаю на своем серваке, своим скриптом токен и данные платежа (id заказа, товар, мыло юзера)
Дальше все просто: принял данные - кодеселлеру ответ отправил "Принял" и обрабатываю клиента - отправляю автоматом ключи.Когда юзер активирует - он присылает активацию на мой сервак: совпадает - ок. Не совпадает - провал.
В общем мне такой механизм кажется более правильным. Да и к чему кодеселлеру решать за нас наши активационные проблемы?
А для чего все это? Ведь если кому то надо на халяву - это же не поможет, вырежут часть кода отвечающую за проверку и распространят.
А так, как вариант, мы же в админке вводим ключ для recall, который тут в ЛК есть. Можно сделать что бы при активации плагина была проверка - покупал ли владелец этого ключа плагин
Preci сказал(а)
А для чего все это? Ведь если кому то надо на халяву - это же не поможет, вырежут часть кода отвечающую за проверку и распространят.
давайте в этой теме не будем затрагивать этот вопрос давая идеи и тут как можно обходить.
Если автор захотел закрыть - его право.
Когда покупаешь на Envato то ключи приходят от них. Envato - это сервис для разработчиков.
И разработчики ПО особо не парятся на тему где продавать , т.к. на Envato есть партнерская программа и большая часть разработчиков с удовольствием отправляют туда покупателей. И причин тут несколько.
Основная причина это то что Envato хоть и берет комиссию за продажи, но с этой комиссии он делает реальную площадку по продажам. Envato предоставляет разработчикам сервис и им не надо думать о том как продать. Это делает Envato. Плюс любой разработчик понимает что один раз отправив клиента на Envato разработчик становится партнером и дальше с каждой покупки он будет получать с этого клиента процент. Абсолютно любой разработчик понимает что купив его продукт клиент еще купит несколько продуктов и многие клиенты будут продлевать на эти продукты лицензии(поддержку) , а это значит реферальные отчисления.
Вот и весь секрет Envato. Сервис для разработчиков + мотивация. Поэтому там все и продают)
А все ключи это так... формальная дисциплина. Основные покупатели - это разработчики сайтов и им нуленки не выгодны, т.к. они подсаживая клиента на платные продукты также становятся рефералами и получают бабло. Все очень просто:)
При желании можно капитально защитить. Скачивал одну тему, не помню автора. В нем бесплатная версия распространялась со ссылками на их сайт. В общем, при удалении внешних ссылок, сайт переставал отображаться. В итоге, так и не удалось понять, как была организована защита, хотя с WP уже несколько лет имел дело.
Ян Александров сказал(а)
При желании можно капитально защитить. Скачивал одну тему, не помню автора. В нем бесплатная версия распространялась со ссылками на их сайт. В общем, при удалении внешних ссылок, сайт переставал отображаться. В итоге, так и не удалось понять, как была организована защита, хотя с WP уже несколько лет имел дело.
Для чего капитальная защита? От пары школьников?
Ян Александров сказал(а)
При желании можно капитально защитить. Скачивал одну тему, не помню автора. В нем бесплатная версия распространялась со ссылками на их сайт. В общем, при удалении внешних ссылок, сайт переставал отображаться. В итоге, так и не удалось понять, как была организована защита, хотя с WP уже несколько лет имел дело.
Капитальная защита возможна если только как-то супер-пупер зашифровать весь код плагина, но тогда невозможно будет с ним работать. Если бы Андрей, например, так зашифровал все свои плагины - не получилось бы другим писать расширения.
Вообще как я уже написал на мой взгляд не стоит заморачиваться что бы делать какие-то сильные защиты с проверкой лицензии через свой сервер (а если у вас сервер упадет, то сайты всех клиентов то же?) кому нужен плагин и он вообще не хочет платить - тот либо забьет, либо найдет хакнутую версию. Но тогда будут риски что тот кто хакнул засунет какой-то вирус в код, не будет постоянно обновлять версию, у тебя не будет поддержки и т.п.
Простой защиты с проверкой на то что аккаунт покупал этот плагин, намой взгляд, будет вполне достаточно. Тем более аналог уже наверно есть, если я не ошибаюсь то без действующего VIP плагины с этой меткой не будут активироваться или обновляться
Знаю одну системку с открытым кодом, но допы были зазендены, а потом все в ionCube. В итоге кроме как гемора для пользователей никаких плюсов я не вижу. Нет к ним дополнений, под каждый чих хостера разработчикам надо каждому пользователя выеживатся и делать, если кто и что то все же умудрился свое прикрутить и тут выворачиваться даже при обновлении, которые очень редки в итоге. И это не говоря о глобальных изменениях, скажем когда версия php меняется, а куб еще не работает с ней.
В итоге имеем одну cms под открытой лицензией и вторую с плагином под закрытой и всего три официальных плагина, куча недо плагинов 🙂
И естественно вагон уже хакнутого, с доработками в итоге.
Да, забыл, еще и ключ с привязкой к домену, плюс мего гемор с официальной перепродажей есть. Зачем то воткнули прайс на переоформление и сами понимаете когда есть прайс с разными ценниками на это дело, получается еще один прекрасный момент для жуликов.
Конечно, что то кардинально закрывать смысла нет, так все равно сломают, но ТС вполне понимаю, тк привязка к домену, пусть даже с возможностью перепривязки позволяет хотя бы не тратить свое время на поддержку 100500 сайтов с одного заказа, хорошо, если привязка еще и позволяет ограничивать возможность обновления.
То как это сделано сейчас на этом сервисе не позволяет предложить этот функционал к использованию сторонним разработчикам, если только позже я рассмотрю какой то упрощенный вариант, с простой отправкой ключей и фиксацией доменов, это вполне возможно.
