forum.opennet.ru - "Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода" (66)

"Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода"

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

"Уязвимость в web-фреймворке Django, которая может привести к подстановке SQL-кода"	+/–
Сообщение от opennews (??), 04-Июл-22, 15:32
Опубликованы корректирующие выпуски web-фреймворка Django 4.0.6 и 3.2.14, в которых устранена уязвимость (CVE-2022-34265), потенциально позволяющая выполнить подстановку своего SQL-кода. Проблема затрагивает приложения, использующие непроверенные внешние данные в параметрах kind и lookup_name, передаваемых в функции Trunc(kind) и Extract(lookup_name). Программы, которые допускают в значениях lookup_name и kind только проверенные данные уязвимость не затрагивает... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57452
Ответить \| Правка \| Cообщить модератору

Оглавление

просто используешь построитель запросов и все Но нет, давайте клеить sql-строку, Аноним (1), 15:32 , 04-Июл-22, (1)

Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижд, Без аргументов (?), 15:50 , 04-Июл-22, (4) –6

У меня конструкции вида select func max text cast key as integer ,text valu, Аноним (6), 16:06 , 04-Июл-22, (6) –7

Кстати, там то же самое рядом через ORM, если это зло и намного хуже, то я даже , Аноним (6), 16:11 , 04-Июл-22, (8) –2

везде нифига не понятно интересно, как это будет работать, если строк миллион а, Без аргументов (?), 19:54 , 04-Июл-22, (25)

Прекрасно это работает Откуда там миллиону взяться, если поле с жсоном обновляе, Аноним (6), 20:19 , 04-Июл-22, (31)

Вот так и начинаются кадастрофы , ПерлухаБратуха (?), 04:46 , 05-Июл-22, (48)

В данном случае это костыль, позволяющий избежать бессмысленного усложнения схем, Аноним (6), 13:44 , 05-Июл-22, (53)

max int k for k in self relations - это какая-то хитрая чёрная магия Или про, Онаним (?), 22:11 , 04-Июл-22, (39)

Но если к max надо ещё условие присандалить, то будет получаться шиза вида sel, Онаним (?), 22:13 , 04-Июл-22, (40)
Это именно получение последнего по времени объекта из жсона, с ним можно работат, Аноним (6), 22:45 , 04-Июл-22, (43)

Я ничего тут не понял что там у вас про JSON Я говорю про человеческую нормализ, Без аргументов (?), 19:52 , 04-Июл-22, (24)

Да не, тут нормально всё Это json в sqlite, надо получить последнюю по времени , Аноним (6), 20:16 , 04-Июл-22, (30)

Ну я же говорю, что это детский садик Другое дело когда у вас оракл и 120ГБ ОЗУ, Без аргументов (?), 00:03 , 05-Июл-22, (45)

Так если бы там были какие-то данные, я бы как минимум не стал использовать жсон, Аноним (6), 00:11 , 05-Июл-22, (46)

ОРМ нужен не для того чтобы неадекватную архитектуру покрывать Если кто-то модел, GG (ok), 10:53 , 05-Июл-22, (49) –2

Хех, но ведь это же вообще не имеет отношения к ORM, претензия должна быть к SQL, Аноним (6), 14:39 , 05-Июл-22, (55)

На практике в нормализованных БД слишком много джойнов, даже если это база микро, Аноним (56), 03:13 , 06-Июл-22, (56) +1

Ха Да Дальше второй формы уходить - это уже для особых случаев Когда не жалко, Онаним (?), 00:03 , 08-Июл-22, (67)

Глаза чутка подвытекли Я уж за производительность этого добра даже не переживаю , Онаним (?), 22:07 , 04-Июл-22, (37) +1

Кстати, с производительностью всё удивительно хорошо в итоге Ну и оно же кэширу, Аноним (6), 22:52 , 04-Июл-22, (44)

Хотя конечно после cast key as integer там уже точно ничего не страшно, Онаним (?), 22:07 , 04-Июл-22, (38) +1
особенно тут , Аноним (61), 19:50 , 06-Июл-22, (61)

Разве что, чуточку Но в SQL это выглядело не лучше и позволяло выполнить подста, Аноним (6), 20:08 , 06-Июл-22, (62)

Не понял, ты на код глазами смотришь или чем Про возможность эскейпинга подстав, Аноним (68), 17:02 , 09-Июл-22, (68)

Да, я, например, хочу строить запросы одинаково на любом рантайме , Аноним (66), 18:38 , 07-Июл-22, (66)

Опять все путают ORM и Query Builder ORM нужна для того, чтобы автоматически орг, Аноним (7), 16:09 , 04-Июл-22, (7) +3

Вот весь прикол в том, что аналитические запросы есть смысл класть на нормальную, kai3341 (ok), 19:29 , 04-Июл-22, (18)

Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя , Аноним (19), 19:41 , 04-Июл-22, (19)

Пользуясь случаем, о каком двустороннем маппинге речь Об ActiveRecord Если да,, kai3341 (ok), 19:48 , 04-Июл-22, (23)

