Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Критическая уязвимость в системе управления web-контентом Dr..."	+/–
Сообщение от opennews (??), 21-Фев-19, 21:30
В системе управления контентом Drupal выявлена (https://www.drupal.org/sa-core-2019-003) критическая уязвимость (CVE-2019-6340 (https://www.drupal.org/sa-core-2019-003)), позволяющая удалённо выполнить произвольный PHP код на сервере. Уязвимости присвоен наивысший уровень опасности - "Highly critical" (20∕25). Проблема устранена (https://cgit.drupalcode.org/drupal/commit/?h=8.5.x&id=3c6e78...) в выпусках Drupal  8.5.11 (https://www.drupal.org/project/drupal/releases/8.5.11) и 8.6.10 (https://www.drupal.org/project/drupal/releases/8.6.10). Уязвимость вызвана отсутствием должной чистки некоторых типов полей, передаваемых не через обычные формы ввода, а через API для взавимодействия с web-сервисами. Проблема проявляется в Drupal 8 при  разрешении методов PATCH или POST и активности встроенного модуля RESTful Web Services (rest) или любых внешних модулей с реализацией web-сервисов, таких как JSON:API (https://www.drupal.org/project/jsonapi) в Drupal 8 или Services (https://www.drupal.org/project/services) и RESTful Web Services (https://www.drupal.org/project/restws) в Drupal 7. В качестве обходного пути защиты можно отключить все модули с реализацией API для работы web-сервисов или запретить в настройках обработку запросов к ресурсам web-сервисов с использованием HTTP-методов PUT, PATCH и POST. Помимо входящего в базовый состав API RESTful Web Services выделено 8 проблемных внешних модулей (https://www.drupal.org/security/contrib), в которых может быть эксплуатирована данная уязвимость. Проблема затрагивает основную поставку Drupal только для ветки Drupal 8.x. Ветка Drupal 7 сама по себе не требует обновления, но вышеупомянутые варианты модулей для неё подвержены проблеме и требуют отдельного обновления. URL: https://www.drupal.org/psa-2019-02-19 Новость: https://www.opennet.dev/opennews/art.shtml?num=50187
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Критическая уязвимость в системе управления web-контентом Dr..."	+6 +/–
Сообщение от Аноним (1), 21-Фев-19, 21:30
Когда была новость про Wordpress, сразу подумал о друпале. Вот и настал его черёд
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Критическая уязвимость в системе управления web-контентом Dr..."	+9 +/–
	Сообщение от Аноним (2), 21-Фев-19, 21:33
	wordpress, joomla, drupal - святая троица
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Критическая уязвимость в системе управления web-контентом Dr..."	+1 +/–
	Сообщение от th3m3 (ok), 21-Фев-19, 21:35
	Joomla разве ещё жива?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Критическая уязвимость в системе управления web-контентом Dr..."	+6 +/–
	Сообщение от Аноним (2), 21-Фев-19, 21:39
	живее живых: >Created: 12 February 2019 >Joomla 3.9.3 is now available. This is a security fix release for the 3.x series of Joomla which addresses 6 security vulnerabilities and contains 30 bug fixes :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Аноним (1), 21-Фев-19, 21:40
	Ну последний релиз 9 дней назад, судя по англовики
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Критическая уязвимость в системе управления web-контентом Dr..."	+1 +/–
	Сообщение от Аноним (9), 21-Фев-19, 21:49
	Вам сюда https://framework.joomla.org Уже и framework и composer и все "потроха" меняют аккуратно без революций, незаметно для пользователей.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	10. "Критическая уязвимость в системе управления web-контентом Dr..."	+1 +/–
	Сообщение от th3m3 (ok), 21-Фев-19, 21:55
	Сейчас стало модно добавлять слово - Framework. Даже Битрикс теперь Framework :) Но только от этого, они лучше не стали)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Критическая уязвимость в системе управления web-контентом Dr..."	+1 +/–
	Сообщение от Аноним (11), 21-Фев-19, 22:15
	Ну почему. Та же жумла лучше *стала.* Но лучше там ещё становиться и становиться.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	16. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Вадии (?), 22-Фев-19, 03:10
	Как бы фреймворк мало общего с платформой имеет. Они лишь планируют их сливать и то только в пятой ветке если повезет. Хотя внутри да меняется потихоньку, хотя лучше бы все таки сосредоточились на юзабилити. Для хомячков с wp  меню в три уровня это сложно очень :-)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	18. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Аноним (18), 22-Фев-19, 07:35
	До фреймворка вручную правили платформу, теперь - фреймворк. Чтобы сделать автоматическое обновление невозможным. Т.о. заказчик навсегда привязан к разработчику. Или заказывает новый сайт.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	34. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Kuromi (ok), 23-Фев-19, 04:04
	Жумла стала не то что жива, а даже "более-менее" - в последнее время все таки работа над безопасностью дает о себе знать и дырок стало меньше.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	37. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от th3m3 (ok), 23-Фев-19, 16:32
	Неужели кто-то ещё остался на php и юзает коробочные CMS? Разве что - студенты шлёпают сайты за еду на этом.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	40. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Kuromi (ok), 23-Фев-19, 17:04
	> Неужели кто-то ещё остался на php и юзает коробочные CMS? Разве что > - студенты шлёпают сайты за еду на этом. Иногда большего и не нужно. А еще иногда надо вот это вот "нашлепанное" 5-10 лет тому назад как-то обновлять чтобы скрипткиддисы по руоководствам с Ютупа не могли дефейсить. Если за время существования поделки туда активно постили всякий контент (случаи бывают что там многие тысячи постов, с картинками и прочим) проще потихоньку обновлять движек чем переносить все это куда-то еще.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

7. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
Сообщение от Аноним (1), 21-Фев-19, 21:41
Как, интересно, дела у MediaWiki?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Аноним (22), 22-Фев-19, 11:31
	т.к. её запустить (что-бы можно пользоваться было) ещё суметь нужно, она не интересна как цель для взломщиков пока есть другие более массовые продукты.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Критическая уязвимость в системе управления web-контентом Dr..."	+1 +/–
Сообщение от commiethebeastie (ok), 21-Фев-19, 22:49
>позволяющая удалённо выполнить произвольный PHP код на сервере. Мило.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
Сообщение от Аноним (13), 21-Фев-19, 23:01
Друпал 8 все время нестабильный и никому не нужный.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Попугай Кеша (?), 22-Фев-19, 12:42
	Ему надо долго учиться, а Joomla/WordPress взял и пошел фигачить статейки
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
Сообщение от Kaiwas (?), 21-Фев-19, 23:54
что-то этакое подобное/похожее закрывали с год назад в modx
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Критическая уязвимость в системе управления web-контентом Dr..."	+1 +/–
Сообщение от Аноним (15), 22-Фев-19, 00:29
Я не понимаю, чего все агрятся. Да, уязвимость. Но не следует забывать, что друпал написан не на языке программирования, а на шаблонизаторе "Персональная Домашняя Страница". Хоть как-то работающая CMS на шаблонизаторе - уже чудо. Вы же не критикуете акварельные рисунки своих 6-летних детей? Хоть что-то нарисовал - уже хорошо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Критическая уязвимость в системе управления web-контентом Dr..."	+2 +/–
	Сообщение от Jvc1 (?), 22-Фев-19, 09:05
	Когда-то JS тоже был для браузеров ради динамики веб-страничек, а Java - для умной бытовой техники.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	21. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Аноним (15), 22-Фев-19, 09:12
	и даже в те времена .js- и .java-файлы были именно исходниками на языке программирования, а .php-файл и поныне - это по умолчанию именно обычный текстовый файл произвольного содержания, а чтобы начать вставлять в него конструкции шаблонизатора, нужно обрамлять их через <?php ?>
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	25. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Jvc1 (?), 22-Фев-19, 14:25
	В PHP можно как угодно, в том числе и так. А в JSP/JSF не так что ли?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	27. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Аноним (27), 22-Фев-19, 15:00
	> В PHP можно как угодно, в том числе и так. Ага, и поэтому все похапе-файлы начинаются исключительно с <?php, причем всякие утф-бомы совать нельзя, а то будет headers already sent. А начинаются с <?php, поскольку похапе не язык программирования, а шаблонизатор, а конструкция <?php просто переключает с текстового режима в режим шаблонизаторских конструкций.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	30. "Критическая уязвимость в системе управления web-контентом Dr..."	–1 +/–
	Сообщение от Аноним (30), 22-Фев-19, 17:10
	> всякие утф-бомы совать нельзя Зачем вам совать утф-бомы? ascii для кода и комментариев, utf-8 без бома для тех редких случаев, когда нужна иностранщина.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	31. "Критическая уязвимость в системе управления web-контентом Dr..."	–1 +/–
	Сообщение от Аноним (15), 22-Фев-19, 18:10
	Сунул бом в файл якобы "исходного кода" - запустилась логика по отправке HTTP-заголовков клиенту. В языках программирования такого не бывает. Сунул бом в .java-файл - не страшно, никакая логика не запустится. Ну а в шаблонизаторах такой сайд-эффект это норма.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	28. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Ordu (ok), 22-Фев-19, 16:01
	> на шаблонизаторе "Персональная Домашняя Страница". > обычный текстовый файл произвольного содержания Вот сейчас ты пытаешься натянуть сову на глобус. Ты используешь совершенно невалидные аргументы для того, чтобы доказать, что всё что написано на PHP обречено на судьбу Drupal. Проблемы привносимые PHP не имеют ничего общего с тем, о чём говоришь ты. Я очень давно в него заглядывал, поэтому моё мнение устарело вероятно, но тогда разработчики PHP и разработчики на PHP совершенно не умели в системное программирование. Ну, в том смысле, что инкапсуляция, разделение функциональности по разным местам, причём принудительное разделение, так чтобы тупому и ленивому программисту было бы проще сделать правильно, чем плохо. Вон с дырой в плагине к wordpress, я так и не понял, зачем было ждать от плагина, чтобы тот проверял привилегии, почему нельзя было сделать это в update_options? По-моему, напрашивающееся решение -- вообще все права доступа проверять централизованно, и вне зависимости от того, как что и о чём думает разработчик. Чтобы написание кода, который обойдёт проверки на права доступа, выливалось бы в заморочный код строк в 100, в код добавление которого невозможно будет не заметить. Но не, PHP двадцать лет назад предлагал программистам интерфейс к SQL, вида "собери из строк SQL запрос и отправь его бэкенду". И по-моему они до сих пор продолжают действовать именно так. С тех пор уже были примеры cl-sql и ActiveRecord в rails. Как минимум два -- это те, в которые я заглядывал, сколько же есть реализаций, в которые я не заглядывал, я даже предположить боюсь. Все преимущества очевидны -- проблемы экранирования решаются системно, нам уже не надо ждать от каждой тупой макаки пишущей код, что она будет уметь экранировать правильно. Как только мы сделали это, у нас уже пропадает жёсткая линейная зависимость количество дыр вызванных неверным экранированием от количества вызовов sql_query. Коэффициент в этой линейной зависимости внезапно оказывается монотонно убывающей функцией от времени. Но PHP продолжает предлагать макакам использовать sql_query. У PHP проблемы не с названием, у него гораздо более серьёзные проблемы, его разработчики не умеют мыслить системно, не умеют создавать надёжные системы, не умеют закладывать в системы запас надёжности, и именно поэтому системы на PHP столь ненадёжны. facebook'у как-то удаётся, но я полагаю они смогли переломить карму PHP, посадив за написание кода на PHP хотя бы нескольких людей, кто не потерял из-за этого способность мыслить системно.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	29. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Аноним (27), 22-Фев-19, 16:45
	Все, что ты говоришь, - правильно. Но одновременно с этим все, что ты говоришь, - жестоко. Ты взял акварельный рисунок своего сынишки и, вместо того, чтобы примагнитить его к холодильнику, опубликовал разгромную статью о том, что пропорции в изображении мамы ненатуральны, что перспектива не соблюдена, что солнце - это просто кружок с торчащими из него неестественными линиями... Если же подходить к вопросу с позиций, что Personal Home Page - это именно не более, чем шаблонизатор, то все становится на свои места.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	32. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Ordu (ok), 22-Фев-19, 18:22
	> Если же подходить к вопросу с позиций, что Personal Home Page - > это именно не более, чем шаблонизатор, то все становится на свои > места. Это более чем шаблонизатор. Когда я десять лет назад его разглядывал, он тогда был более чем шаблонизатор. Но с совершенно убогой стандартной библиотекой: зачем копировать C'шные API в язык с динамической типизацией, с ООП и прочими штуками? Прежде чем пользоваться этим "шаблонизатором", надо поверх этой библиотеки написать нормальную, с API которые напрашиваются из возможностей языка.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	33. "Критическая уязвимость в системе управления web-контентом Dr..."	+2 +/–
	Сообщение от Аноним (15), 22-Фев-19, 19:24
	> зачем копировать C'шные API в язык с динамической типизацией, с ООП и прочими штуками По пыху можно отследить прогресс в изучении его автором языков программирования. Пока он знал только си, он имитировал в пыхе си. Потом он открыл для себя перл -- вот и появились поверх си-стайл апи перловые конструкции. Далее в честь окончания забугорного аналога ПТУ ему подарили книжку "Java с нуля за 21 день" - и вот у нас в си-перл-стайл пыхе уже игрушечное ООП, имитирующее Яву. Далее он ознакомился с функциональным программированием. К сожалению в это же самое время он лечился от последствий сотрясения мозга, поэтому array_reduce и array_map принимают функцию и массив в разном порядке.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	35. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от пох (?), 23-Фев-19, 13:31
	> Вон с дырой в плагине к wordpress, я так и не понял, зачем было ждать от плагина, чтобы тот > проверял привилегии, почему нельзя было сделать это в update_options? потому что, внезапно, нет ничего необычайного в плагине, который управляет привиллегиями. на этом, собственно, надо микрофон апологету выключить, и больше его выступлений не слушать, поскольку он не понимает совершенно тривиальных вещей, но вещает нам о мировых тенденциях. > С тех пор уже были примеры cl-sql и ActiveRecord в rails. Как минимум два -- это те, в которые я > заглядывал, сколько же есть реализаций, в которые я не заглядывал, я даже предположить боюсь. больше прокладок богу прокладок. И, конечно же, их какие-то уникальные люди пишут, не те же самые. А для писания на php, как встарь, достаточно знания sql, а не еще стапиццот прокладок (впрочем, новые-модные фреймворки это успешно нивелируют). А если вы не умеете в работу с untrusted input и делаете какие-то предположения о том, что он может содержать - то вам никакие прокладки не помогут вообще - все равно вас поимеют.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	38. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Ordu (ok), 23-Фев-19, 16:36
	>> Вон с дырой в плагине к wordpress, я так и не понял, зачем было ждать от плагина, чтобы тот >> проверял привилегии, почему нельзя было сделать это в update_options? > потому что, внезапно, нет ничего необычайного в плагине, который управляет привиллегиями. И что? Сделай либо API в ядре CMS для установки объекта управляющего привилегиями, либо устанавливай такие плагины посредством наложения патчей на ядро CMS. Неудобно, но в том-то и фишка, что неудобно, нам нужно чтобы каждый идиот не лез своими кривыми ручонками в самые критичные куски кода. > больше прокладок богу прокладок. Я люблю принципиальных людей. Они так забавно продавливают свои принципы наперекор любому здравому смыслу, что невольно начинаешь гадать о том, какими интересными лабиринтами движется их процесс мышления. > А для писания на php, как встарь, достаточно знания sql, а не > еще стапиццот прокладок (впрочем, новые-модные фреймворки это успешно нивелируют). > А если > вы не умеете в работу с untrusted input и делаете какие-то > предположения о том, что он может содержать - то вам никакие > прокладки не помогут вообще - все равно вас поимеют. С untrusted input (как впрочем и со всем остальным) проблема решается очень просто: пишется отдельный код, который из untrusted input'а, делает trusted. Мы в этот код засовываем данные полученные от пользователя, а на выходе мы получаем либо дулю с маслом (панику, Err(InvalidData), вылет исключения, или даже NULL -- не важно), либо структуру с trusted данными. Такая замечательная прослойка позволит отлаживать код разбора данных один раз, покрыть его тестами, прогнать его через две недели фаззинга на шестнадцати ядрах, и потом, какой бы дурак не пользовался нашим API для работы с untrusted данными, он просто не сможет перепутать endiannes, записать в поле size значение полученное от пользователя, не проверив его валидность, и вообще ничего особо плохого он сделать не сможет. Потому что о его возможных ошибках мы подумали заранее. Надо только не забыть порезать клиентскому коду все простые пути получения исходных untrusted данных, и вынудить его пользоваться нашим API. ps. Честно говоря, глядя на твои понты здесь, я думал о тебе лучше. Думал, что понты наверное не на пустом месте, и пох наверное что-то понимает в программировании. Но, судя по этим возражениям, это абсолютно пустые понты.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	39. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от пох (?), 23-Фев-19, 17:03
	> И что? Сделай либо API в ядре CMS ну сделай, что-ли... только, полагаю, описание всех возможных в твоей cms апи закончат читать к моменту, когда конкуретны на вротпрессе и дрюпалке уже пятую версию сайта выкатят. > С untrusted input (как впрочем и со всем остальным) проблема решается очень просто: пишется > отдельный код, который из untrusted input'а, делает trusted. похоже, ты никогда не пытался его написать. Нет, не бывает такого кода. Единственный способ работы с untrusted input - помечать его таки как untrusted, и тащить в таком виде через весь код до места применения. Разбери простейший пример - untrusted input - текст (предположим, только) из веб-формы.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	41. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Ordu (ok), 23-Фев-19, 18:10
	>> И что? Сделай либо API в ядре CMS > ну сделай, что-ли... только, полагаю, описание всех возможных в твоей cms апи > закончат читать к моменту, когда конкуретны на вротпрессе и дрюпалке уже > пятую версию сайта выкатят. Вот делать мне больше нечего, кроме как решать проблемы пэхапунов. Ну, реально. Зачем я буду писать все эти замороки, есть у меня есть Rocket[1]? Который генерит скомпилированный нативный бинарь, выполняя на этапе компиляции всю работу, которую можно выполнить на этапе компиляции, чтобы не выполнять её во время выполнения. Который очень строго обходится с типами, позволяя мне полагаться на то, что если у меня есть переменная u8, то мне не удастся _нечаянно_ какой-нибудь арифметической операцией превратить её значение в String или в i32. В пхп, я подозреваю, при попытке разработать подобный API, половину времени придётся потратить на размышления, как спроектировать API, чтобы были бы невозможными нечаянные конфузы вызванные неявными автоматическими преобразованиями типов. Ты не представляешь себе как подобные проблемы бесят после опыта работы со строго типизированным языком. >> С untrusted input (как впрочем и со всем остальным) проблема решается очень просто: пишется >> отдельный код, который из untrusted input'а, делает trusted. > похоже, ты никогда не пытался его написать. > Нет, не бывает такого кода. Единственный способ работы с untrusted input - > помечать его таки как untrusted, и тащить в таком виде через > весь код до места применения. Так в чём проблема-то, я не понял? В том смысле, что я согласен с тем, что лучший подход -- это тащить данные блобом до того места, где они понадобятся, и где-нибудь там, где они понадобятся, объяснять библиотечному коду, что именно мы хотим извлечь. Но я не вижу здесь никаких противоречий с тем, чтобы весь код разбора аргументов был бы сложен в специальные места и был бы покрыт специальными тестами. > Разбери простейший пример - untrusted input - текст (предположим, только) из веб-формы. [2] #[derive(FromForm)] struct Task {     complete: bool,     description: String, } #[post("/todo", data = "<task>")] fn new(task: Form<Task>) -> String {     format!("Form `task` had fields: `complete`=={:?}, `description`=={:?}",              task.complete, task.description) } Это делается _элементарно_. Обработчик запроса получает распарсенную форму, в которой уже проверены все значения -- строки на валидность utf8, числа на синтаксис и на попадание в заданный диапазон, enum'ы на то, что указанное значение допустимо. Всё элементарно, причём в парадигме "разделяй и властвуй". Если, конечно, мы пользуемся не пхпшными библиотеками из 90-х годов, а чем-нибудь, хотя бы, из нулевых. [1] https://rocket.rs [2] https://rocket.rs/v0.4/guide/requests/#forms
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	42. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от пох (?), 23-Фев-19, 19:04
	> Вот делать мне больше нечего, кроме как решать проблемы пэхапунов. Ну, реально. > Зачем я буду писать все эти замороки, есть у меня есть ну так, чтоб немного отличаться от абстрактного диванного теоретика, не? > Rocket[1]? Который генерит скомпилированный нативный бинарь, выполняя на этапе компиляции и для любого мелочного исправления нужно его перекомпилировать. (и еще пятнадцать раз, потому что с первого не всегда получается правильно) > всю работу, которую можно выполнить на этапе компиляции, чтобы не выполнять включая сборку кода, который вероятнее всего не будет вызван ровно ни разу до следующей перекомпиляции. А теперь представляем на нем такого типичного монстра каких пишут для больших сайтов на той дрюпалке - и ужасаемся. Оно,простите, сколько времени хотя бы перезапускается? (вот php-fpm, например - медленно, приходится костыликами обкладывать - но его-то мне и не надо перезапускать при изменении кода) > Так в чём проблема-то, я не понял? В том смысле, что я попробуй код из твоего примера применить там, где обычно применяются полученные из вебформы данные. Ну чего я тебе подсказывать должен, где на самом деле и как. > согласен с тем, что лучший подход -- это тащить данные блобом > до того места, где они понадобятся, и где-нибудь там, где они там ньюансы бывают... например, место это вообще не у нас. > Это делается _элементарно_. Обработчик запроса получает распарсенную форму, в которой то есть кто-то что-то сделал за тебя. > уже проверены все значения -- строки на валидность utf8, числа на а кто сказал что это utf? ;)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	43. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от Ordu (ok), 23-Фев-19, 20:11
	>> Вот делать мне больше нечего, кроме как решать проблемы пэхапунов. Ну, реально. >> Зачем я буду писать все эти замороки, есть у меня есть > ну так, чтоб немного отличаться от абстрактного диванного теоретика, не? Нет, это недостаточная причина. >> Rocket[1]? Который генерит скомпилированный нативный бинарь, выполняя на этапе компиляции > и для любого мелочного исправления нужно его перекомпилировать. (и еще пятнадцать раз, > потому что с первого не всегда получается правильно) Естественно. Ещё его надо тестировать после любого мелочного исправления. Вам что надо, надёжная система или пошатывающаяся от малейшего прикосновения гора костылей? >> всю работу, которую можно выполнить на этапе компиляции, чтобы не выполнять > включая сборку кода, который вероятнее всего не будет вызван ровно ни разу > до следующей перекомпиляции. А теперь представляем на нем такого типичного монстра > каких пишут для больших сайтов на той дрюпалке - и ужасаемся. Я не понял в чём проблема? Нехватка процессорной мощности сервера? Собирай и тестируй на выделенной под эти задачи машине, а не на сервере. Я, кстати, так и делаю, заливая на сервер готовые бинари, собранные в release. >> согласен с тем, что лучший подход -- это тащить данные блобом >> до того места, где они понадобятся, и где-нибудь там, где они > там ньюансы бывают... например, место это вообще не у нас. И что? В том месте программист возьмёт предложенный нами тип, и использует его. С нашим типом связана вся информация как надо парсить данные и как их надо верифицировать. Он может писать всё что угодно, но парсинг и верификация данных будет выполняться нашим кодом, который был хорошо продуман, документирован и оттестирован. Который имеет связанную с ним историю разработки, историю багов в нём найденных и исправленных, историю улучшений с объяснениями зачем они, и почему они были сделаны именно так, а не иначе. >> Это делается _элементарно_. Обработчик запроса получает распарсенную форму, в которой > то есть кто-то что-то сделал за тебя. Да. Или нет. Смотря что ты понимаешь под "сделал за тебя". В приведённом примере скорее "да", чем "нет": там ты можешь видеть, что объявления и структуры, и функции-обработчика запроса скармливается макросам, которые генерят весь необходимый код. Скорее "да", потому что вызов макроса для получения тривиальной реализации impl FromForm ты, я думаю, не считаешь поводом считать, что это сделано мною, а не кем-то ещё. Даже несмотря на то, что буквы "#[derive(FromForm)]" написал я. >> уже проверены все значения -- строки на валидность utf8, числа на > а кто сказал что это utf? ;) Я сказал. Там написано в объявлении структуры: String. String определяется в расте как utf8 owned строка. Там не может быть ничего другого.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	23. "Критическая уязвимость в системе управления web-контентом Dr..."	+2 +/–
	Сообщение от YetAnotherOnanym (ok), 22-Фев-19, 11:55
	> акварельные рисунки своих 6-летних детей Тонко. Зачот.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

26. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
Сообщение от Drupaler (?), 22-Фев-19, 14:41
Друпал с восьмой веткой явно пошел не туда. + разбазаривание сил на 7ю и 8ю. 7 - лучшее, что было в Друпале, пилить бы и пилить, но нет... хипстеры, новые веяния.. Жаль.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "Критическая уязвимость в системе управления web-контентом Dr..."	+/–
	Сообщение от хыпстер (?), 23-Фев-19, 13:34
	пилите, кто вам-то не дает? А-а-а, вы хотите чтоб пилил кто-то, а вам нахаляву пользоваться и еще и за деньги результат продавать? Тогда жрите что поднесли на лопате. Потому что те кто занимаются разработкой друпалок - получать деньги тоже любят, и делают ровно то, что, тем или иным способом, им эти деньги приносит.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема