Альфа-тест! Внимание! Attention! Achtung! Atención Attention 注意 انتباه Atenção Attenzione

Что такое саблицензии

Саблицензии - это ключи доступа к конкретному паку или мини-приложению, которое сделал автор этого пака.

Это может быть кликер, бот, тул, helper, готовая мини-аппка под конкретную задачу - неважно. Смысл в том, что вы делаете свой продукт на базе EyeAuras и сами решаете:

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

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

Пример такого подхода: мини-аппка на базе EyeAuras

Важно: сам EyeAuras теперь бесплатен

Отдельная лицензия на сам EyeAuras для использования саблицензий не нужна.

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

Авторизация через ключ

Чтобы пользователю было проще начать работу, в EyeAuras есть вход по ключу без отдельной регистрации.

Пользователь просто нажимает I have a key, вставляет ключ, и программа автоматически создает для него аккаунт. Дальше он может пользоваться паком как обычный пользователь.

Что получает автор пака

На странице пака у автора теперь есть отдельный блок, связанный с лицензированием.

Выпуск ключей

Саблицензии предполагают, что ключи распространяете вы, автор пака, через любые удобные площадки.

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

На практике варианты такие:

• самый простой - FunPay, Plati.ru и похожие площадки
• более взрослый вариант - свой сайт или лендинг с продажей ключей
• если продукт нишевый - можно вообще продавать ключи вручную через Discord/Telegram

Пока идет альфа, выпуск ключей все еще через меня. Проще всего связаться через контакты, обычно быстрее всего через Discord.

После альфы выпуск ключей станет автоматическим. Базовая идея такая:

• вы публикуете мини-аппку или пак
• выпускаете первую партию ключей
• распространяете их любым удобным способом
• если продажи пошли и нужна еще партия ключей, вы заказываете ее через сайт
• комиссия EyeAuras будет 15%, то есть 85% остается автору

Итог простой: пока вы ничего не заработали, вы ничего не теряете.

License Settings

Здесь настраивается, как именно будет работать лицензирование вашего пака.

Важно: изменения не ретроактивны. Если вы уже выпустили ключи с определенными условиями, они такими и останутся. Пользователь должен быть уверен, что купленный ключ не изменится задним числом.

Подсчет времени

Определяет, как тратится время лицензии.

Calendar - классическая модель. Ключ выдается на срок вроде недели или месяца, и время идет само по себе. Закрыли программу - время все равно идет.

Consumed - считается только время, когда пользователь реально пользуется программой. Закрыли EyeAuras - время не идет.

Заморозка ключей

Автор может временно заморозить лицензии и остановить расход времени.

Это удобно, если после обновления что-то сломалось и нужно спокойно все починить. В такой ситуации можно заморозить ключи, исправить проблему и потом разморозить их обратно. Пользователи не потеряют время в простое.

Важно: для Calendar этот режим пока еще дописывается. Для Consumed он уже должен работать нормально.

Подсчет сессий

У каждого ключа есть определенное количество сессий. По умолчанию обычно это 1.

Что именно считается "сессией", определяете вы, автор пака:

• просто сам факт, что приложение запущено
• количество окон
• использование конкретного ресурса
• любая другая логика, которую вы заложите в код

EyeAuras сам не придумывает, что такое сессия именно для вашего продукта - он только считает и обслуживает эти сессии.

Привязка к железу

Можно выпускать ключи, которые при первом использовании привязываются к конкретному компьютеру.

Если пользователь захочет использовать пак на другом ПК, для этого можно:

• купить еще один ключ
• либо, если вы разрешили это настройками, сбросить привязку

Просмотр списка лицензий

Пока это в первую очередь список выпущенных лицензий и их текущего статуса.

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

Просмотр списка подключений

Это нужно для отслеживания онлайна и понимания, используется ли ваш продукт прямо сейчас.

Список анонимизирован. Видно только сам факт подключения и техническое состояние лицензии, но не видно, кто именно это делает.

Позже здесь появится больше статистики по росту и активности пользователей.

Ключи и активация

Как пользователь получает ключ

Ключ пользователь получает не у EyeAuras, а у автора пака.

То есть схема простая:

• автор делает продукт
• автор выпускает ключи
• автор продает или раздает их
• пользователь активирует этот ключ в EyeAuras

Как активировать ключ

Есть два обычных сценария.

1. Привязать ключ к уже существующему аккаунту

Если у пользователя уже есть аккаунт EyeAuras, он может просто зайти в профиль и активировать ключ там.

2. Войти сразу по ключу

Если аккаунта еще нет, можно просто нажать I have a key и войти только по ключу.