Поскольку тормозит применительно к питону - это его естественное состояние, всё , Онаним (?), 22:16 , 04-Июл-22, (41) –1

Давно уже есть, просто довольно нетривиально, GG (ok), 10:56 , 05-Июл-22, (50) –1

Меня тоже бомбило, но потом я попробовал алхимию https habr com ru post 55973, kai3341 (ok), 16:16 , 04-Июл-22, (9) –3

Если выходит плюс минус так же, зачем Чтобы что В базу оно все равно пойдет в , Аноним (12), 17:30 , 04-Июл-22, (12)

Как думаете, зачем я дал ссылку на статью Ответ -- в ней ответы на заданные вам, kai3341 (ok), 18:19 , 04-Июл-22, (13) –2

Расскажи пожалуйста подробно, зачем ты делаешь сложные операции Ты не думал что, Аноним (11), 16:53 , 04-Июл-22, (11) +2

Я работал разработчиком BI-отчетов и витрин данных Там на первом месте оптимиза, Без аргументов (?), 19:45 , 04-Июл-22, (20)

Вон из профессии, GG (ok), 10:57 , 05-Июл-22, (51) –3

Вся эта шелуха работает до тех пор, пока проект более менее не вырастет в большу, Без аргументов (?), 19:57 , 04-Июл-22, (27) –1

Но-но, у нас тут хайлоад, кек Орм в первую очередь, про удобство взаимодействия, Аноним (6), 20:51 , 04-Июл-22, (32)

Народ ныне очень любит ORM отрывать от логики объектов, превращая его в прослойк, Онаним (?), 21:59 , 04-Июл-22, (35) +2

Если у тебя набор данных сложнее товаров для витрины превращается в непроходимую, GG (ok), 11:00 , 05-Июл-22, (52) –1

Пока у тебя да, полтора товара на витрине, как правильно указали - тебе пойдёт и, Онаним (?), 22:03 , 04-Июл-22, (36)

А каким образом Вы боретесь с уязвимостями типа sql-иньекция , Аноним (17), 18:56 , 04-Июл-22, (17)

Проверить входные параметры, чтобы без точек с запятой и т п А вообще изкоробки, Без аргументов (?), 19:46 , 04-Июл-22, (21)

Любой драйвер БД умеет в подстановку значений Я рекомендую читать документацию, kai3341 (ok), 20:05 , 04-Июл-22, (28)

Нифига сколько неосиляторов в SQL минусонуло Ну я тоже с трудом въезжал Пока н, Без аргументов (?), 19:56 , 04-Июл-22, (26) –1

Не в этом дело, мне кажется Просто, комментатор слишком уж категоричен Ну и по, Аноним (6), 21:00 , 04-Июл-22, (33)

Ды не, ORM своё место Тут стоит для начала вернуться к тому, что ORM от SQL-inj, Онаним (?), 22:19 , 04-Июл-22, (42) +1

Скрыто модератором, васёк (?), 15:36 , 04-Июл-22, (2) –1

Скрыто модератором, Корец (?), 15:46 , 04-Июл-22, (3) +1
Скрыто модератором, Без аргументов (?), 15:51 , 04-Июл-22, (5)

Тест на имбецила в 21 веке Если такая ошибка находится, СРАЗУ же в отдел кадров, Аристарх (??), 18:46 , 04-Июл-22, (14) –2

Соглы , Без аргументов (?), 19:47 , 04-Июл-22, (22) +1

А как это можно использовать Не совсем понятно, куда нужно вбивать свой СКУЛь , Sergey (??), 18:46 , 04-Июл-22, (15)

В эксплоит Эксплоит тебе придеться купить , Аноним (63), 14:41 , 07-Июл-22, (63)

Нужно использовать подготовленные выражения и тогда sql-иньекции станут невозм, Аноним (17), 18:49 , 04-Июл-22, (16) +1
затонеphp tm Суть та же, криворучки - они повсюду , Онаним (?), 20:10 , 04-Июл-22, (29) –1
Sql injection в 2022 Достижение , Аноним (34), 21:51 , 04-Июл-22, (34) +1

Достижение, что наконец-то лидерство какого-то говнянеького фреймворка начинает , Аноним (63), 14:43 , 07-Июл-22, (64)

Перечисленные методы в нормальных руках при нормальных мозгах никогда не будут, Аноним (47), 04:32 , 05-Июл-22, (47) +1
А раст может как-то помочь Или в расте такие же дыры , Аноним (61), 14:06 , 05-Июл-22, (54)

От ошибок в бизнес-логике раст тоже не защитит Только от гонок и некоторых видо, Аноним (56), 03:25 , 06-Июл-22, (57)

Пока вебрендера не было, синхронизация вкладок не отваливалась , Аноним (6), 03:47 , 06-Июл-22, (58) +1

Ратс не нужен забудь про него плз , Аноним (60), 17:45 , 06-Июл-22, (60) +1

Так его так и не доснимали же , Аноним (63), 14:49 , 07-Июл-22, (65)

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

1. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (1), 04-Июл-22, 15:32

просто используешь построитель запросов и все. Но нет, давайте клеить sql-строку самому.

Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость в web-фреймворке Django, которая может привести к..." –6 +/–

