и мне бы узнать как эти дырки закрыть...

В любой системе вполне вероятны уязвимости. Помню, что код, зашифрованный этой вирт. машиной вполне расшифровывали (без ключа).

XSS

Да, трояны любят прятать в том числе и таким образом. Но не факт, что там внутри именно троян

вообщем скачал этот движок без ионкуба декодированный.
и там не работает статистика.

Перестать пользоваться этим кодом?

XSS тут ни при чем. Если там и есть умышленные дыры, то скорее RCE.

А если есть именно XSS, то это скорее оплошность разработчика. Непреднамеренная

Не использовать ионкуб

Коллеги..  помогите,
кто сталкивался с таким при выполнение команды composer update

Could not delete /var/www/....../vendor/symfony/polyfill-php70/LICENSE:

С правами все ок?  вероятно нет.

вот проверяю с под другого

Из под рута, чтобы наверняка (вредные советы ON)

__так и попробовал и ....

все гуд)

👍

sudo composer update это 5

👍

Ребята кто поможет изменить парсер а имено не большой код php mysql на sqlite ОТБЛАГОДАРЮ$

Описание группы читал?

Помогите пожалуйста разобраться с событиями.
Есть заказ. Заказ может переходить в разные состояния. Например заказ перешёл в процессинг, создалось событие. Далее диспетчер запускает все слушатели, которые были подписаны на это событие.
1. Можно ли/правильно ли при таком подходе делать так, что если один из слушателей вылетит с ошибкой, то делать откат и самого заказа, т.е. можно ли оборачивать в транзакцию сам переход состояния заказа вместе с обработчиками события. Или же результат работы обработчиков ни как не должен влиять уже на сам заказ. Если события отправляются в очередь, то понятно, что здесь уже не обернёшь все.
2. При проектировании системы с событиями, нужно ли проектировать с учетом того, что в любой момент может появится необходимость отправлять все события в очередь, т.е. они не сразу обработаются, а через какое-то время, и при этом ничего не должно сломаться. Другими словами, если мы используем события/обработчики то мы изначально понимаем что нам не должно быть важно, что какой-то обработчик выполниться не сразу после наступления события.
3. Если необходимо сделать так, чтобы после перехода заказа в какое то состояние, выполнилась ещё какая то операция, и ошибка в ней должна была откатить и сам заказ, то эту операцию необходимо поместить в один use case и обернуть все в одну транзакцию, при этом подход с тем, чтобы такую операцию поместить в обработчик события использовать нельзя. Верно ли это?