Оба варианта рабочие. Разница только в том, есть ли у пользователя уже аккаунт или EyeAuras создаст его автоматически в момент входа.

Что видит пользователь после активации

На странице My Account и прямо в окне логина теперь есть таймлайн активированных саблицензий.

Там видно:

• для каких паков куплен доступ
• какие лицензии активны
• когда они истекают
• какие из них сейчас используются

Пользовательская заморозка

Пользователь тоже может заморозить свою лицензию на неопределенный срок.

Пока лицензия заморожена, время не расходуется.

Количество таких заморозок ограничено. Точное число настраивает автор пака, а по умолчанию сейчас обычно стоит 1.

Два уровня кастомизации

С точки зрения саблицензий у авторов обычно есть два очень разных сценария.

1. Вы добавили скрипты или функционал, но пользователь все еще работает через обычный UI EyeAuras

Это самый простой вариант.

В таком случае ничего отдельного придумывать с логином обычно не нужно:

• у пользователя уже есть окно логина EyeAuras
• есть вход по ключу
• есть активация ключей в профиле
• есть таймлайн саблицензий

То есть вы просто добавляете в пак логику аренды и проверки лицензии, а весь пользовательский сценарий входа остается на стороне самого EyeAuras.

2. Вы делаете свой кастомный UI

Это уже сценарий mini-app или почти отдельной программы.

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

Здесь есть два подварианта:

• комбинированный подход: EyeAuras все еще остается "снаружи", но пользователь запускает ваше мини-приложение кнопкой, скриптом или из интерфейса пака
• полностью кастомный подход: вы пишете свой интерфейс и строите mini-app примерно так, как показано здесь: пример mini-app

Самый безопасный формат в итоге - именно полностью кастомный UI.

Как добавить логин в своем интерфейсе

Если у вас свой UI, есть два основных варианта.

Вариант 1. Использовать LoginWidget

Это самый быстрый способ, если у вас Blazor-окно и вы не хотите писать форму логина самостоятельно.

Достаточно вставить в свое окно:

<LoginWidget/>

Так пользователь сможет открыть стандартное окно логина EyeAuras прямо из вашего интерфейса.

Вариант 2. Написать полностью свой логин

Если у вас свой ImGui / Blazor / WPF / любой другой интерфейс, вы можете работать напрямую через IEyeHubService.

На практике вам обычно нужны такие операции:

• PerformLogin(username, password) - обычный логин по имени пользователя и паролю
• PerformLogin(licenseKey, licenseKey) - вход по ключу без отдельной регистрации
• ActivateLicenseKey(licenseKey) - привязка дополнительного ключа к уже залогиненному аккаунту
• ActiveLicense - текущее состояние лицензии
• ConnectionState, ConnectedFor, DisconnectedFor - состояние соединения

Минимальная схема выглядит так:

var eyeHub = GetService<IEyeHubService>();

var userLicense = await eyeHub.PerformLogin(username, password);
var keyLicense = await eyeHub.PerformLogin(licenseKey, licenseKey); // key login
var updatedLicense = await eyeHub.ActivateLicenseKey(extraLicenseKey); // only for already logged-in user

Log.Info($"Current user: {eyeHub.ActiveLicense.Username}");
Log.Info($"Connection state: {eyeHub.ConnectionState}");

Практически это позволяет собрать полностью свой экран логина, свой профиль, свои статусы подключения и вообще не выводить стандартный UI EyeAuras пользователю напрямую.

Что теперь можно читать из ActiveLicense

Кроме базового Username, в лицензии теперь доступны и другие подписанные поля:

• UserId - стабильный идентификатор пользователя из подписанной лицензии
• Roles - роли пользователя, если они были выданы сервером
• HardwareId - hardware id, который попал в лицензию
• AppVersion - версия приложения, для которой была выдана лицензия
• StartsAt - момент начала действия лицензии

Если нужен именно стабильный идентификатор пользователя для вашего собственного кода, своей БД, своего backend или привязки пользовательских данных, берите именно UserId, а не Username.

Минимальный пример через ILicenseAccessor:

var license = GetService<ILicenseAccessor>();

Log.Info($"Username: {license.Username}");
Log.Info($"UserId: {license.UserId}");
Log.Info($"HardwareId: {license.HardwareId}");
Log.Info($"AppVersion: {license.AppVersion}");
Log.Info($"StartsAt: {license.StartsAt}");
Log.Info($"Roles: {string.Join(", ", license.Roles)}");

Если вы уже работаете через IEyeHubService, получить UserId можно и так:

var eyeHub = GetService<IEyeHubService>();
var userId = eyeHub.ActiveLicense.UserId;

Log.Info($"Current user id: {userId}");

В крайнем случае можно читать и отдельные raw-атрибуты через GetAttribute(...), но это уже скорее запасной путь:

var license = GetService<ILicenseAccessor>();
var userId = license.GetAttribute("UserId");

Что теперь можно читать из саблицензии

У элементов в ShareSublicenses теперь есть явный MaximumSessions.

Это полезно, если вы хотите:

• показать пользователю лимит прямо в своем UI
• логировать или диагностировать состояние лицензии
• подстроить свое поведение под конфигурацию ключа

Пример:

var license = GetService<ILicenseAccessor>();

foreach (var sublicense in license.ShareSublicenses)
{
    Log.Info($"ShareId: {sublicense.ShareId}");
    Log.Info($"MaximumSessions: {sublicense.MaximumSessions}");
    Log.Info($"ExpiresAt: {sublicense.ExpiresAt}");
}

Важно: читать metadata из ShareSublicenses нормально, но принимать решение о том, выдан ли доступ к паку прямо сейчас, все равно нужно через ISublicenseManager и lease, как описано ниже.

Для авторов паков: важно обновить код проверки

Если у вас уже есть пак с саблицензиями, обязательно прочитайте этот блок.

Механизм проверки саблицензий сильно изменился.

Раньше можно было просто читать список саблицензий из текущей лицензии, например через ILicenseAccessor.ShareSublicenses.

Теперь для новых версий EyeAuras правильная модель другая:

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

Что будет, если ничего не менять

Если оставить старую пассивную проверку и не перейти на новый API, поведение будет таким:

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

Коротко: для новых паков и новых версий клиента старый способ больше не подходит.

Если вы собираетесь публиковать или обновлять пак под новую версию EyeAuras, миграция на ISublicenseManager обязательна.

Новый способ проверки

Теперь нужно использовать ISublicenseManager и запрашивать lease.

Минимальный пример:

using var lease = GetService<ISublicenseManager>()
    .Rent(new AuraShareId("S20260209165639iiQZB0NCruAb"));

lease.WhenChanged()
    .Subscribe(x => Log.Info($"Lease changed: {new { x.IsGranted, x.Status, x.Message, x.LastUpdatedAt }}"));

Рекомендуемый вариант для реактивной подписки - привязать подписку к ExecutionAnchors:

var lease = GetService<ISublicenseManager>()
    .Rent(new AuraShareId("S20260209165639iiQZB0NCruAb"));

lease.WhenChanged()
    .Subscribe(x =>
    {
        if (!x.IsGranted)
        {
            Log.Warn($"Sublicense is not granted yet: {x.Status} / {x.Message}");
            return;
        }

        Log.Info("Sublicense granted, pack can continue working");
    })
    .AddTo(ExecutionAnchors);

Что здесь важно:

• Rent(...) не блокирует выполнение и возвращает объект сразу
• первое состояние обычно Pending
• дальше EyeAuras сам в фоне обновляет лицензию
• когда что-то меняется, срабатывает WhenChanged()
• доступ считается выданным только когда lease.IsGranted == true
• сам lease EyeAuras уже привязывает к жизненному циклу скрипта, а .AddTo(ExecutionAnchors) выше нужен именно для вашей подписки

Практические правила

1. Держите lease живым, пока нужен доступ

Один lease = одна логическая сессия.

Если вы освободили lease, то сессия считается завершенной. Когда скрипт или пак завершается, EyeAuras тоже освободит такие сессии автоматически.

2. Не принимайте решение только по факту вызова Rent(...)

Сам по себе вызов Rent(...) еще не означает, что доступ уже получен.

Правильная проверка - это lease.IsGranted и, при необходимости, lease.Status / lease.Message.

3. Если вам нужно несколько сессий - создавайте несколько lease

Каждый вызов Rent(...) - это отдельная сессия.

4. Старый ILicenseAccessor.ShareSublicenses больше не используйте как основной способ

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

5. Semi-Offline, дисконнекты и краши

Текущая модель лицензирования старается быть максимально дружелюбной к пользователю.

EyeAuras не требует, чтобы пользователь терял доступ к паку при каждом кратком дисконнекте, реконнекте или перезапуске клиента.

Как это работает на практике:

• lease выдается не "навсегда", а на ограниченное время
• пока действует подписанная оффлайн-лицензия, клиент может продолжать использовать уже выданный доступ
• если интернет временно пропал, EyeAuras не должен сразу останавливать работу пака
• когда соединение возвращается, EyeAuras синхронизирует состояние снова