Сообщение от Без аргументов (?), 04-Июл-22, 15:50

Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.

Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в web-фреймворке Django, которая может привести к..." –7 +/–

Сообщение от Аноним (6), 04-Июл-22, 16:06

У меня конструкции вида select(func.max(text("cast(key as integer)")),text('value')).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'")) всё норм, ничего не бомбит. Легко читается, даже легче, чем чисто sql. Вы что-то делаете не так.

Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в web-фреймворке Django, которая может привести к..." –2 +/–

Сообщение от Аноним (6), 04-Июл-22, 16:11

Кстати, там то же самое рядом через ORM, если это зло и намного хуже, то я даже не знаю ем тут помочь.
maxvalue = max([int(k) for k in self.relations])
return (maxvalue, self.relations[str(maxvalue)],)
а вот это orm-sql
return select(func.max(text("cast(key as integer)"))).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'"))
ну и где читаемее?

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Без аргументов (?), 04-Июл-22, 19:54

везде нифига не понятно.
интересно, как это будет работать, если строк миллион. а можно ли передать ему подсказку, в каких случаях использовать и какие индексы? нет.

Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 04-Июл-22, 20:19

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

Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от ПерлухаБратуха (?), 05-Июл-22, 04:46

> тут никаких проблем быть не может.
Вот так и начинаются кадастрофы.

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 05-Июл-22, 13:44

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

Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Онаним (?), 04-Июл-22, 22:11

max([int(k) for k in self.relations]) - это какая-то хитрая чёрная магия?
Или просто у нас все объекты предвгружены? А если их там 100500000 и каждый по килобайту размером?
В жирных специфично сдизайненных контейнерах ORM получится что-то типа self.relations.getMaxByKey('k'), тогда уже да, никакой магии, просто эксплицитная поддержка.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

40. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Онаним (?), 04-Июл-22, 22:13

Но если к max() надо ещё условие присандалить, то будет получаться шиза вида self.relations.getSubCollection(...conditions).getMaxByKey('k'), и это шиза.

Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 04-Июл-22, 22:45

Это именно получение последнего по времени объекта из жсона, с ним можно работать как с обычным хеш тейблом. Только возвращает всё текстом, мне не понравился вариант пропатчить на поддержку других типов. При необходимости, он сначала подгружается (целиком, там undefer, да). Изменений там от 0 до нескольких за месяц, содержит категории и ссылки на данные (которые не обязательно имеются в одной из таблиц). Мне показалось это подходящим для моих задач, но я так и не смог нагуглить ничего даже отдалённо похожего. Потом можно будет скидывать старые данные куда-нибудь на диск, это же жсон.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

24. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Без аргументов (?), 04-Июл-22, 19:52

Я ничего тут не понял что там у вас про JSON. Я говорю про человеческую нормализованную СУБД.
Но сразу виду обезьянокод. Какие-то двойные преобразования типов из текста в число. И еще макс можно сделать в одном запросе без вложения.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

30. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 04-Июл-22, 20:16

Да не, тут нормально всё. Это json в sqlite, надо получить последнюю по времени запись из поля с жсоном, ключи в котором принудительно конвертируются в текст, а значит, последнее значение из текстового ключа не получить. Я это к тому, что даже если ORM не позволяет решить не стандартную задачу адекватно (вставки text), это всё ещё вполне прилично выглядит в результате, куда лучше чем голый зубодробительный sql с сотней уязвимостей на запрос.

Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Без аргументов (?), 05-Июл-22, 00:03

Ну я же говорю, что это детский садик. Другое дело когда у вас оракл и 120ГБ ОЗУ и пол терабайта данных продаж с тысячи магазинов за пол года перелопатить надо.

Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 05-Июл-22, 00:11

Так если бы там были какие-то данные, я бы как минимум не стал использовать жсон в sqlite. Речь то совсем о другом. Я сомневаюсь, что перелопачивать пол терабайта надо прям на каждый запрос (для такого памяти маловато опять же), а значит, не исключено, что орм тут себя прекраснейшим образом проявит.

Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в web-фреймворке Django, которая может привести к..." –2 +/–

Сообщение от GG (ok), 05-Июл-22, 10:53

ОРМ нужен не для того чтобы неадекватную архитектуру покрывать.
Если кто-то модель данных спроектировал так что там без такого геморроя велосипедов запрос не сделать — надо гнать его ссаными тряпками из профессии и переделывать нормально, а не городить вот это вот.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

55. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 05-Июл-22, 14:39

Хех, но ведь это же вообще не имеет отношения к ORM, претензия должна быть к SQL (ну или к json).

Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Аноним (56), 06-Июл-22, 03:13

На практике в нормализованных БД слишком много джойнов, даже если это база микросервиса с довольно узкой зоной ответственности. Поэтому денормализация до второй формы
и требования к "академичности" пониже и код пожиже. Зато работает в рамках заданного SLA.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

67. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Онаним (?), 08-Июл-22, 00:03

Ха. Да. Дальше второй формы уходить - это уже для особых случаев. Когда не жалко.

Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Онаним (?), 04-Июл-22, 22:07

