Плагин [GEN] rscPermissions v0.10.x — идеальный менеджер прав для мультисерверных сред [1.2.5 - 1.10.x]

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

spigotmc.org | Исходный код | Скачать | FAQ​

Основные возможности.

• Работает на серверах, начиная с очень старых версий (скорее всего, даже на версии 1.2.5) до самых последних!
  
• Использование одного СУБД MySQL для хранения прав игроков со многих игровых серверов; интуитивно понятная структура таблиц (проще, чем у PermissionsEx). Можно удалённый — плагин нагрузки не создаёт. Плагин регулярно сам перечитывает данные из базы.
• Использование ников, uuid-ов и ip-адресов (все они в том числе с wildcard-подстановками!) для обозначения игроков.
• Условная выдача прав и групп игрокам в зависимости от числа уровней опыта, названия сервера (поле server-id в файле server.properties), мира, регионов WorldGuard.
• Права и группы могут могут быть выданы на определённый срок (до указанных даты/времени).
  
• Множественное приоритетное наследование групп другими группами и игроками. Порядок сортировки при множественном наследовании предопределён: сперва по колонке приоритета (1–∞), затем по алфавиту.
• Наследование абстрактных групп (или «прототипирование»): назначьте «абстрактное» право herochat.speak.? группе Citizens и добавьте игрока в группу Citizens.MyTown. Игрок в ходе разрешения дерева наследования получит право писать в канал MyTown (потому что он получит право herochat.speak.MyTown). Для наследования групп это тоже работает.
• Вычисляемые префиксы и суффиксы групп и игроков.
• Опциональная интерпретация права * (звёздочка) как статуса оператора сервера.
  
• Настраиваемые режимы обслуживания сервера — блокируйте зевак, пока строите карту!
• Настраиваемые лимиты свободных слотов — зарезервируйте слоты для важных игроков!
• Совместимость с Vault (самостоятельная интеграция в него) и WEPIF (самостоятельная интеграция в него).
• Переведён на русский и английский языки, можно создавать свои переводы.

Расположение (destination) включает в себя три опциональных поля: название региона (WorldGuard, Residence, в будущем будет поддержка других плагинов), название мира и имя сервера (значение server-id из файла server.properties). Допускается использование подстановочных знаков ? (инстантиатор прототипа группы) и * (wildcard). Элементы вводятся в следующем виде: [регион:]мир[@сервер] (без квадратных скобок), пустое или не введённое значение приравнивается к *.

Файл конфигурации.
Описание всех возможных пунктов конфигурации в файле config.yml перенесено из этой темы прямо в исходный код (на английском и русском языках).

• Посмотреть файл config.yml с комментариями на GitHub.

Список команд.
Команды для работы с базой прав:

• Расширенная инструкция, часть 1.
• Расширенная инструкция, часть 2.
• /rscp user|group <название> ap|ag <цель> [параметры] — добавить пользователю или группе новое право либо новую родительскую группу. Опциональные параметры:
  destination <местоположение> — добавляемое право/группа будет действовать только в определённом месте.
• /rscp user|group <название> rp|rg <цель> — удалить у пользователя или группы имеющееся право или родительскую группу.
• /rscp player <игрок> lp — (list permissions) показать все права, которыми обладает игрок.
• /rscp player <игрок> lg — (list groups) показать дерево групп, которым принадлежит игрок.
  
• /rscp player <игрок> p — показать префикс игрока.
  
• /rscp player <игрок> s — показать суффикс игрока.

Другие команды административного назначения:

• /rscp lock [название режима обслуживания] — включить режим обслуживания default или указанный. Только игроки, имеющие право rscp.maintenance.<название> (или rscp.maintenance.*) смогут зайти на сервер!
  
• /rscp unlock — выключить режим обслуживания.
• /rscp debug [значение|toggle] — включить/выключить вывод отладочной информации. Команда работает по-разному для игроков и для консоли.
• /rscp fetch — немедленно полностью перечитать данные из БД в локальный кэш и запустить пересчёт деревьев прав для всех игроков.
  
• /rscp reload — перечитать конфигурацию (config.yml) и перезапустить плагин.
  
• /rscp update [do] — проверить наличие обновлений / запустить автоматическое обновление.
• /rscp help — справка по статусу сервера и доступным игроку командам.

