vitaly_74

На первом скрине, похоже, атака через "Stacked Queries". Хацкер надеется, что вы не отфильтровали входящие данные.

Допустим у вас из бройзера приходит ID товара. И в программе запрос:

SELECT * FROM products WHERE productid={нефильтрованный ID};

Хакер отправляет вместо ID товара следующее:

1; SELECT pg_sleep(25)

В результате получится запрос:

SELECT * FROM products WHERE productid=1; SELECT pg_sleep(25);

И ваш сервер при каждом таком запросе будет спать 25 секунд. И порядочное количество таких запросов в случае удачи атаки смогут повесить вам там всё.

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

Я разобрался, слава макаронному монстру. Оставлю пост для всех тех, у кого много вопросов, но мало ответов:

В чем суть сегодняшнего жса (пишу для жквери динозавров вроде себя, кто слышал о всем новом, не до конца не понимал):

1. Раньше жс был тонной отдельных файлов в глобальном пространстве. Жквери и в след за ней 10 плагинов разной направленности. Это и сейчас так осталось, только теперь вебпак пакует еще большее количество файлов, но написанное на ES с участием require и export. Тот же самый привычный для серверных языков require внутри одного файла импортит другой файл, в котором прописан export. В ноде из коробки это работает, но в данном случае у нас бекенд не нода и это не работает.

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

3. Мы пишем модули. Бегущая строка = модуль, подсчет времени = модуль. Все это раскладываем в читабельном виде по структуре папок внутри проекта. Их мы собираем вебпаком. Вот по вебпаку вводная, например: https://habr.com/post/309306/

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

5. Подключаем итоговый файлик как обычно на странице - на этом сборка окончена. Далее уже пошел наш ES5-6 код с реактом или без реакта. Далее ватчеры, less-sass-scss-babel с пресетами и все остальное через вебпак становится юзабельным и уходит уже в папки, откуда сервер отдает готовые и скомпиленные статичные файлы.

В данном случае не получилось подружить Yii с реактом в том смысле, что я хотел это сделать не нарушая иерархию - через vendor/npm-asset, без /node_modules/ в корне данная конструкция не запускается - вебпак не видит их через require. Но node_modules в корне все ок.

Я для этих целей использую расширение Decimal:

(new Decimal\Decimal('153.17'))->mul(100)->toInt(); // 15317

Но можно использовать и функцию bcmul:
(int)bcmul('153.17', '100'); // 15317

Самая грамотная по моему следующая стратегия.
Анонимный пользователь получает в localstorage или в куку свой идентификатор который вечный.
Дальше приложение считывает этот идентификатор, если он уже есть в базе то товары складываются в бд именно для этого пользователя, если нет то просто в локалстораге.
После логина все уходит в бд и хранится только там.

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

все просто:

1 двигает элемент вниз массива, -1 двигает элемент вверх массива, 0 оставляет на месте.

Почему uasort отрабатывает не так как ожидается?

У вас очень логичный вопрос на счет сеттера: сеттер полностью уничтожает задумку с инкапсуляцией. Правильно это называется "семантическое нарушение инкапсуляции" — то есть как-бы мы инкапсулировали, но по факту назад открыли прямую запись в свойство напрямую. Все доводы "ну мы можем в сеттере валидировать" не корректны

Правильным способом будет не использовать сеттеры. Вот моя статья на эту тему:
https://habr.com/ru/post/469323/

Более подробно: каждый класс нужно проектирвовать так, чтобы данные внутри были максимально связаны. Например каждый метод работать должен в хорошем случае с максимальным числом полей класса, тогда у него высокий cohesion... В тоже время снаружи наужно работать с максимальн омалым числом метода, тогда будет низкая связанность (coupling). Это пара принципов из GRASP.
Когда вы делаете сеттеры и геттеры, то у вас данные внутри между собой почти никак не взаимодействут: с геттером работают снаружи, с сеттером работаю снаружи — весь класс нараспашку, а в нем в 100% случаев появляются данные, которые вместе не должны находиться и никак не связаны — анрушена и абстракция и инвариант и много чего еще...

Про инвариант отдельно: например есть платеж, у него есть значение, с которым платеж инициирвоан (initValue), есть значение холда (holdAmount) и есть значение чарджа на списание (chargeAmount)
Когда вы работаете с платежом, контролируя ивнариант в самом классе, то ваш каждый метод првоеряет др значения и позволяет перейти к др состоянию... методов будет 2-3, все инкапсулировано и безопасно.