Глаза чутка подвытекли.
Я уж за производительность этого добра даже не переживаю.
Каждый вызов функции - это офигенные накладные расходы даже в компилируемом языке, чем и плохи все генераторы.
В компилируемых такие вещи хотя бы заинлайнить можно, но в скриптовых всё очень плохо.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

44. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 04-Июл-22, 22:52

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

Ответить | Правка | Наверх | Cообщить модератору

38. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Онаним (?), 04-Июл-22, 22:07

Хотя конечно после cast(key as integer) там уже точно ничего не страшно

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

61. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (61), 06-Июл-22, 19:50

> всё норм, ничего не бомбит
особенно тут:
> where(text("key and json_type(key) == 'integer' and type=='object'"))

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

62. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 06-Июл-22, 20:08

Разве что, чуточку. Но в SQL это выглядело не лучше и позволяло выполнить подстановку чего-нибудь нехорошего в 5 местах, а тут не получится.

Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (68), 09-Июл-22, 17:02

> позволяло выполнить подстановку чего-нибудь нехорошего
Не понял, ты на код глазами смотришь или чем? Про возможность эскейпинга подставляемых значений безо всяких ормов что-нибудь слышал?

Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (66), 07-Июл-22, 18:38

>Вы что-то делаете не так.
Да, я, например, хочу строить запросы одинаково на любом рантайме.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Уязвимость в web-фреймворке Django, которая может привести к..." +3 +/–

Сообщение от Аноним (7), 04-Июл-22, 16:09

Опять все путают ORM и Query Builder.
ORM нужна для того, чтобы автоматически организовать как сохранение данных дерева объектов в РСУБД, так и восстановление их из сохраненных в РСУБД данных в память. Такая своего рода сериализация, только в РСУБД, что позволяет эффективно организовать поиск по данным.
Query Builder нужен преимущественно как часть ORM для построения запросов для поиска нужных объектов в базе. При использовании Query Builder совместно с ORM важно, что они друг с другом интергрированы, и в качестве результата будут получены не сырые данные из базы, а нужный объект (или коллекция) со всеми вложенными объектами-коллекциями.
Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). Query Builder-ы иногда полезны, если запрос строится в зависимости от данных, запрошенным пользователем - без них довольно неудобно собирать запрос по частям (что-то в select, что-то в join, что-то в where и т.д.). Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy. С более примитивными QB, которые разработаны как вспомогательные части для ORM, будет проще генерировать запрос вручную.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

18. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от kai3341 (ok), 04-Июл-22, 19:29

> Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга).
> Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy
Вот весь прикол в том, что аналитические запросы есть смысл класть на нормальную ORM типа алхимии (DjangoORM говно). Так как статью (ниже) читать дело не царское, скажу тут. ORM позволяет сделать SQL-запрос модульным, позволяет повторно переиспользовать код через наследование или композицию. Также адекватная ORM умеет в вывод типов. Алхимия позволяет также реализовывать макросы, что удачно сочетается с выводом типов.
Ещё раз для тех, что не умеет читать: чмORM типа той же djangoORM дают преимущества только на простейших запросах (CRUD), но на аналитике дрыщут в лужу. Адекватные ORM типа алхимии дают как преимущества на банальном CRUD, так и на аналитике.
Ну и таки шо по производительности? Если верхний мозг не использовать, то алхимия тормозит, джанга чуть меньше тормозит. Если верхний мозг в наличии, то небольшие тормоза получаем на этапе инициализации, но в рантайме производительность мало отличается от raw sql. Вопросу уделено особое внимание в статье
А ещё про миграции никто не рассказал

Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (19), 04-Июл-22, 19:41

Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам нет, не совсем корректно называть это ORM.

Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от kai3341 (ok), 04-Июл-22, 19:48

> Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую
> гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам
> нет, не совсем корректно называть это ORM.
Пользуясь случаем, о каком двустороннем маппинге речь? Об ActiveRecord? Если да, то где он вообще есть для такого типа запросов?

Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в web-фреймворке Django, которая может привести к..." –1 +/–

Сообщение от Онаним (?), 04-Июл-22, 22:16

Поскольку тормозит применительно к питону - это его естественное состояние, всё вами описанное таки верно.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

50. "Уязвимость в web-фреймворке Django, которая может привести к..." –1 +/–

Сообщение от GG (ok), 05-Июл-22, 10:56

> нет двухстороннего маппинга
Давно уже есть, просто довольно нетривиально

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

9. "Уязвимость в web-фреймворке Django, которая может привести к..." –3 +/–

Сообщение от kai3341 (ok), 04-Июл-22, 16:16

> Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.
Меня тоже бомбило, но потом я попробовал алхимию: https://habr.com/ru/post/559738/
Выходит плюс/минус тот же самый синтаксис

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

12. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (12), 04-Июл-22, 17:30

Если выходит плюс минус так же, зачем? Чтобы что? В базу оно все равно пойдет в виде запроса. Лишь бы не писать SQL?
Из той же серии билдеры регулярных выражений (не путать с грамматиками). Иррациональный страх перед технологиями отцов-основателей? Своё лучше пахнет и делает волосы мягче и шелковистее?

Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость в web-фреймворке Django, которая может привести к..." –2 +/–