Отдельно важный случай - краш.

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

За счет Semi-Offline режима и кэшированной подписанной лицензии EyeAuras старается восстановить уже выданный доступ после перезапуска и продолжать работу, пока эта оффлайн-лицензия еще валидна.

То есть ожидаемое поведение такое:

• произошел краш
• пользователь перезапускает EyeAuras
• пак снова запрашивает lease
• если есть еще валидное кэшированное разрешение, работа продолжается
• когда клиент снова полноценно синхронизируется с сервером, состояние выравнивается окончательно

Важно понимать границы этого режима:

• это не полный offline
• это именно Semi-Offline, то есть "пережить временные проблемы с сетью, рестарты и краши без лишней боли"
• новый доступ с нуля без подходящего кэша может не появиться до следующей успешной синхронизации с сервером

Защита и упаковка

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

Рекомендуемый набор настроек такой:

• PackDistributionPolicy = PackedOnly
• PackScriptCompilationMode = BinariesOnly
• PackScriptProtectionMode = PerformanceFirst или SecurityFirst

Что это дает:

• PackedOnly - пользователю отдается только запакованная версия пака
• BinariesOnly - текст скриптов не распространяется, остаются только бинарники
• PerformanceFirst / SecurityFirst - поверх этого добавляется защита и обфускация

В сумме это делает код с проверкой лицензий заметно менее доступным для изучения и вмешательства.

Подробности есть в статье Защита C# скриптов.

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

И все же стоит помнить: даже при хорошем паковании и защите самый безопасный вариант - это полностью кастомный UI и mini-app подход.

Если это не mini-app, а обычный пак

Не каждый платный продукт обязан быть полноценным mini-app с большим количеством кода.

Бывает и так, что основной функционал почти полностью собран из:

• аур
• макросов
• behavior tree
• стандартных действий и триггеров

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

Есть два практичных варианта.

Вариант 1. Через отдельную ауру IsAuthenticated

Самый простой путь - завести отдельную ауру, например IsAuthenticated, и держать в ней Fixed Value Trigger.

Дальше ваш скрипт отслеживает состояние lease и при изменениях просто включает или выключает эту ауру.

После этого весь остальной пак можно завязать на обычные механизмы EyeAuras:

• AuraIsActive
• Enabling Condition
• линки между аурами

То есть лицензирование остается в одном маленьком скрипте, а вся остальная автоматизация по сути работает как раньше.

Если нужно найти нужную ауру из кода, используйте подход отсюда: Как найти ауру

Вариант 2. Через переменные

Если вам удобнее, состояние авторизации можно хранить не в отдельной ауре, а в переменной.

Идея та же самая:

• скрипт арендует саблицензию
• при изменении lease обновляет переменную вроде isAuthenticated
• остальные части пака читают это состояние и принимают решение, работать им или нет

Подробнее про этот подход здесь: Переменные

Если продаете код - скрывайте его

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

F.A.Q.

Я автор пака и хочу использовать саблицензии

Сейчас ничего отдельно "включать" не нужно.

Пока идет альфа, выпуск ключей все еще через меня, так что просто пишите мне.

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

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

Где продавать ключи

Где угодно. EyeAuras не ограничивает вас в канале продаж.

Самые частые варианты:

• Discord / Telegram вручную
• FunPay / Plati.ru
• собственный сайт

Нужна ли пользователю отдельная лицензия на сам EyeAuras

Нет. EyeAuras теперь бесплатен.

Пользователь оплачивает только ваш продукт, если вы решили продавать доступ к нему через саблицензии.

Можно ли изменить правила у уже выпущенных ключей

Нет, не задним числом.

Новые настройки влияют только на новые ключи. Уже выпущенные должны оставаться такими, какими были в момент покупки.

Что означает статус Pending

Это значит, что EyeAuras уже запросил доступ, но фоновое обновление лицензии еще не завершилось.

Обычно это нормальное промежуточное состояние при старте.

Что будет при дисконнекте или краше

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

Если произошел краткий дисконнект, EyeAuras постарается продолжить работу на уже полученной подписанной лицензии и потом пересинхронизироваться с сервером.

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

Но важно: это Semi-Offline, а не полный offline. Если подходящего кэша нет, новый доступ придется дождаться от сервера.

Нужно ли обновлять старые паки

Да, если вы хотите, чтобы они надежно работали на новых версиях EyeAuras.

Если пак продолжает проверять доступ старым способом и никогда не вызывает ISublicenseManager.Rent(...), пользователь с купленным ключом может не получить доступ на новых клиентах.