Нормальная единая бан-система

[CrazyHackGUT]

Добрый вечер всем пользователям.​

Ещё около года назад я проводил небольшой опрос касательно написания нормальной бан системы во всех возможных чатах SourceBans Material Admin (ВК, Telegram, Discord). Решил повторить его, но в этот раз здесь, на форуме.

Сразу опишу, какой я вижу нормальную бан-систему:

• Поддержка GoldSource и Source одновременно. Полноценная поддержка этих обоих движков.
• Объединение понятий "бан" и "мут" в одно целое. Мут - то же самое, что и бан, только на чат. Так почему бы не хранить и баны, и муты в одной таблице? При необходимости можно разделить отображение банов и мутов на две разные страницы для того, чтобы пользователи не путались.
• Мониторинг серверов с кешем. Он не должен "долбить" сервера каждый раз, когда кто-то открывает страницу с ним. Он должен его по крону с некоторой периодичностью "долбить", либо в фоне при открытии страницы пользователями.
• Разные админ-права на разных серверах. Тут без комментариев.
• Полноценная поддержка фичи SM с выдачей нескольких админ-групп одному админу.
• Реализация админ-групп для AMXX. Из коробки AMXX их не имеет, но что мешает нам самим их реализовать? Самая банальная реализация, которую можно сделать - при получении админа из БД и его групп, так же запрашивать админ-флаги, которые есть у групп.
• Поддержка нескольких локализаций.
• Система шаблонов без захардкоженного HTML-кода в логике, как это сейчас в SB.
• Web API.
• Система аддонов. Для реализации кастомных страниц в бан-систему, вроде вип-листа, добавления настроек и так далее без редактирования файлов движка...

Это не полный список. Вполне вероятно, что я что-то забыл. Но из него уже понятно, что придётся написать:

• Веб-сайт
• Плагин для Source-движка (SourceMod или Source.Python - значения не имеет)
• Плагин для GoldSource-движка (AMX Mod X)

Со стороны плагина, в свою очередь, должно отсутствовать прямое общение с БД. То есть всё через API веб-сайта.

Пишите своё мнение, мысли, идеи в тему.

P.S.:

Я не рассчитывал всё писать в одиночку. Если идея людям зайдёт - будем собирать команду, которая будет этим заниматься помимо меня.
Веб-разработчики (бэк и фронт), скриптеры, проектировщики БД, дизайнеры и т.д..

 

[SergeyShorokhov]

То есть всё через API веб-сайта.

Есть некая сложность. В AMXX нет нормального модуля для работы с запросами.

 

[CrazyHackGUT]

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

 

[serveer_222]

Идея хорошая.Мне зашла.Даю разрешение на разработку)

31 Май 2018

Только еще бы hosting'и поднапряглись и нормальные Web-части себе сделали,было бы вообще здорово)

 

[RockTheStreet]

Даю разрешение на разработку

Никто разрешения и не требует.

 

[81x08]

wopox1337, Может подойдут модули cURL?
Пробовал с ними работать, в принципе не плохо.

 

[fantom]

Одна проблема. Дожен быть только HTTP, а не HTTPS. А так то да. Я давно говорил что мут/гаг это то же самое что и бан. Плюс вместо 100500 запросов к базе можна сделать один запрос на WEB API который отдаст баны/стату/настройки игрока. Также не надо разделять админов и игроков. Админ это тот же самый игрок, но с доп флагами. Ну и главная боль в существующих системах для меня, это структура таблиц, которая не позвоялет крутить данные так, как тебе нужно

 

[ssx]

Разделять нужно по статусу игроков:
К примеру у меня один плагин и к нему подключены многие плагины где вместо проверок на флаги реализован get_user_status(id)

public client_putinserver(user)
{
    if(is_user_hltv(user) || !is_user_connected(user))
        return

    new iFlags = get_user_flags(user);
    who[user] = (is_user_bot(user)) ? 5 : (iFlags & ADMIN_RESERVATION && (iFlags & ADMIN_BAN)) ? 4 : (iFlags & ADMIN_BAN) ? 3 : (iFlags & ADMIN_RESERVATION) ? 2 : is_user_steam(user) ? 1 : 0;
}

Только я тупанул сначало и сделал 4 статуса - забыл ботов.. потом пришлось делать ботам статус 5 .
Лучше конечно:
Bot = 0
Non-Steam = 1
Steam = 2
VIP = 3
ADMIN = 4
VIP+ADMIN = 5

 

[BoecSpecOPs]

Не прокнет единая таблица всех банов? Я предлагаю доработать эту тему и реализовать что нужно по спецификации. Так же я разрабатываю RBAC (role based access control), что может быть полезно при выдаче нескольких "админ-групп" одному админу.

 

[cAh]

