нельзя закидывать данные из *непроверенного* источника...

Любой источник непроверенный

Любой источник непроверенный

даже твой код?

даже твой код?

Именно

@worlak2 Это не select, а create table.

Именно

пожалуйста не неси хуйни, ладно?

@worlak2 Это не select, а create table.

Ну ладно

пожалуйста не неси хуйни, ладно?

Вы хотите поспорить насчёт овасп топ?

Или скл инъекций ?

На селекте используется placeholder

Или скл инъекций ?

я бы послушал

спорьте

Изначально это является плохим ходом, потому что данные туда могут попасть разные и при недостаточной обработке будут не лучшие результаты из-за такой *хуйни* которую вы делаете

спорьте

https://memepedia.ru/wp-content/uploads/2018/01/j8ufbixp.jpeg

https://memepedia.ru/wp-content/uploads/2018/01/j8ufbixp.jpeg

именно)

Вы хотите поспорить насчёт овасп топ?

нет, я хочу сказать что ты идиот и не понимаешь разницы между unsafe данными и данными, полученными на основе твоего же кода (как-то структура твоего же класса) и таки если мы говорим про аля ORM и построение запроса, то ты ну никак не уйдешь от генерации запроса строковыми операциями.

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

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

Изначально это является плохим ходом, потому что данные туда могут попасть разные и при недостаточной обработке будут не лучшие результаты из-за такой *хуйни* которую вы делаете

а по твоему ORM работают не так?

нет, я хочу сказать что ты идиот и не понимаешь разницы между unsafe данными и данными, полученными на основе твоего же кода (как-то структура твоего же класса) и таки если мы говорим про аля ORM и построение запроса, то ты ну никак не уйдешь от генерации запроса строковыми операциями.

Я хотел отметить что данный подход является не самым подходящем, так как если вы работаете с командой и кто-то недобросовестный передаст туда что-то, то выйдет не самое подходящее в связи с чем подобные данные необходимо было бы предварительно обработать, дабы избежать всяческих ошибок. Меня обеспокоило то, что вы 100 процентов доверяете тому что написано, не предусматривая что с этим кто-то может еще и работать

ну передаст, это вылезет в тестах

а по твоему ORM работают не так?

так, но я предполагаю там минимальные обработки присутствуют

вообще конечно имено колонок надо нормализовать, да

даже твой код?

иногда и из кода лучше не надо несекьюрно инъектить, сегодня доверенный, а завтра вызов твоего метода кто-нибудь к своему эндпоинту прикрутил

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

вот об этом и речь была

иногда и из кода лучше не надо несекьюрно инъектить, сегодня доверенный, а завтра вызов твоего метода кто-нибудь к своему эндпоинту прикрутил

вот про это и писал выше.

но от формата никуда не денешься

ну ясное дело

об этом и речь

просто нужно всегда типобезопасный формат делать со всеми эскейпами

или о чём срач?

просто нужно всегда типобезопасный формат делать со всеми эскейпами

о create table с форматом

срачь об безапеляционном заявлении "никогда не используйте форматные строки для построения SQL"

F

вообще, create table надо просто руками писать, а не долбить генерацию

но от формата никуда не денешься

моя ошибка что сказал про формат не рассмотрев до конца запрос, мельком пока листал. Показалось что это селект или како либо инсерт. Поэтому сделал замечание, что такие вещи в формат не стоит пихать

ну, без слоя эскейпинга и правда не надо использовать

просто нужно всегда типобезопасный формат делать со всеми эскейпами

+

я думаю, вы к словам придираетесь, короч

вообще я склонен согласиться - нефиг юзать формат для SQL.

вообще я склонен согласиться - нефиг юзать формат для SQL.

тут есть нюансы, для новичков - да это табу. но ты никуда не денешься от формата в том или ином виде, например если тебе нужно собрать динамический запрос руками с идентификатормами получаемыми программно. и если, к примеру, psycopg2 тебе предоставляет безопасный query builder, который по факту тот же формат на стероидах, то другие движки - нет

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

тут есть нюансы, для новичков - да это табу. но ты никуда не денешься от формата в том или ином виде, например если тебе нужно собрать динамический запрос руками с идентификатормами получаемыми программно. и если, к примеру, psycopg2 тебе предоставляет безопасный query builder, который по факту тот же формат на стероидах, то другие движки - нет

ну если только динамический квери. Но это потом очень тяжко читать

у меня щас в проекте db.query(some_wrapper%(base_query % condition), (blabla, …))

ты в первую очередь должен понимать откуда данные приходят.

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

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

и если у тебя программист-зловред в команде засунул SQL-inj намеренно, то ты ну никак от этого не защитишься, кроме код-ревью и тестов.

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

да, или если ты к примеру запрос по кусам собираешь. есть разница между данными, которые ты контролируешь и которые нет.

сорян, за грубость в отношении безапеляционных заявлений.

сорян, за грубость в отношении безапеляционных заявлений.

Рад что мы пришли к общему выводу, просто поняли неправильно друг друга

Подскажите, а нормальная ли практика вьюхи которые должны быть закрыть паролем наследовать от LoginRequiredMixin ?

или есть более адекватное решение

Подскажите, а нормальная ли практика вьюхи которые должны быть закрыть паролем наследовать от LoginRequiredMixin ?

ты бы хоть стек технологий указал

я ж предлагал мидлварю

или не тебе?

Django

я ж предлагал мидлварю

мне )

я просто читаю

и смотрю)

Подскажите, а нормальная ли практика вьюхи которые должны быть закрыть паролем наследовать от LoginRequiredMixin ?

Нормальная

Но закрыты паролем это скорее про SuperuserRequiredMixin

я только изучаю Python и Django так что, естественно не все понимаю и не все возможности вижу.

Нормальная

Мне надо что бы сайт был доступен только после авторизации пользователя

Если весь сайт, то лучше мидлварь

Если весь сайт, то лучше мидлварь

а где про это почитать ?

Мне нравятся относительные импорты в пределах пакета

сомневаюсь что до меня этого не делали)

а где про это почитать ?

https://docs.djangoproject.com/en/2.2/topics/http/middleware/

сомневаюсь что до меня этого не делали)

Там десять строк, конечно делали

Я даже ссылку давал

Там десять строк, конечно делали

Получается пишешь прослойку, и она будет проверять все, а все остальное пишешь словно и не требуется праоль ?

блин, клёвое слово «праоль»

это мама Оли

или нескольких Оль

(или папа)

ваша праоль скомпрометирована

срочно поменяйте праоль

"Оля! Что там твоя мама опять в интернете творит?!"

может это глагол

а может, глагол с ошибкой

и правильно писать "прооль"