Команды, которые не поддерживаются и, вероятно, будут удалены:

• /rscp examplerows — вставить в БД какие-то строки с примерами.
  Устарело. Используйте на свой страх и риск.
• /rscp import pex-sql — импортировать строки из БД PermissionsEx (без префиксов).
  Устарело. Используйте на свой страх и риск.

Собственные права плагина.

• rscp.admin — полный доступ ко всем командам и возможностям плагина.
• rscp.admin.reload — позволяет перезагружать плагин (перечитывая конфигурацию и обновляя кэш данных из БД).
  
• rscp.admin.lock — позволяет включать и выключать режимы обслуживания на сервере.
• rscp.maintenance.<название режима> — позволяет подключиться на сервер, когда на нём включён определённый режим обслуживания.
• rscp.maintenance.* — позволяет подключаться на сервер вне зависимости от того, какой режим обслуживания задействован.
• rscp.limits.<название ограничения> — позволяет подключиться на сервер, когда количество оставшихся свободных слотов попадает под ограничение соответствующего лимита.
• rscp.limits.* — позволяет полностью игнорировать все имеющиеся ограничения по количеству свободных слотов.

Функция лимитированного входа.
Предположим на сервере открыто 100 слотов. Плагин по умолчанию устанавливает два лимита: premium = 20 (соответствующее право rscp.limits.premium) и administrators = 5 (rscp.limits.administrators). Игроки, которые не имеют ни одного из этих прав, могут заходить на сервер, пока есть 100 - max(limits) слотов, то есть 80 человек. После этого на сервер смогут заходить только премиум-игроки, до тех пор, пока не останется только 5 слотов — дальше только администраторы. Если игрок имеет одно право на вход с меньшим числом свободных слотов, то это автоматически позволяет ему игнорировать лимиты, рассчитанные на менее привилегированных игроков.

История изменений:

• 0.9.20b: Разрешены wildcard-ы в поле entity (во всех таблицах) — например, «Guest_*» или «192.169.*.*». Это, с одной стороны, позволяет как-то выделить игроков, ник или uuid у которых генерируется автоматически, а с другой стороны наконец-то реализует функцию опознавания игроков по IP-адресам!
  Страница плагина на dev.bukkit.org более не поддерживается.
• 0.9.18b: режимы обслуживания имеют настраиваемые сообщения в config.yml (motd / kick тех, кто онлайн / сообщение о невозможности входа), в тексте можно использовать {MMODE} для вставки названия текущего режима. Переведены большинство строк в /rscp help, блокировка от slot-limits. Автообновление конфигурации до версии 4. Добавлена настройка, позволяющая группам не наследовать автоматически родительские префиксы. Не-положительные значения slot-limits игнорируются.
• 0.9.17b: исправления багов, неточности в переводе.
• 0.9.16b: поддержка WEPIF, отключаемая автоперезагрузка прав из БД, улучшения в обработке лимитированных слотов, улучшение отладочного вывода, исправления ошибок.
• История изменений начата заново с представлением сборки версии 0.9.11b. Описание в этом посту является всегда актуальным для самой последней версии.

Ограничения.

• Плагин предоставляет собственные реализации таких популярных интерфейсов для взаимодействия между плагинами, как Vault и WEPIF, однако ограничивает возможности использования их методов для редактирования прав. Полноценно работают все те методы, которые направленны на получение от плагина информации об игроках и группах.
  Исключение составляют методы установки префиксов и суффиксов — указанные интерфейсы допускают изменение этих параметров для игроков и групп.
  
• По умолчанию плагин настроен на интерпретацию права «*» как режим оператора сервера. Все игроки, которые не имеют данное право, автоматически лишаются данного статуса. Это свойство вкупе с невозможностью из игры назначить игрокам группы/права часто может иметь решающую роль для противодействия взлому сервера злоумышленниками.

Если Вы имеете опыт программирования на Java (а ещё лучше — разработки плагинов) и желание помочь мне в написании кода, я буду очень рад.

Послесловие.
Для удобного редактирования таблиц БД предлагаю использовать MySQL Workbench или phpMyAdmin (на самом деле его уже не советую, он глупый), а также призываю разработчиков Личных кабинетов к интеграции со структурой БД плагина. Для работы требуется Java 7 или более новая.