Сообщение от kai3341 (ok), 04-Июл-22, 18:19

Как думаете, зачем я дал ссылку на статью? Ответ -- в ней ответы на заданные вами вопросы и некоторые ещё не заданные

Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость в web-фреймворке Django, которая может привести к..." +2 +/–

Сообщение от Аноним (11), 04-Июл-22, 16:53

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

20. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Без аргументов (?), 04-Июл-22, 19:45

Я работал разработчиком BI-отчетов и витрин данных. Там на первом месте оптимизация и скорость выполнения. Как выше написали, ORM/QB детский садик работает для примитивных CRUD. Насчет мапинга не скажу, что удобнее. Точнее мапинг можно и из сырого запроса сделать без всякого блоатваре.

Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в web-фреймворке Django, которая может привести к..." –3 +/–

Сообщение от GG (ok), 05-Июл-22, 10:57

Вон из профессии

Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в web-фреймворке Django, которая может привести к..." –1 +/–

Сообщение от Без аргументов (?), 04-Июл-22, 19:57

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

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

32. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 04-Июл-22, 20:51

Но-но, у нас тут хайлоад, кек. Орм в первую очередь, про удобство взаимодействия с данными. У тебя есть инстанс чего-то, у него есть отношения с другими инстансами чего-то, на эти инстансы по различным правилам мапятся данные из таблиц, при совершении определённых операций могут случатся всевозможные полезные вещи с зависимостями в других таблицах. Когда он больше не нужен, он автоматически удаляешься из сессии (и её кэша).
Если шпарить sql, довольно быстро свихнёшься, а баги ловить ещё то удовольствие. Хотя ВЫГЛЯДИТ оно куда проще, ага. Стоимость намного выше в итоге, а ошибок и уязвимостей больше, сопровождение и доработка часто превращаются в практически не решаемую проблему.
Если, конечно, задача примитивная, там чем проще тем лучше, но когда связей много, или много условий, что и когда подгружать (у записи много данных, которые не нужны при наиболее частых обращениях) и обновлять, тут без орм никуда.
Я бы не стал прям так демонизировать орм, у этого подхода есть большой спектр задач, которые он способен решать весьма эффективно. В принципе, та же алхимия, может использоваться и без орм, если производительность и эффективность прямо так важны (что крайне маловероятно на практике), всё ещё остаётся много хорошего, что в ней есть помимо него.

Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в web-фреймворке Django, которая может привести к..." +2 +/–

Сообщение от Онаним (?), 04-Июл-22, 21:59

Народ ныне очень любит ORM отрывать от логики объектов, превращая его в прослойку между объектами и БД, и запихивая всю логику обработки полностью в рассредоточенные контроллеры. Вот с этого подхода лично меня коробит, это лишняя абстракция ради абстракции
Сам предпочитаю жирный ORM и контейнеры. Когда объекты из ORM рассованы по своим управляющим контейнерам, отвечающим за вгрузку-выгрузку, и когда они работают как полноценные объекты от логики - представляя собой не только тупой набор данных, но и всё, что нужно для их обработки. Из ORM у этих объектов "лишнего" только чтение-запись-удаление, в остальном они обычная часть логики обработки. Наличие контейнеров позволяет оптимизировать внутри контейнеров такие операции, как нестандартная выборка по условию, добавляя те части SQL, которые в самых дубовых 1-1 ORM'ах реализуются через одно место внешними запросами и впихиванием данных.

Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в web-фреймворке Django, которая может привести к..." –1 +/–

Сообщение от GG (ok), 05-Июл-22, 11:00

Если у тебя набор данных сложнее товаров для витрины превращается в непроходимую кучу — это исключительно твоя проблема.
И заключается она не в ОРМ, а в том что ты себя возомнил архитектором, когда на самом деле тебе и бейджик кодера-юниора снимать рано ещё.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

36. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Онаним (?), 04-Июл-22, 22:03

Пока у тебя да, полтора товара на витрине, как правильно указали - тебе пойдёт и один запрос на объект.
Но когда у тебя хотя бы 100M записей в день начнёт капать, которые ещё надо с другими объектами связывать, тебе так или иначе их придётся пакетной обработкой проходить...

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

17. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (17), 04-Июл-22, 18:56

А каким образом Вы боретесь с уязвимостями типа "sql-иньекция"?

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Без аргументов (?), 04-Июл-22, 19:46

Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще изкоробки обычно есть постановка параметров (через ???), которая проверяет.

Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от kai3341 (ok), 04-Июл-22, 20:05

> Проверить входные параметры, чтобы без точек с запятой и т.п. А вообще
> изкоробки обычно есть постановка параметров (через ???), которая проверяет.
Любой драйвер БД умеет в подстановку значений. Я рекомендую читать документацию

Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимость в web-фреймворке Django, которая может привести к..." –1 +/–

Сообщение от Без аргументов (?), 04-Июл-22, 19:56

