Nick Sdk

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

Вот по вашему примеру будет примерно так

function observeAndClickElement() {
  const targetSelector = '.f5-notifier-notification-action_btn';
  const observer = new MutationObserver((mutationsList) => {
    for (let mutation of mutationsList) {
      if (mutation.type === 'childList') {
        const notificationButton = document.querySelector(targetSelector);
        if (notificationButton) {
          notificationButton.click();
          console.log("Кнопка в уведомлении была нажата");
        }
      }
    }
  );


observer.observe(document.body,  childList: true, subtree: true );
observeAndClickElement();

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

Такой подход должен работать гораздо быстрее

По двору прошелся жулик и попытался хакнуть эксплойтом для "майбаха" (условно) все тачки в вашем дворе. Майбахов не нашлось, этот жулик пошел дальше и забыл уже про ваш дворик.

Надо ли защищаться от атаки, не релевантной вашему сетапу? Не надо.
Надо ли делать выводы об уязвимости того или иного оборудования? Надо.
Надо ли проверять свои конфигурации на эксплойты? Надо.
Надо ли реагировать на всякую нерелевантную хрень в логах с ошибками порядка 400? Не надо.
Надо ли позаботиться об оркестрации быстрого развёртывания ваших серверов на случай взломов или проблем с железом? Конечно надо!

Вообще, если ваш сетап на виртуальных машинах в повторяемой среде и с декларативной конфигурацией вроде кубера или докера, то вы легче сможете пережить всякие такие факапы.
Схема такая.
Есть признаки взлома - бэкап логов, снапшот базы, бэкап стораджа, остановка сервисов (если позволяет продакшн), анализ атаки и последствий. Устраняем уязвимость по вектору атаки (гугление по логам и курение тредов), правим конфиги развёртывания и запускаем прод. Потом долго и тщательно разбираемся по логам, снапшотам и бэкапам что затронуто. Делаем тестовый чистый сетап по старой конфигурации и сравниваем пофайлово с атакованной системой, выясняем в какие места вмешались злодеи. Дифаем базу и смотрим на подозрительные различия. Делаем выводы, объявляем об утекших данных, если есть такие признаки (чтобы не подставлять пользователей), принимаем превентивные меры против похожих векторов атак.

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

Это взгляд дилетанта по безопасности, если чего пропустил -- поправьте. Если где не прав -- расскажите.

SELECT `item_id`, ... 
FROM `items_table` AS t1
LEFT JOIN `shown_table` AS t2 on t1.`item_id`=t2.`shown_id`
WHERE [сложное условие для поиска] 
AND  t2.`user_id`=$user_id AND t2.`item_id` IS NULL
LIMIT 1;

Имхо, обычные способы бана по телефону бесполезны. Просто очень хорошо знаком с работой досок «изнутри» и с методами работы этих самых «некоторых товарищей».

Вот что эти товарищи будут делать, когда увидят сообщение «объявление не размещено, т.к. ваш номер телефона забанен на нашем сайте!»? Да они тупо возьмут другой номер и запостят своё объявление. И так до следующего раза.

На одном из своих проектов я решил проблему по-другому. Задача такая: максимально достоверно опознать «нехорошего человека».

Что я для этого делаю?

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

1. ставлю ему бессрочные Cookie с меткой что данный пользователь — тот ещё петрушка;
2. также запоминаю в базе максимальное количество идентифицирующих его данных (IP, юзер агент браузера и т.д.);
3. его объявление сохраняю в базе и помечаю его как «полускрытое». Это значит, что объявление видно исключительно ему, для него создаётся видимость, будто всё прошло успешно и объявление опубликовано. На самом же деле, всем остальным пользователям сайта оно не показывается (в том числе незалогиненным);
4. если «нехороший человек» догадался, что я его обманул и теперь он вбивает очередной свой шлак, то, используя пункты 1 и 2 я снова его определяю, заношу в чёрный список уже новый номер, повторяю по новой пукнты 1 и 2.

В результате все «редиски» смотрят на мой сайт довольные, думают что я нормально опубликовал их объявления, не пытаются всеми возможными и невозможными способами обойти защиту (поскольку они подумали, что они её обошли), а в действительности сайт остаётся чистым.

Когда не знаете хоткей, его всегда можно подсмотреть в меню или в настройках

Под винду нужен PhpStormProtocol

Думаю, и так все понятно:


А за неумение гуглить, я бы руки отрывал...
https://intellij-support.jetbrains.com/hc/en-us/co...

Подсветка не странная. Так отображаются файлы, исключенные из проекта. Либо через меню самого шторма, либо в файле гитигнор.
Как видно у вас весь проект исключен.
Либо нечаянно. Либо глюк.
Можно убрать из excluded правой кнопкой по папке



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

Удалить таблицу main - за полной её ненадобностью и бессмысленностью. Вместо неё создать представление на основе остальных двух таблиц,