Система лицензирования плагинов WordPress: как устроен лицензионный сервер

Как только вы решаете продавать плагин WordPress, возникают сразу три вопроса: как проверять, что клиент заплатил, как ограничивать число сайтов и как доставлять обновления только платящим пользователям. Ответ на все три даёт лицензионный сервер. Мы построили такую систему для AYM Multilingual, поэтому делимся архитектурой, которая выдержала реальную эксплуатацию.

Что лицензия продаёт на самом деле

Код плагинов WordPress распространяется под лицензией GPL, поэтому технически «запретить» запуск кода невозможно, да и не нужно. Лицензионный ключ на практике продаёт доступ к обновлениям, поддержке и сервисным функциям, например к ИИ-переводу или облачным возможностям. Понимание этого определяет архитектуру: система должна быть строгой с точки зрения доступа к обновлениям и мягкой с точки зрения работы сайта клиента.

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

Компоненты системы

Полноценная система лицензирования состоит из нескольких частей:

• База лицензий: ключ, тариф, статус, срок действия, лимит сайтов, список активаций.
• Лицензионный сервер: веб-сервис с API для активации, деактивации и проверки лицензий.
• Клиентский модуль в плагине: форма ввода ключа, обращения к серверу, кэш статуса.
• Сервер обновлений: выдаёт информацию о новой версии и ссылку на архив.
• Интеграция с оплатой: выпуск ключа после покупки, продление и отзыв при возврате платежа.
• Панель управления: просмотр лицензий и активаций, ручная выдача и отзыв.

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

Активация, проверка и привязка к домену

• activate: принимает ключ и адрес сайта, создаёт активацию и возвращает статус;
• deactivate: освобождает место в лимите, чтобы ключ можно было перенести;
• check: возвращает текущий статус и срок действия, вызывается по расписанию;
• update-info: сообщает последнюю версию, список изменений и защищённую ссылку на архив.

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

Тарифы с разным числом сайтов реализуются счётчиком активаций. У AYM Multilingual, например, есть тарифы на один сайт и тариф для агентств на пять сайтов с одним ключом, поэтому клиент должен иметь возможность самостоятельно деактивировать ключ на старом сайте и перенести его на новый. Без этого служба поддержки утонет в письмах о переезде. Подробнее о наших тарифах смотрите на странице цен.

Продумайте, что происходит при окончании лицензии. Хороший вариант: плагин продолжает выполнять основные функции, но обновления, поддержка и сервисные возможности отключаются, а в админке появляется спокойное напоминание о продлении. Блокировка сайта клиента из-за просроченной подписки разрушает доверие и приводит к возвратам платежей.

Формат ключа тоже имеет значение. Используйте длинные случайные значения, а не предсказуемые последовательности, и храните на сервере только хэш, если ключ не нужно показывать повторно. В интерфейсе плагина показывайте ключ частично замаскированным, а при ошибках давайте понятные сообщения: «лимит сайтов исчерпан», «срок лицензии истёк», «ключ не найден». Так обращений в поддержку станет заметно меньше.

Доставка обновлений через WordPress

Чтобы платные плагины обновлялись из админки как обычные, нужно подключиться к механизму обновлений WordPress. Стандартный способ состоит из двух шагов. Во-первых, фильтр transient обновлений плагинов дополняется данными о вашей новой версии. Во-вторых, фильтр plugins_api отвечает на запрос «Подробнее о версии» и отдаёт описание, список изменений и ссылку на архив. Ссылка на пакет защищается: сервер выдаёт её только при действующей лицензии, и срок жизни ссылки ограничен.

Все запросы клиентского модуля мы строим на REST API: подробно про него рассказано в документации WordPress. Не забывайте указывать для каждого маршрута проверку прав и валидацию аргументов.

Безопасность и защита от злоупотреблений

1. Передавайте данные только по HTTPS и проверяйте входные параметры на сервере так же строго, как в плагине.
2. Подписывайте ответы сервера, чтобы поддельный сервер не мог «включить» лицензию на сайте клиента.
3. Ограничивайте частоту запросов и записывайте журнал обращений, чтобы замечать подбор ключей.
4. Не храните в плагине секреты, которые позволяют генерировать ключи: любой код плагина доступен клиенту.
5. Предусмотрите льготный период после окончания лицензии: плагин продолжает работать, но не получает обновления и сервисные функции.
6. Не собирайте лишних персональных данных: достаточно адреса сайта, версии и статуса.

Базовые принципы безопасного кода плагина изложены в руководстве по безопасности, и они в полной мере относятся к клиентскому модулю лицензирования. Общий порядок разработки плагина мы описали в «руководстве по созданию плагина».

Готовое решение или своё

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

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

Для небольшого проекта можно взять готовый менеджер лицензий для WooCommerce, который уже умеет выпускать ключи и отдавать обновления. Собственный лицензионный сервер оправдан, когда нужны нестандартные тарифы, привязка к сервисным функциям, интеграция с вашей платёжной системой или полный контроль над данными клиентов. Это частный случай вопроса, который мы разбирали в статье «Заказная разработка или готовое решение».

Мы проектируем и реализуем такие системы в рамках разработки плагинов WordPress: от API и базы лицензий до клиентского модуля и сервера обновлений. Если вы готовите платный плагин к запуску, расскажите о проекте, и мы подберём архитектуру под ваш тариф и объём продаж.

Поделиться:XLinkedInWhatsApp