Строки с запрещенными словами для логина из слитых данных Твича
Эти ники доступны только для админов)
Прикольно быть админом твича. Если кто тебе слово поперёк скажет, бан за розжиг.
> Прикольно быть админом твича. Если кто тебе слово поперёк скажет, бан
так точнее
так точнее
Здесь пугает скорее то, что походу это какое то многоступенчатое условие в лучших традициях индусского кода, а не какой нибудь json с данными.
не верю что у них не проверка в цикле по данным из таблицы. это же при каждом обновлении списка код переписывать вместо добавления строки в таблицу.
да и строки странно выглядят - "ice____wallow" не пройдёт, но "ice_wallow" это уже совсем другая строка и спокойно проходит. хотя вообще хз как там функция LIKE прописана...
да и строки странно выглядят - "ice____wallow" не пройдёт, но "ice_wallow" это уже совсем другая строка и спокойно проходит. хотя вообще хз как там функция LIKE прописана...
Возможно валидация таким образом сделана, что ничего нового не всунуть, и на фронте только с костылями. Но действительно, как то странно что именно в SQL запросе, хардкодом список размещен, когда куда логичнее сделать это функцией и данные тянуть с какого-нибудь массива
Почему это "логичнее"? Я уверен, что с точки зрения производительности функция на лайках с массивом будет тупее самого кривого кешированного скл запроса
По какому условию? Джой с LIKE в условии будет печально работать (если вообще будет).
По уму надо сначала чистить логин (ну т.е. приводить к одному регистру все буквы, убирать _ и
пробелы, заменять 1 на i), а потом считать расстояние Левенштейна между введенным логином и всеми логинами из базы запрещенных логинов.
Ну и делать это на бэкэнде при регистрации нового пользователя или между моментом регистрации и отправкой на почту письма для подтверждения емейла.
По уму надо сначала чистить логин (ну т.е. приводить к одному регистру все буквы, убирать _ и
пробелы, заменять 1 на i), а потом считать расстояние Левенштейна между введенным логином и всеми логинами из базы запрещенных логинов.
Ну и делать это на бэкэнде при регистрации нового пользователя или между моментом регистрации и отправкой на почту письма для подтверждения емейла.
join с like прекрасно работает, производительность не должна быть критичной, так как это выполняется в двух местах:
- на стороне пользователя можно "спокойно" прогрузить json, предварительно отвалидировать и отсылать только уже проверенные данные. Конечно если они решат запретить весь словарь, то отправляемый json будет весить пару Гб, но кажись тогда у платформы проблемы не с валидацией.
- тоже самое дублируется на серверной части. Но так-как регистрация вызывается не особо часто, просадки по этому методу не критичны. Данные из таблицы с "маркерами" вычитываются моментально без лишних локов, в отличии от той же проверки имени на уникальность (вот там намного веселее).
Так что лично я не вижу ни одной причине в этом дерьме из 100500 OR LIKE
- на стороне пользователя можно "спокойно" прогрузить json, предварительно отвалидировать и отсылать только уже проверенные данные. Конечно если они решат запретить весь словарь, то отправляемый json будет весить пару Гб, но кажись тогда у платформы проблемы не с валидацией.
- тоже самое дублируется на серверной части. Но так-как регистрация вызывается не особо часто, просадки по этому методу не критичны. Данные из таблицы с "маркерами" вычитываются моментально без лишних локов, в отличии от той же проверки имени на уникальность (вот там намного веселее).
Так что лично я не вижу ни одной причине в этом дерьме из 100500 OR LIKE
1) Это sql-запрос, очевидно как раз сформированный в цикле.
2) Делать запросы в БД из кода в цикле - это очень хреновая идея.
3) Очевидно, что они просто вносят логины в какой-то чёрный список по мере появления, а не пытаются предусмотреть все возможные варианты на все времена. То есть, да, со всеми этими логинами реально регались юзеры.
2) Делать запросы в БД из кода в цикле - это очень хреновая идея.
3) Очевидно, что они просто вносят логины в какой-то чёрный список по мере появления, а не пытаются предусмотреть все возможные варианты на все времена. То есть, да, со всеми этими логинами реально регались юзеры.
Самый разумный коммент )
Скорее всего так и есть, у них база black_words, может даже txt которую обновляют и небольшой билдер-генератор, который банально через foreach по шаблону генерит SQL запрос, далее уже копипастят в сурс или ложится куда надо.
Скорее всего так и есть, у них база black_words, может даже txt которую обновляют и небольшой билдер-генератор, который банально через foreach по шаблону генерит SQL запрос, далее уже копипастят в сурс или ложится куда надо.
То есть, можно запилить ботоферму, которая будет регистрировать тонны аккаунтов с "оскорбительными" никами - и пусть обосрутся? А сам генератор ников написать - дело 5 минут: набиваем текстовый файл со всякими Ben Dover, а потом втыкаем разделители в разных количествах и вариантах (-, _, =, + и т.д.), даже не обязательно по выражениям, а тупо рандомом.
Как вариант формировать промежуточный запрос. Т.е. иметь таблицу с шаблонами для проверки, одной выборкой сформировать условие для SQL запроса, а потом уже проверить по этому условию. Для ускорения процесса можно вынести в агент и уже где-то отдельно иметь сформированный запрос обновляя его раз в пол-часа. А потом просто выполнять через EXEC или его аналог.
Судя по наличию "ice___wallow" и ""ice___wall" все остальные варианты включая "ice_wallow" перечислены выше.
Была инфа что прогеррам пришлось сделать это потому что ЧЕРНЫЙ СПИСОК запрещенных слов какому-то оскорбленному менеджеру пришелся не по вкусу. Хз насколько это правда, но учитывая то что случилось с Master/Slave, я не буду удивлен
с Master/Slave вообще обидно вышло
Видимо религия таких оскорбленных им не позволяет делать адекватно
Что пришлось сделать? Переименовали просто в blocklist, это конечно ересь та ещё. Но что поделать, такой прогрессивный мир нынче.
https://bugzilla.mozilla.org/show_bug.cgi?id=1571734
https://bugzilla.mozilla.org/show_bug.cgi?id=1571734
не любят на твиче пенсов...
У Semyon всё норм.
А вот чем им Хильтеры не угодили?
А вот чем им Хильтеры не угодили?
А что с Semenом не так?
Ну утрировать не надо, ненавидеть немцев никто не запрещает.
научиться использовать букву ё?
Ну Джшлатт вроде как добился разбана.
что-то неграм там не рады
интересно, можно ли использовать украинскую і вместо английской.
Подписывается на стримера "ледяная стена сперма", и в благодарность стримлер глотает сперму, спасиба, гыгыггяггы вот для того чтобы помешать пранкерам, создают такие списки.
ицевалловкоме. кто такой цевалло?
А кириллические символы там доступны для ввода? А то ж это простейшее решение ещё со времён начала нулевых, только тогда кириллицу в латиницу гнали, чтобы маты пихать.
nigler
Nigel Peter
Я один думаю что проще нейронку обучить? или у них сидит джун и набивает в такое полотно?
И сделает это IRL
Нет, опыт ai dungeon говорит о том что latitude долбаебы, прямым текстом обвинившие своих пользователей в педофили, дискредитировавшие себя, свой продукт и весь жанр и блочащие людей за личные заметки, прикрывая просмотр личных историй борьбой за мораль.
Опыт говорит что AI потом обвиняют в расизме и неправильной настройке. Поэтому есть специальные дисциплины по тому как искорежить веса нейронки чтобы она решала задачи "политкорректно", а не выводила то что лучше не идти в мексиканский ресторан чтобы не травануться.
https://habr.com/ru/company/microsoft/blog/336358/
https://habr.com/ru/company/microsoft/blog/336358/
opposite_to_white
Сделал себе ник White_Pawa, полет нормальный.
Щас быстро неженки абидятся, настучат и твой ник дополнит сии строки, да и сам бан схватишь
давно? судя по коду эта проверка происходит постфактум, возможно, раз в несколько дней, а не в момент создания ника. а ещё, я думаю, там проверяется есть ли хоть одна жалоба, неактивные ники могут себе хоть годами лежать, пока их никто не увидел и не оскорбился.
До этого был ник wh1te_pwr, продержался почти год
А чё там Майк Ястреб делает? Чому он запрещённый?
полным именем писать
...найти там половинку червяка...
верхнюю или нижнюю?
Любая регулярка это дохуя машинного времени. Субдэшный лайк явно быстрее
Чтобы понимать, о чём я.
Регулярка вида "*(?:aaa|aab|bbb|ccc)*", которая нам тут нужна, компилируется в дерево поиска, с которым делается всего один проход по искомой строке.
SQL конструкция типа "like '%aaa%' or like '%aab%' or ..." потребует столько проходов, сколько этих like у нас имеется. Что будет радикально медленнее.
Регулярка вида "*(?:aaa|aab|bbb|ccc)*", которая нам тут нужна, компилируется в дерево поиска, с которым делается всего один проход по искомой строке.
SQL конструкция типа "like '%aaa%' or like '%aab%' or ..." потребует столько проходов, сколько этих like у нас имеется. Что будет радикально медленнее.
Мне кажется делегировать проверку на СУБД вообще не самая светлая мысль. Как минимум можно в синглтоновский сервис вычитать список, и дальше уже работать из памяти. Менятся это дело будет явно не часто, тупо скармливаем значение и ожидаем на выходе true/false. Ну это конечно если архитектура приложения не подразумевает исключительно прослойку между интерфейсом api и вызовами SP.
А уже на уровне кода можно развлекаться любыми средствами для оптимизации.
А уже на уровне кода можно развлекаться любыми средствами для оптимизации.
Вполне вероятно там какой-нибудь построитель запросов.
Где передаётся список запрещённых слов.
В итоге работает примерно по следующему принципу:
Condition cond = new OrCondition();
for (String bannedWord : bannedWords)
{
cond.addCondition(new LikeCondition(bannedWord));
}
return cond;
Где передаётся список запрещённых слов.
В итоге работает примерно по следующему принципу:
Condition cond = new OrCondition();
for (String bannedWord : bannedWords)
{
cond.addCondition(new LikeCondition(bannedWord));
}
return cond;
нет по человечески там ) #troll
$banned_words_array = file ('bases/banned_words.txt');
foreach ($banned_words_array as $banned_word)
{
$sql_data = $sql_str . "OR ue.login LIKE '% ". trim ($banned_word). "%'" ."\n";
}
file_put_contents ('sql_queries/banned_words_sql.txt', $sql_data);
$banned_words_array = file ('bases/banned_words.txt');
foreach ($banned_words_array as $banned_word)
{
$sql_data = $sql_str . "OR ue.login LIKE '% ". trim ($banned_word). "%'" ."\n";
}
file_put_contents ('sql_queries/banned_words_sql.txt', $sql_data);
на 64,7%.
а почему вы интересуетесь?
а почему вы интересуетесь?
Нахер я это глянул?! Как? КАКСУКАБЛЯТЬНАХУЙ!!!!! Даже я 5 лет назад (если не больше), когда пытался влепить фильтр в свой 10 строчный проект, и то блядь додумался сделать парсер ника на выпиливание пробелов-подчеркиванией-дефисов и формирования "хеша" приводя цифры-буквы-комбинации к единому формату. И эти же идиоты лепят идиотские мат-фильтры, которые резут по самой примитивной маске, тем самым превращая обычный текст в гребаные ребусы из звездочек.
я не спец в SQL, но, может там нет регулярок и выпиливаний пробелов...
Есть там регулярок. В энтот самый like, что на картинке, вполне можно регулярку пихать.
теперь бы придумать одну регулярку, которая проверяла разные варианты написания одновременно ниггера, гитлера и глотающих
Да заебали. На любом собеседовании: паттерны, подходы, СОЛИД, бест практисы. А на сливы кода посмотришь, так везде ифов напихают и сидят, радуются. Про проекты самих собеседователей я вообще молчу. "Да это легаси. Серега это написал, но он уже уволился". Ебучий Серега.
Тесты? Ну да, наверное, дело хорошее. Но на них время нужно, а релиз завтра. Пусть как-нибудь будем писать. Когда перепишем приложение.
и вообще, он это ещё на визуал бейсике писал, мы потом нашли конвертор кода в питон, но он кривой был, то прогнали сначала в лисп, а потом уже лисп в питон...
Классика:
На реальном проде это будет результат работы какого-нибудь конструктора хранимых процедур на вебформах. Процедуры эти явно тягаются редко и в основном сидят в глубоком кэше, так что на первом месте удобство оператора и скорость реализации. Что об этом думает кудахтыч с джойреактора, кажется, никого не ебет
Токенизируем ник пользователя и дубасим в эластику, где хранятся плохие слова. Но да, реляционная база данных для хранения списков, разумеется, куда лучше.
Отличный комментарий!