После обновления движка SS7 появились сообщения "Магазин войти не удалось"

11 ответов

• популярные
• новые

• 1

  Alex 29 июля 2018 09:36 #

  Нашел схожее сообщение.

  https://support.webasyst.ru/fo...

  Но проблему это не решает же?

  ответить
• 1

  replicant 29 июля 2018 17:18 #

  Рекомендую для начала сделать вот так https://developers.webasyst.ru... и понаблюдать за ситуацией какое-то время. Но, если правильно помню, то при входе в админку будет немного другой лог.
  

  
  Но все равно лучше перепроверить.
  
  Возможно перебирают учетки юзеров.
  

  ответить
  • +2

    Роман 29 июля 2018 21:43 #

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

    такое чувство, что хотят сайт вскрыть

    ответить
    • +1

      Genasyst Партнер-эксперт Партнер-разработчик 29 июля 2018 22:18 #

      Это попытка войти на витрине магазина, это клиенты

      ответить
      • +1

        Syrnik.com Партнер-разработчик 29 июля 2018 23:46 #

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

        ответить
    • +1

      replicant 30 июля 2018 09:08 #

      Это записи из таблицы wa_log о попытках авторизации через frontend например приложения shop. Искать по полю action = login_failed.
      
      Выглядит это так. Там ещё есть логин (он же вроде и email) и IP.
      

      
      
      Меня больше поражает другое. Неужели штатно нельзя было добавить эти подробности из таблицы в ленту событий? Все время какие-то "недомолвки" в этой ленте. Это как с редактированием категорий товаров. В базе инфа есть, а в ленте не выводится. :)
      
      P.S. Если логины одинаковые, то выводится только последняя строка по данному логину. Т.е. механизм проверки в некотором смысле уже есть. Но доработать до финала его видимо никак. Придется допиливать руками самостоятельно.
      

      ответить
    • +1

      Alex 30 июля 2018 09:13 #

      Такая же ситуация.

      Точку входа в админку изменил с переменной и с нестандартной постоянной частью.

      Сайт новый, клиентов всего 10-15.

      Маловероятно, что они круглосуточно пытаются войти на сайт.

      Это какой-то глюк или перебор паролей.

      По логам БД действительно получается перебор паролей для входа в пользовательскую часть.

      ответить
      • +1

        replicant 30 июля 2018 09:19 #

        Загляните в базу в таблицу wa_log. Просто нужно понять что там в неё падает. Подробности видеть надо.
        

        ответить
        • +1

          Alex 30 июля 2018 09:31 #

          Заглянул.

          Видно, что просто перебирают с различными логинами с разных IP адресов.

          Подумал, что можно на форму авторизации поставить ReCapcha.

          Но никак не найду, как ставится. Может знаете как установить на форму входа?

          ответить
          • +1

            replicant 30 июля 2018 11:46 #

            Если клиентов будет много, то слишком мудреная капча на форме авторизации отпугнет и выбесит. Я бы поcмотрел в сторону простейших капч с суммой двух чисел (php или js непринципиально).
            
            Запихивать это (конструкцию формы и проверку правильности) надо в function loginForm в файл /wa-system/view/waViewHelper.class.php.
            

            ответить
• 1

  replicant 30 июля 2018 12:13 #

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

  Закомментируйте строку
  

  $this->logAction('login_failed', $data);

  в файле wa-system/controller/waLoginAction.class.php.

  ответить