Нифига сколько неосиляторов в SQL минусонуло. Ну я тоже с трудом въезжал. Пока не научился делать пятэтажные запросы и такие, и сякие, с динамической группировкой и фильтрами на тысячу строк кода. А бывает, когда в СУБД надо передать хинты, т.к. оптимизатор не экстрасенс на все случаи жизни

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

33. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (6), 04-Июл-22, 21:00

Не в этом дело, мне кажется. Просто, комментатор слишком уж категоричен. Ну и потом, я слабо себе представляю, как можно использовать ORM, без чёткого понимания, что и зачем он генерирует.

Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Онаним (?), 04-Июл-22, 22:19

Ды не, ORM своё место. Тут стоит для начала вернуться к тому, что ORM от SQL-injection как правило не спасает, поскольку часть вещей на ORM всё равно нереализуема и сваливается к передаче в ORM кусков запроса. Самый простой пример - когда надо вгрузить объекты, подходящие по длинным цепочкам пропертей других объектов. Нет, можно всё повгружать "по порядочку", но когда у тебя на каждом шаге по миллиону записей - это становится немножко накладно.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

2. Скрыто модератором –1 +/–

Сообщение от васёк (?), 04-Июл-22, 15:36

и питоша тоже? я думал только Сишка дырявая

Ответить | Правка | Наверх | Cообщить модератору

3. Скрыто модератором +1 +/–

Сообщение от Корец (?), 04-Июл-22, 15:46

>я думал только Сишка дырявая
Не переживай, дырявым может быть код на любом языке. Даже на том самом ;)

Ответить | Правка | Наверх | Cообщить модератору

5. Скрыто модератором +/–

Сообщение от Без аргументов (?), 04-Июл-22, 15:51

А у тебя минимум 4 дырки.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

14. "Уязвимость в web-фреймворке Django, которая может привести к..." –2 +/–

Сообщение от Аристарх (??), 04-Июл-22, 18:46

> подстановку своего SQL-кода
Тест на имбецила в 21 веке. Если такая ошибка находится, СРАЗУ же в отдел кадров на увольнение по собственному!

Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Без аргументов (?), 04-Июл-22, 19:47

Соглы.

Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Sergey (??), 04-Июл-22, 18:46

А как это можно использовать ? Не совсем понятно, куда нужно вбивать свой СКУЛь запрос ;(

Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (63), 07-Июл-22, 14:41

В эксплоит. Эксплоит тебе придеться купить.

Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Аноним (17), 04-Июл-22, 18:49

Нужно использовать "подготовленные выражения" и тогда sql-иньекции станут невозможны.

Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость в web-фреймворке Django, которая может привести к..." –1 +/–

Сообщение от Онаним (?), 04-Июл-22, 20:10

затонеphp(tm)
Суть та же, криворучки - они повсюду.

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Аноним (34), 04-Июл-22, 21:51

Sql injection в 2022? Достижение!

Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (63), 07-Июл-22, 14:43

Достижение, что наконец-то лидерство какого-то говнянеького фреймворка начинает шататься.
Вопрос только, что где что-то можное современное молодежное с асинхроньщиной и поэтессами =)

Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Аноним (47), 05-Июл-22, 04:32

Перечисленные методы в нормальных руках (при нормальных мозгах) никогда не будут принимать непроверенные параметры. Расходимся посоны...

Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (61), 05-Июл-22, 14:06

> непроверенные внешние данные
А раст может как-то помочь? Или в расте такие же дыры?

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (56), 06-Июл-22, 03:25

От ошибок в бизнес-логике раст тоже не защитит. Только от гонок и некоторых видов утечек в куче.

Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Аноним (6), 06-Июл-22, 03:47

Пока вебрендера не было, синхронизация вкладок не отваливалась.

Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в web-фреймворке Django, которая может привести к..." +1 +/–

Сообщение от Аноним (60), 06-Июл-22, 17:45

Ратс не нужен забудь про него плз.

Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимость в web-фреймворке Django, которая может привести к..." +/–

Сообщение от Аноним (63), 07-Июл-22, 14:49