Если у вас возникли проблемы или вопросы, прочитайте FAQ, а если и там нет нужного ответа, то просто спросите ниже .

 

Ты таки запостил это здесь)

 

Frequintly Asked Questions / Часто задаваемые вопросы​

Вопрос: — При заходе на сервер игрок не появляется в базе. Почему? Как мне добавить его самому?
Ответ: — Следуя своей философии, плагин не считает необходимым знать явно о всех игроках — в базу данных игрока стоит добавлять только тогда, когда его игровая группа отличается от группы по умолчанию. Например, если Вы продали игроку группу VIP, то просто добавьте в таблицу inheritance строку с игроком и родительской группой VIP. Если выставить значение в lifetime (точка во времени, до которой должна существовать эта запись) — после истечения срока запись будет полностью удалена из БД и игрок будет снова неявно принадлежать группе по умолчанию. Это один из способов поддерживать минимальность записей в БД для удобства её администрирования.

Вопрос: — Я добавил игрока в группу VIP, следует ли мне самому прописать этой группе права группы Default?
Ответ: — Существует несколько путей, но в любом случае права прописывать не нужно. Плагин имеет настраиваемую опцию settings.always-inherit-default-group (по умолчанию true). Если она включена, то это означает, что все игроки, явно принадлежащие любым группам, будут сперва наследовать и группу по умолчанию. Если она выключена, то вместо прописывания аналогичных прав корректным решением с Вашей стороны будет наследовать группу VIP от группы по умолчанию (используя таблицу inheritance). Кстати говоря, группа по умолчанию не имеет какого-то предопределённого постоянного значения (я имею ввиду названия), её всегда можно изменить с Default на что-то другое в опции плагина settings.default-group.

Вопрос: — Как дать разные права игроку на разных серверах?
Ответ: — Таблицы permissions и inheritance имеют колонку destination, которая отвечает за "географическое" условие применения данной строки БД к рассматриваемому игроку. Значение в колонке может быть пустой строкой — это означает применимость "везде". На самом деле формат её значения таков: [регион:][мир][@сервер], то есть состоит из трёх опциональных элементов: регион, мир, сервер (квадратные скобки в данном формате записи лишь означают необязательность элемента, содержащегося в них, сами они в тексте не вставляются!). Обратите внимание, что после названия региона должно идти двоеточие, а перед названием сервера — символ @. Сперва необходимо задать разным серверам разные названия — за это отвечает поле server-id в файле server.properties. После этого можно добавлять две записи в таблицу inheritance: у первой указать в колонке destination "@Server1", у второй — "@Server2".
Если требуется использовать другую группу для большинства игроков на отдельном сервере, то есть резон поменять на этом сервере название группы по умолчанию на требуемое в config.yml этого сервера.

Вопрос: — Я хочу указать игроку группу Moderators на нескольких серверах, но не на всех. Добавлять для каждого сервера новую строку? У меня их много...
Ответ: — Если требуется создать множество записей, которые отличаются только значением колонки destination, то существует возможность избежать этого, записав всего лишь одну строку: в колонке destination разделите несколько значений при помощи одного или нескольких следующих символов: пробел, табуляция (\t), запятая, точка с запятой, возврат каретки (\r), перенос строки (\n). Плагин будет реагировать на такие единичные записи как на множество.

Вопрос: — А если мне нужно записать несколько игроков в одну группу или назначить нескольких игрокам одно и тоже право?
Ответ: — Аналогично предыдущему вопросу: имеется возможность записать в колонку entity (применимо к любой из таблиц) несколько значений, разделённых теми же самыми разделителями. К слову, этот механизм также применим к колонке permission в таблице permissions и к колонке parent таблицы inheritance.

Вопрос: — Если я введу зависимость права или группы игрока от названия региона, не будет ли это тормозить сервер?
Ответ: — Если коротко, то нет. Пересчёт прав (не путайте с перечитыванием данных из БД) для каждого игрока происходит каждый раз, когда для него меняется список регионов, в которых он находится. Это справедливо для всех игроков, которые есть на сервере, все зависимости от того, существуют ли для них region-based права или нет. Пересчёт происходит в параллельном потоке, и запускается через какое-то фиксированное время (настраивается, по умолчанию 1 секунда). Только после перерасчёта в основной игровой цикл помещается вызов небольшого куска кода, который заменяет для игрока старый список прав на уже перерасчитанный новый. Единственное, что стоит учитывать, что параллельный поток использует асинхронную очередь для всех игроков, которых нужно пересчитать, и если игроков очень много, и, соответственно, для какого-то конкретного игрока после входа его в регион с дополнительными правами эти новые права могут прийти к нему с небольшой задержкой (порядка менее или нескольких секунд).

