добавлю - сущности я создал ORM генератором, но связи нужно добавлять вручную
05.06.2024 08:29:30
есть 2 сущности "очереди" RECEIPT_QUEUE и "календари" RECEIPT_CALENDAR - обе ХЛ блок
связь в одну сторону - в очередях добавлено множественное свойство типа ссылка на элементы ХЛ блока как её описать? подробнее: то что в доке я думаю все эти связки из документации работать не будут т.к. они рассчитаны на ManyToMany двух кастомных сущностей с использованием собственной таблицы 'receipt_queue_calendar' 'RECEIPT_CALENDAR' => (new ManyToMany( 'RECEIPT_CALENDAR', ReceiptCalendarTable::class ))->configureTableName('receipt_queue_calendar'), в таблице receipt_queue_calendar пусто !!! - ни одной записи, поэтому ничего и не будет работать! на самом деле календари - это множественное свойство в ХЛ блоке (я его в админке и создавал) система сама автоматически создала таблицу receipt_queue_uf_receipt_calendar с полями ID и VALUE сейчас там как раз есть данные для связки, и они явно используются в самой админке то есть какой то другой подход должен быть ... |
|
|
13.04.2024 05:36:41
проверка "Цитирования" |
|||
|
21.02.2024 10:46:02
такое лучше в саппорте спросить |
|||
|
13.02.2024 07:18:42
бесплатно? если да, то вообще супер-вариант! ![]() |
|||
|
13.02.2024 07:11:56
вот я тут сильно сомневаюсь, что закрыты - я когда "наискосок" посмотрел "bitrix attack" (90% конечно не понял, уж больно всё на "заумном"), но понял одно - если внутри ядра не поправлено, то "достучаться" можно не только через явно указанные дыры и первое, что нужно сделать это актуализировать движек, потом всё в гит и вылавливать дыры в некоторых случаях (например в Вашем) наверное проще перетащить контент на свежеустановленный движек, потом гит и режим наблюдения, иначе можно задолбаться вычищать |
|||
|
13.02.2024 07:05:15
это что-то новенькое
при файловом доступе авторизация вообще не проблема
100% ! может быть и хуже на сколько я помню Украинские хакеры после начала СВО сносили контент - как в БД так и в файлах |
|||||||
|
12.02.2024 18:43:14
Ну да - смена всех паролей это вообще первое, что нужно сделать при обнаружении взлома. SSH, FTP и от админки тоже Шаред хостинг в принципе не рекомендую - виртуалки имхо понадёжнее. Раньше было много кейсов по взлому "соседей", сейчас не знаю как там дела обстоят. |
|||
|
12.02.2024 12:34:45
* сделать бэкап текущего состояния сайта, скопировать логи для дальнейшего изучения * удалить сайт по умолчанию в /home/bitrix/www, если он не нужен. Проверить отсутствие установочных скриптов bitrixsetup.php и restore.php * проверить, нет ли каких-то служб в systemctl или задач в crontab, которые вы не создавали, удалить лишнее и подозрительное * сменить все пароли - ssh, ftp, все админские учетные записи на сайте * воспользоваться штатными средствами Проактивная защита начать с поиска троянов /bitrix/admin/xscan_worker.php?lang=ru * воспользоваться сторонними средствами ( aibolit и т.п.) * поискать по файлам вручную (самое быстрое в консоли по ssh), довольно много сингатур публиковались в этой ветке - конкретный пост не подскажу, давненько было дело - нужно искать. Я по ним много раз находил заразу. * посмотреть агентов - чтобы лишних не было (если зараза в агентах, то смысла в файловой системе искать нет - всё равно будет заново создано) * так же в памяти не помешает глянуть (или ребутнуть аппача), бывает зараза сидит в памяти и при удалении сама себя сразу же восстанавливает * добавить код сайта в гит (будете изменения быстро вылавливать, а так же контролировать новые файловые изменения) * поставить какой нибудь скриптик по отлову изменений (например, при изменении сразу письмо на электронку) так по горячим следам гораздо проще анализировать логи (например за последние сутки) * по логам вычислить заразу и прибить * после чистки - режим наблюдения (скрипт изменений + гит либо просто регулярно git status в ручном режиме) * регулярное резервное копирование (желательно не сюда же - в облако или стороннее хранилище, при наличии гита можно бэкапить только БД) как то так ... P.S. так же можно обратиться в саппорт Битрикса - есть случаи когда саппорт помогал найти и устранить уязвимость |
|||
|
12.02.2024 12:27:31
пока не догадаетесь, так и будет всякая зараза на сайте значит у Вас либо открытая уязвимость (версия движка актуальная?) либо бэкдор, который подсунули в момент когда уязвимость ещё была не защищена нужно проанализировать логи - найти эту дыру и залатать |
|||
|
12.02.2024 09:06:46
походил по каталогу - не моделируется |
|||
|
10.02.2024 04:37:04
Ну вот - и движек то не при делах. Хорошая новость. |
|||
|
07.02.2024 10:43:42
Ну так то для дебага совсем не обязательно VirtualBox + VScode. Я например юзаю VMWare + PHPStorm, реже Docker + PHPStorm. Вообще да - дебаг самое надёжное решение для любой возможной ситуации. |
|||
|
07.02.2024 04:22:59
на попытки забейте - это нормальная история, ищите "не попытки", всё что 404 смысла нет смотреть (имхо)
Вы же понимаете, что фронт без бэка сам выполняться не начнёт - ищите откуда "ноги растут" и результат плс в студию |
|||||
|
06.02.2024 11:09:56
и именно поэтому повышенный интерес к взлому |
|||
|
05.02.2024 18:59:54
Кстати, как с соседями - один сайт на виртуалке? |
|||
|
05.02.2024 18:58:24
да вот как показывет практика - bitrix обычно в исключения ставят, а зараза как раз любит именно туда зацепиться поэтому, не думаю, что сильно намного проще вот наличие читых бэкапов - это здорово, я бы восстановил с бэкапа, обновился до актуального и уже спокойно искал заразу ну и анализ логов, анализ логов, анализ логов |
|||
|