Так его так и не доснимали же ...

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
Сообщение от Аноним (1), 04-Июл-22, 15:32
просто используешь построитель запросов и все. Но нет, давайте клеить sql-строку самому.
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Уязвимость в web-фреймворке Django, которая может привести к..."	–6 +/–
	Сообщение от Без аргументов (?), 04-Июл-22, 15:50
	Меня, как опытному в SQL, люто бомбит от использования ORM, в котором надо трижды извратиться, сделав более сложночитаемый код, чтобы сделать более менее сложную операцию, сильно связывает руки. Но, конечно, за такие уязвимости и актисанитарию пороть надо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Уязвимость в web-фреймворке Django, которая может привести к..."	–7 +/–
	Сообщение от Аноним (6), 04-Июл-22, 16:06
	У меня конструкции вида select(func.max(text("cast(key as integer)")),text('value')).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'")) всё норм, ничего не бомбит. Легко читается, даже легче, чем чисто sql. Вы что-то делаете не так.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Уязвимость в web-фреймворке Django, которая может привести к..."	–2 +/–
	Сообщение от Аноним (6), 04-Июл-22, 16:11
	Кстати, там то же самое рядом через ORM, если это зло и намного хуже, то я даже не знаю ем тут помочь. maxvalue = max([int(k) for k in self.relations]) return (maxvalue, self.relations[str(maxvalue)],) а вот это orm-sql return select(func.max(text("cast(key as integer)"))).select_from(cls, func.json_tree(cls.relations)).where(text("key and json_type(key) == 'integer' and type=='object'")) ну и где читаемее?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Без аргументов (?), 04-Июл-22, 19:54
	везде нифига не понятно. интересно, как это будет работать, если строк миллион. а можно ли передать ему подсказку, в каких случаях использовать и какие индексы? нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 04-Июл-22, 20:19
	Прекрасно это работает. Откуда там миллиону взяться, если поле с жсоном обновляется пару раз в месяц? Причём, используется всегда только последнее значение, старые данные остаются для истории. Тут никаких проблем быть не может.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от ПерлухаБратуха (?), 05-Июл-22, 04:46
	> тут никаких проблем быть не может. Вот так и начинаются кадастрофы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 05-Июл-22, 13:44
	В данном случае это костыль, позволяющий избежать бессмысленного усложнения схемы и заполнения таблиц неконсистентными бесполезными данными. Никогда не поздно мигрировать на новую версию, при необходимости, однако, до сих пор не вижу ровно никаких предпосылок.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Онаним (?), 04-Июл-22, 22:11
	max([int(k) for k in self.relations]) - это какая-то хитрая чёрная магия? Или просто у нас все объекты предвгружены? А если их там 100500000 и каждый по килобайту размером? В жирных специфично сдизайненных контейнерах ORM получится что-то типа self.relations.getMaxByKey('k'), тогда уже да, никакой магии, просто эксплицитная поддержка.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	40. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Онаним (?), 04-Июл-22, 22:13
	Но если к max() надо ещё условие присандалить, то будет получаться шиза вида self.relations.getSubCollection(...conditions).getMaxByKey('k'), и это шиза.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 04-Июл-22, 22:45
	Это именно получение последнего по времени объекта из жсона, с ним можно работать как с обычным хеш тейблом. Только возвращает всё текстом, мне не понравился вариант пропатчить на поддержку других типов. При необходимости, он сначала подгружается (целиком, там undefer, да). Изменений там от 0 до нескольких за месяц, содержит категории и ссылки на данные (которые не обязательно имеются в одной из таблиц). Мне показалось это подходящим для моих задач, но я так и не смог нагуглить ничего даже отдалённо похожего. Потом можно будет скидывать старые данные куда-нибудь на диск, это же жсон.
	Ответить \| Правка \| К родителю #39 \| Наверх \| Cообщить модератору


	24. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Без аргументов (?), 04-Июл-22, 19:52
	Я ничего тут не понял что там у вас про JSON. Я говорю про человеческую нормализованную СУБД. Но сразу виду обезьянокод. Какие-то двойные преобразования типов из текста в число. И еще макс можно сделать в одном запросе без вложения.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	30. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 04-Июл-22, 20:16
	Да не, тут нормально всё. Это json в sqlite, надо получить последнюю по времени запись из поля с жсоном, ключи в котором принудительно конвертируются в текст, а значит, последнее значение из текстового ключа не получить. Я это к тому, что даже если ORM не позволяет решить не стандартную задачу адекватно (вставки text), это всё ещё вполне прилично выглядит в результате, куда лучше чем голый зубодробительный sql с сотней уязвимостей на запрос.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Без аргументов (?), 05-Июл-22, 00:03
	Ну я же говорю, что это детский садик. Другое дело когда у вас оракл и 120ГБ ОЗУ и пол терабайта данных продаж с тысячи магазинов за пол года перелопатить надо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 05-Июл-22, 00:11
	Так если бы там были какие-то данные, я бы как минимум не стал использовать жсон в sqlite. Речь то совсем о другом. Я сомневаюсь, что перелопачивать пол терабайта надо прям на каждый запрос (для такого памяти маловато опять же), а значит, не исключено, что орм тут себя прекраснейшим образом проявит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Уязвимость в web-фреймворке Django, которая может привести к..."	–2 +/–
	Сообщение от GG (ok), 05-Июл-22, 10:53
	ОРМ нужен не для того чтобы неадекватную архитектуру покрывать. Если кто-то модель данных спроектировал так что там без такого геморроя велосипедов запрос не сделать — надо гнать его ссаными тряпками из профессии и переделывать нормально, а не городить вот это вот.
	Ответить \| Правка \| К родителю #30 \| Наверх \| Cообщить модератору


	55. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 05-Июл-22, 14:39
	Хех, но ведь это же вообще не имеет отношения к ORM, претензия должна быть к SQL (ну или к json).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Уязвимость в web-фреймворке Django, которая может привести к..."	+1 +/–
	Сообщение от Аноним (56), 06-Июл-22, 03:13
	На практике в нормализованных БД слишком много джойнов, даже если это база микросервиса с довольно узкой зоной ответственности. Поэтому денормализация до второй формы и требования к "академичности" пониже и код пожиже. Зато работает в рамках заданного SLA.
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	67. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Онаним (?), 08-Июл-22, 00:03
	Ха. Да. Дальше второй формы уходить - это уже для особых случаев. Когда не жалко.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Уязвимость в web-фреймворке Django, которая может привести к..."	+1 +/–
	Сообщение от Онаним (?), 04-Июл-22, 22:07
	Глаза чутка подвытекли. Я уж за производительность этого добра даже не переживаю. Каждый вызов функции - это офигенные накладные расходы даже в компилируемом языке, чем и плохи все генераторы. В компилируемых такие вещи хотя бы заинлайнить можно, но в скриптовых всё очень плохо.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	44. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 04-Июл-22, 22:52
	Кстати, с производительностью всё удивительно хорошо в итоге. Ну и оно же кэшируется. С диска долго, в памяти нормально, никаких претензий. Проблемы начинаются, когда генерирует что-то не то.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Уязвимость в web-фреймворке Django, которая может привести к..."	+1 +/–
	Сообщение от Онаним (?), 04-Июл-22, 22:07
	Хотя конечно после cast(key as integer) там уже точно ничего не страшно
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	61. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (61), 06-Июл-22, 19:50
	> всё норм, ничего не бомбит особенно тут: > where(text("key and json_type(key) == 'integer' and type=='object'"))
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	62. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (6), 06-Июл-22, 20:08
	Разве что, чуточку. Но в SQL это выглядело не лучше и позволяло выполнить подстановку чего-нибудь нехорошего в 5 местах, а тут не получится.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (68), 09-Июл-22, 17:02
	> позволяло выполнить подстановку чего-нибудь нехорошего Не понял, ты на код глазами смотришь или чем? Про возможность эскейпинга подставляемых значений безо всяких ормов что-нибудь слышал?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (66), 07-Июл-22, 18:38
	>Вы что-то делаете не так. Да, я, например, хочу строить запросы одинаково на любом рантайме.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	7. "Уязвимость в web-фреймворке Django, которая может привести к..."	+3 +/–
	Сообщение от Аноним (7), 04-Июл-22, 16:09
	Опять все путают ORM и Query Builder. ORM нужна для того, чтобы автоматически организовать как сохранение данных дерева объектов в РСУБД, так и восстановление их из сохраненных в РСУБД данных в память. Такая своего рода сериализация, только в РСУБД, что позволяет эффективно организовать поиск по данным. Query Builder нужен преимущественно как часть ORM для построения запросов для поиска нужных объектов в базе. При использовании Query Builder совместно с ORM важно, что они друг с другом интергрированы, и в качестве результата будут получены не сырые данные из базы, а нужный объект (или коллекция) со всеми вложенными объектами-коллекциями. Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). Query Builder-ы иногда полезны, если запрос строится в зависимости от данных, запрошенным пользователем - без них довольно неудобно собирать запрос по частям (что-то в select, что-то в join, что-то в where и т.д.). Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy. С более примитивными QB, которые разработаны как вспомогательные части для ORM, будет проще генерировать запрос вручную.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	18. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от kai3341 (ok), 04-Июл-22, 19:29
	> Для аналитических же запросов - в которых и нужны более-менее сложные операции - ORM вообще не применимы (поскольку тут нет двухстороннего маппинга). > Но тут подойдет только мощный query builder, не уступающий написанию запроса вручную, типа SQLAlchemy Вот весь прикол в том, что аналитические запросы есть смысл класть на нормальную ORM типа алхимии (DjangoORM говно). Так как статью (ниже) читать дело не царское, скажу тут. ORM позволяет сделать SQL-запрос модульным, позволяет повторно переиспользовать код через наследование или композицию. Также адекватная ORM умеет в вывод типов. Алхимия позволяет также реализовывать макросы, что удачно сочетается с выводом типов. Ещё раз для тех, что не умеет читать: чмORM типа той же djangoORM дают преимущества только на простейших запросах (CRUD), но на аналитике дрыщут в лужу. Адекватные ORM типа алхимии дают как преимущества на банальном CRUD, так и на аналитике. Ну и таки шо по производительности? Если верхний мозг не использовать, то алхимия тормозит, джанга чуть меньше тормозит. Если верхний мозг в наличии, то небольшие тормоза получаем на этапе инициализации, но в рантайме производительность мало отличается от raw sql. Вопросу уделено особое внимание в статье А ещё про миграции никто не рассказал
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от Аноним (19), 04-Июл-22, 19:41
	Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам нет, не совсем корректно называть это ORM.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Уязвимость в web-фреймворке Django, которая может привести к..."	+/–
	Сообщение от kai3341 (ok), 04-Июл-22, 19:48
	> Да, ORM-функциональность Алхимии можно использовать и с аналитикой, осуществляя автоматическую > гидрацию read models. Но поскольку двустороннего маппинга тут по очевидным причинам > нет, не совсем корректно называть это ORM. Пользуясь случаем, о каком двустороннем маппинге речь? Об ActiveRecord? Если да, то где он вообще есть для такого типа запросов?
	Ответить \| Правка \| Наверх \| Cообщить модератору