Вопрос: — У меня есть Личный кабинет, он заносит купленные привилегии (группы и права) для игроков в БД. Как мне заставить плагин воспринять их? Использовать такие устаревшие костыли, как WebSend?
Ответ: — В этом нет необходимости! Плагин регулярно перечитывает БД по заданному интервалу (по умолчанию равен 15 минутам). При желании можно смело уменьшать это значение, но лично я не вижу большого смысла в значениях ниже 3-5 минут — ведь привилегии обычно выдаются на недели и месяцы, и даже 15 минут тут несравнимо малая величина.

Вопрос: — Как пользоваться резервацией слотов?
Ответ: — Очень просто! Давайте рассмотрим ситуацию, когда конфиг плагина был создан со значениями по умолчанию. Имеется два лимита, названные administrators и premium, выставленные в значения 5 и 20 соответственно. Предположим, что на сервере число слотов равно 100.

Спойлер: Пояснение картинкой

Стоит отметить, что premium и administrators — это не названия групп или чего-либо ещё, это просто названия значений ограничителей. Эти названия подставляются в пермишен rscp.limits.<название> и выдаются нужным Вам игрокам. К слову, если игрок имеет лимит на вход при меньшем числе свободных слотов, то он автоматически получает и все "более слабые" лимиты.

Вопрос: — Вопрос?
Ответ: — Ответ!

Наверх​

 

Мало было Стасу геморроя, запостил Стас свой плагин на руведре.
Видел его на бакките, а вот и тут всплыл. Молодец, что. :3

 

А как воспользоваться конвентером?

 

Да получилось, и еще вопрос, есть ли документация плагина на русском языке?

 

1 вопрос, что посоветуешь поставить на плагин чата для взятия префиксов и тд из rscPermissions

 

ПермишнсЕкс должен быть настроен на мускл, и ту же самую бд, что и рскп. Потом команда /rscp import pex-sql, вроде так

Не особенно, но я попытаюсь собрать вопросы с этой темы в некий faq, когда наберется несколько.

Решил осваивать и родные просторы, в дополнение к буржуйским =)

У меня немного опыта в чатах, я всегда пользовался Herochat, и с ним никаких проблем. Всё работает через поддержку Vault.

 

А можешь сделать lifetime для префиксов? Очень полезная штука бы была.

 

А как быть, если игрок хочет определенный префикс?

 

Что там на счет lifetime для префиксов?

 

Колонку я добавлю) Хорошо, спс

 

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

Я сейчас работают над значительным переписыванием внутрянки, чтобы поддерживать на 100% последний VaultAPI, последний WG и дать собственное красивое внешнее API. Так что такое в будущем возможно, но пока обещать не могу — смотря насколько это впишется в минималистичность дизайна БД.

Если для одного игрока надо сделать один конкретный префикс на определённое время, то, например:

• Добавить строку в таблицу entities:
  • entity = его ник/uuid/другое уникальное сочетание символов.
  • entity_type = 0 (префикс/суффикс устанавливаются для группы)
  • Выставить нужные ему prefix и suffix
• Добавить строку в таблицу inheritance:
  • entity = его ник/uuid
  • parent = его ник/uuid/другое уникальное сочетание символов.
  • child_type = 1 (игрок наследует группу)
    
  • lifetime = конец необходимого срока

Конечно, не очень изящное решение, т.к. сразу бросаются в глаза два минуса:

• Две строки для одного игрока — излишество, контрастирующее с моей идеологией минимума строк в БД.
• После истечения срока действия строка в таблице inheritance будет удалена, тогда как строка в таблице entities останется. Накопление мусора также не мой стиль.

Я действительно сейчас больше склоняюсь к варианту "добавить колонку lifetime в таблицу entities", но пока это не сделано по факту, я не могу обещать это в будущем на 100%.

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

Код:

ALTER TABLE `{ТВОЯ_БД}`.`rscp_entities` ADD COLUMN `lifetime` TIMESTAMP NULL DEFAULT NULL AFTER `suffix`;

Это не будет публичный релиз, чисто рабочий dev для тебя.

Лови.

P.S. На самом деле ты мог сделать это давно сам. Добавить упомянутую выше колонку и отредактировать внутри плагина файл /sqlt/Cleanup_tables.sqlt, изменив условие очистки entities-таблицы таким образом:

Код:

WHERE ((`prefix` = '' OR `prefix` IS NULL) AND (`suffix` = '' OR `suffix` IS NULL)) OR `lifetime` < CURRENT_TIMESTAMP;

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

 

Большое спасибо, а плагин можно как-то подружить с ChatManager? HeroChat слишком навороченный.

 

Префиксы и суффиксы я всего лишь реализую на основе интерфейсного класса Chat внутри Vault. Теоретически, любой чат-менеджер, который умеет работать с ними через Vault, должен их получать и показывать. Никакой конкретной зависимости от HeroChat у меня нет, работает всё само по себе. Просто я не сталкивался с другими.

Возможно в течение следующей недели я закончу работу над очень большим обновлением, где будет 100% поддержка последних версий Vault (там, где они вынесли VaultAPI отдельно) и другие плюшки. не могу точно сказать, как поведёт себя связка из последних версий Vault/rscp/ChatManager. Эксперимент покажет...

 

Автор, есть небольшая проблема, пермы работают так же хорошо как и PEX, но при входе на сервер в в базе не наблюдается добавление нового пользователя, и приходится для смены группы самому добавлять строку (у меня это делает скрипт в кабинете при первой авторизации там или при отсутствии этого поля). Если есть где-то настройка этого, прошу напиши.

 

DimaTiunov, пользователи, входящие впервые на сервер, действительно не заносятся в БД. Я с самого начала задумывания плагина решил, чтобы следовать принципу "минимализации числа строк". Для того, чтобы игрок или группа существовали, нет необходимости следовать правилу и заносить названия куда-либо. Достаточно прописать в любую из таблиц/соотв.колонок игрока или группу, и плагин автоматически знает, что нужно делать.

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

Мне кажется, что

— вполне нормальный вариант. Кстати, ведь нет смысла убирать группу по-умолчанию для того, чтобы добавить какую-то ВИП-группу? Пусть игрок наследует их обе, и не важно, если сама VIP наследует Default (плагин использует Set<String, Boolean>, чтобы устранить все дубликаты прав, последнее по приоритету значение перекроет собой старые).

Возможно, тебе будет интересно почитать про конструкции INSERT IGNORE и INSERT ... ON DUPLICATE KEY UPDATE. Прикрепил скрин с уникальным ключём, который использует плагин для определения дубликатов.

 

Спасибо за развёрнутый ответ. Ещё вопрос по поводу "моментального добавления прав", как правильно настроить всё при том чтобы не вызывало лаги?

 

Если я правильно тебя понял, то всё происходит так:
Ты заносишь в БД необходимую тебе строку. Плагин регулярно по заданному в конфиге интервалу (settings.auto-reload-delay-sec, равен по умолчанию 900 сек = 15 мин) перечитывает полностью все таблицы. Между этими интервалами данные хранятся в "локальном кэше прав". Процесс перечитывания БД заменяет локальный кэш на перерасчитанный новый. Я не замерял его вклад в задержку сервера, т.к. не имею серверов с очень большим онлайном, но на 50+ игроках никаких лагов я никогда не наблюдал.

На самом деле я думаю, что плагин не должен вызывать лагов ни в каком случае, т.к. я всегда перечитываю БД и обновляю права игрокам в параллельных потоках. Единственным побочным эффектом может быть не очень мгновенное обновление прав игроку если к нему начинает применятся новое наследование групп или прав из-за смены актуальных destination — но речь опять же, на доли/единицы секунд.

С одной стороны можно смело уменьшать таймер перечитывания БД, но с другой 1) будет засрана консоль уведомлениями об этом и 2) вряд ли ты выдаёшь проданные випки на срок в минутах, поэтому простая пометка "Вип может быть активирован с задержкой не более 15 минут" мне кажется уместной.

Если я неправильно понял тебя, поясни свой вопрос

 

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