А много ли проектов сейчас где есть сервера разных движков?
Подобное уже сделано с помощью GameCMS
А так неплохая идея =)

 

[Minni]

cAh, в GameCMS не очень хорошо реализовано.

 

[BoecSpecOPs]

ssx, а если игрок Steam+VIP/Admin? :/

 

[CrazyHackGUT]

cAh, GameCMS это вообще комбайн. И сделанный причём очень плохо, если смотреть под капот.

 

[SergeyShorokhov]

под капот

этот "под капот" конечному пользователю вовсе не интересен. Главное, что работает, свои функции выполняет.

 

[BoecSpecOPs]

CrazyHackGUT, под капот амхх если смотреть - вообще в дурку записаться можно, но это же не мешает его юзать :/

 

[CrazyHackGUT]

этот "под капот" конечному пользователю вовсе не интересен.

Это пока что-то модифицировать не понадобится. А такое бывало неоднократно...
Причём хрен бы с этим говнокодом. Но ведь часть файлов обфусцирована.

 

[SergeyShorokhov]

у меня было подобное представление более-менее нормальной системы: (накидано за 5 минут в dbdesigner.net)

 

[BoecSpecOPs]

wopox1337, подгоню своих тараканов к этой схеме :3
Вместо таблицы админов - таблица групп и связующая таблица - группа_игрок

 

[CrazyHackGUT]

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

 

[SergeyShorokhov]

Вместо таблицы админов - таблица групп

Спойлер: хз зачем, но код

CREATE TABLE `Players` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `role_id` INT(32) NOT NULL,
    `nickname` varchar(32) NOT NULL,
    `AuthId` varchar(32) NOT NULL UNIQUE,
    `IP` varchar(32) NOT NULL UNIQUE,
    `avg_ping` INT(5) NOT NULL,
    `stay_time` varchar(32) NOT NULL,
    `connects_count` INT(32) NOT NULL,
    `first_joined` TIMESTAMP(32) NOT NULL,
    `last_joined` TIMESTAMP(32) NOT NULL,
    PRIMARY KEY (`id`)
);

CREATE TABLE `Stats` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `player_id` INT NOT NULL UNIQUE,
    `kills` INT NOT NULL,
    `deaths` INT NOT NULL,
    `assists` INT NOT NULL,
    `headshots` INT NOT NULL,
    `teamkills` INT NOT NULL,
    `shots` INT NOT NULL,
    `hits` INT NOT NULL,
    `damage` INT NOT NULL,
    `bomb_defused` INT NOT NULL,
    `bomb_planted` INT NOT NULL,
    `bomb_exploded` INT NOT NULL,
    `bomb_exploded` INT NOT NULL,
    `hostage_rescued` INT NOT NULL,
    `hostage_killed` INT NOT NULL,
    `rounds_played_t` INT NOT NULL,
    `rounds_played_ct` INT NOT NULL,
    `vip_rescued` INT NOT NULL,
    `vip_losed` INT NOT NULL,
    `wins_t` INT NOT NULL,
    `wins_ct` INT NOT NULL,
    PRIMARY KEY (`id`)
);

CREATE TABLE `Gags` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `player_id` INT NOT NULL UNIQUE,
    `admin_id` INT NOT NULL,
    `reason` varchar(64) NOT NULL,
    `created_time` TIMESTAMP NOT NULL,
    `expiry_time` TIMESTAMP NOT NULL,
    PRIMARY KEY (`id`)
);

CREATE TABLE `Mutes` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `players_ids` varchar NOT NULL,
    PRIMARY KEY (`id`)
);

CREATE TABLE `Roles` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `name` varchar(32) NOT NULL UNIQUE,
    `description` varchar(32) NOT NULL UNIQUE,
    `flags` INT NOT NULL UNIQUE,
    `time_available` varchar(32) NOT NULL UNIQUE,
    PRIMARY KEY (`id`)
);

ALTER TABLE `Players` ADD CONSTRAINT `Players_fk0` FOREIGN KEY (`role_id`) REFERENCES `Roles`(`id`);

ALTER TABLE `Stats` ADD CONSTRAINT `Stats_fk0` FOREIGN KEY (`player_id`) REFERENCES `Players`(`id`);

ALTER TABLE `Gags` ADD CONSTRAINT `Gags_fk0` FOREIGN KEY (`player_id`) REFERENCES `Players`(`id`);

ALTER TABLE `Gags` ADD CONSTRAINT `Gags_fk1` FOREIGN KEY (`admin_id`) REFERENCES `Players`(`id`);

ALTER TABLE `Mutes` ADD CONSTRAINT `Mutes_fk0` FOREIGN KEY (`players_ids`) REFERENCES `Players`(`id`);

муты, гаги и баны можно в одной таблице хранить.

зачем всё в одну кучу делать?