Например:

class Payment {
     pub func charge(amount int) void {
          if (this.holdAmount < amount && this.initAmount < amount) {
               throw new PaymentException('Unavailable charge amount')
          }

           if (this.status === PaymentStatus:finish) {
               throw new PaymentException('Payment already fisnished')
          }

          this.chargeAmount = amount
          this.holdAmount -= amount
          this.status = PaymentStatus:finish
     }
}

Тут в одном методе полные проверки и класс сам контролирует все состояние внутри, также соблюдается закон Деметры. У даннго кода высокий cohesion (из GRASP), тк внутри идет плотная работа с внутр данными (значит они корректно тут закроекны) и низкий coupling ( с теми данными для данного кейса только один метод работы, все внутри)

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

В PHP такой синтаксис не используется. Есть ассоциативные массивы, но у них другой синтаксис:

$foo = ['order' => '100668327'];
echo $foo['order'];

или

$foo = (object)['order' => '100668327'];
echo $foo->order;

Если речь о полученном откуда-то JSON, то его надо декодировать через json_decode.

$foo = json_decode('{"order":"100668327"}');
echo $foo->order;

или

$foo = json_decode('{"order":"100668327"}', true);
echo $foo['order'];

Можно ли хранить товары, посты и всю инфу где нет приватных данных в JSON, а не в БД?

Можно

Какие плюсы данного метода?

Никаких

Какие минусы данного метода?

Вам придется реализовать все что уже сделано разработчиками баз данных самостоятельно

Вполне себе стоит.
Скорость будет падать, если к одной станции подсосётся много устройств - это да.
Но низкая она у вас из-за слабого сигнала.

Тем, что асинхронность - это кооперативная многозадачность, в котором порядок выполнения определяется на прикладном уровне, а многопоточность - это вытесняющая многозадачность, в которой порядок выполнения фактически случаен.

public function behaviors()
 {
     return [
        [
             'class' => 'yii\filters\ContentNegotiator',
             'only' => ['view', 'index'],  // in a controller
             // if in a module, use the following IDs for user actions
             // 'only' => ['user/view', 'user/index']
             'formats' => [
                 'application/json' => Response::FORMAT_JSON,
             ],
             'languages' => [
                 'en',
                 'de',
             ],
         ],
     ];
 }

Class yii\filters\ContentNegotiator

Сложно понять Вашу картину и что имел ввиду Ваш коллега. Об этом лучше спросить самого коллегу. Однако постараюсь помыслить на эту тему...

1. Конкретно DTO не совсем применима к API в чистом виде и работе с ней. Более правильно в запрос кидать json, а вот этот json уже маппить на вашу DTO, в которой будет высокоуровневая валидация от симфони и php7.4. Пример И само DTO.

2. Так как у вас система микросервисная, то DTO передавать по сети точно не нужно. Вы можете использовать DTO внутри своего приложения, но не использовать его по сети. DTO позволяет Вам в сервис/хэндлер/команду передавать не сам Request и не кучу параметров, а своё DTO, которая должна создаваться на основе запроса. Таким образом вы отделяете слои и ответственности. При изменении названий параметров DTO не обязательно их менять в API и наоборот. Нет зависимости и это хорошо! Так же хорошо и для тестируемости.

3. Если вы упомянули ParamConverter это по сути конвектор параметров, но опять же на уровне приложения, а не между запросами сети) Об использовании его можно почитать в документации симфони. С помощью него можно указать в методе DTO, которую он принимает, а конвектор, написанный вами, знает как это DTO создать на основе ваших переданных данных. То есть вы не DTO передаёте в запрос, а те же параметры, просто этот конвектор делает вам из этих параметров DTO. Использовать его или нет - дело ваше. Вы правильно подметили, что в Yii2 такого нет. Можно заморочиться написать свой, но смысла от этого нет вообще) Использовать DTO я бы рекомендовал. Так как профит будет: разделение слоев, меньшая связанность и возможность валидации. А вот использовать конвектор - решение команды или разработчика. Оно позволяет вам создать вашу DTO на основе переданных параметров. Параметры никуда не денутся, они просто сразу лягут в DTO это один профит - чище код.