Блин, классный пост, но боюсь, что потонет в общей ленте.. А для переноса в сообщество IT юмора у тебя не хватает рейтинга, нужно 250. Обидно :(
раскрыть ветку (54)
А сразу нельзя в нужное сообщество поместить? Ну или модератора тогда уж позвать.
В общей ленте он утонет совершенно заслуженно.
раскрыть ветку (26)
Я как раз адмодер в том сообществе, но у человека не хватает рейтинга для переноса. В сообществе настроено ограничение на минимальное количество рейтинга у пользователя в 250.
раскрыть ветку (25)
раскрыть ветку (23)
@stavropol, категорически приветствую. Может отменим порог для пользователей в 250 рейтинга? Мне кажется, что проблем не должно возникнуть.
раскрыть ветку (22)
Думаю, не стоит этого делать. Когда это сообщество только появилось, сюда стали новореги лить всякое гуано, пришлось включить премодерацию. Потом, из-за того, что я не мог оперативно посты модерировать, пришлось сделать порог 250 рейтинга. Зато соотношение постов к количеству подписчиков у нас одно из самых лучших (если не лучшее). 250 не такой уж большой рейтинг. Если не ошибаюсь, при регистрации дают 100 или 200.
Если есть другие аргументы в пользу отмены, пишите.
@Sonad, @EHOTnOTACKYH
раскрыть ветку (18)
Хм, могу в пользу этого решения высказать то, что я нахожусь на сайте довольно часто и могу оперативно реагировать на неформат. С другой стороны, порог в 250 рейтинга действительно не так высок, а я весьма и весьма редко сталкиваюсь с постами в общей ленте, которые нельзя перенести из-за рейтинга.
UPD: Заметил, что пост был перенесен в соо. Администраторы могут переносить посты минуя ограничение или оно просто на время было снято и потом сразу возвращено?
раскрыть ветку (12)
раскрыть ветку (11)
Блин, я уж понадеялся, что у вас больше прав на это дело. Жаль.
В целом, я согласен, что ради нескольких постов в месяц нет смысла снимать ограничение. За пост обидно было..
раскрыть ветку (10)
раскрыть ветку (9)
А почему адмодеры не могут по собственному желанию переносить посты, игнорируя рейтинг? Может тогда позвать саптеха и попросить сделать ограничение именно для ТС-ов, а перенос адмодерами сделать без ограничений? С другой стороны не так уж и сложно на 10 секунд снять и убрать ограничение, да и подобных постов крайне мало.
раскрыть ветку (7)
А почему адмодеры не могут по собственному желанию переносить посты, игнорируя рейтинг?
Полностью поддерживаю, это весьма странно. @SupportCommunity, было бы здорово иметь такую возможность.
С другой стороны не так уж и сложно на 10 секунд снять и убрать ограничение
У рядового модератора сообщества такаой функции по понятным причинам нет, увы. Только у администраторов.
раскрыть ветку (6)
Привет! Кнопка у вашего админа есть, поэтому очень советую обращаться к нему с этим вопросом и уточнять для чего такое ограничение и нужно ли оно ещё
раскрыть ветку (4)
Приветствую!
поэтому очень советую обращаться к нему с этим вопросом и уточнять для чего такое ограничение и нужно ли оно ещё
Ну, этот вопрос мы уже обсудили)
Кнопка у вашего админа есть
А про это не знал. Позвольте еще несколько уточнений:
1) У админа есть кнопка, чтобы перетаскивать пост даже в тех случаях, когда у пользователя не хватает рейтинга? Просто выше описывалось, что был использован легкий хак в виде отключения ограничения на время.
2) В чем минусы разрешения всему админскому составу перетаскивать посты без учета рейтинга? Просто больше похоже, что эта система должна ограничивать авторов, а не руководство.
раскрыть ветку (3)
Нет, у админа нет кнопки перетаскивать всё на свете куда угодно. Это было бы странно давать ее одним, но не давать другим
У админа есть целый кабинет настроек, одна из них - выбор минимального порога рейтинга.
Вы даже уже в этой ветке обсудили этот порог #comment_197082685 поэтому я не очень понимаю, зачем я здесь)
У админов настройки есть, они могут ими пользоваться. Если админы считают, что нужно так, а не иначе, я не могу диктовать условия. Отдельные настройки для каждой роли имели бы смысл, если бы согласование админа в этом вопросе не требуется, но оно требуется! И он уже высказал своё мнение и попросил привести аргументы против.
Думаю, он хочет услышать ваши аргументы, а не призыв Сапком. Паучье чутье подсказывает именно это
раскрыть ветку (2)
Я отвлеку вас в последний раз.
Возможно, я где-то вас недопонял, но у меня сложилось впечатление, что мы говорим о разных вещах. Установка минимального порога вполне понятна, именно это мы и обсудили с админом сообщества. Тут вопросов никаких нет, я согласен с его аргументами и разделяю их.
Мне немного непонятно другое, почему это ограничение распространяется на возможность перетаскивания поста администрацией сообщества? Да, мы не хотим, чтобы к нам постили пользователи с рейтингом меньше 250. Но если такой пользователь запостил годноту в общую ленту, почему у нас нет права перетащить его пост в соо игнорируя это правило, мы же сами его и установили. Почему приходится даже самому админу проделывать финт ушами в виде отключения этого порога на время?
раскрыть ветку (1)
Пост может попасть в сообщество тремя способами: тс сам его туда публикует, его переносит адмодер, его переносит модератор. И во всех трёх случаях поведение конструктора постов учитывает установленный порог.
Почему учитывает? Потому что когда админ его устанавливает, он предусматривает все ситуации. Все три варианта попадания постов в сообщество. Значит ЕМУ нужно, чтобы этот порог был
Из сообщества пост можно вынести в течение недели с момента публикации. Можно не устанавливать порог вхождения, но выносить посты, которые кажутся неподходящими потом. Можно? Можно. Либо можно установить порог, меньше которого посты в сообщество попадать на будут. Можно? Можно.
Модерация в данном случае имеет два варианта реализации и только админ решает, какой ближе именно ему. Если он решил, что лучше порог - мы это принимаем. Если он решил,что лучше выносить - тоже понятно
Я больше того скажу, у модераторов ресурса тоже нет права игнорировать это ограничение. Да, мы тоже не можем перенести пост в сообщество, если админ установил в него порог. Админы самые главные и если они считают порог необходимым, мы учитываем это решение
Копия @SvSvarog
Я согласен, 250 не настолько большой рейтинг, и даже при этом ограничении умудряются часто заливать откровенную дичь. Да, @Sonad часто реагирует быстрее нас, но не всегда же. Во всяком случае, я пусть и не часто, но довольно регулярно выношу посты в общую ленту.
Потом, из-за того, что я не мог оперативно посты модерировать, пришлось сделать порог 250 рейтинга.
Лучше добавить модераторов.
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
На полтора поста в день смысл кучу модераторов назначать? Хотя, если открыть всем доступ, шлак лить начнут, придется как в свежем сидеть. Только есть ли смысл в этом.
раскрыть ветку (7)
Настолько проффесиональный, что без тегов не понятен, хотя с t-sql работаю уже 13 лет.
Сначала думал, что ему знания sql привили
раскрыть ветку (6)
Что происходит в комиксе? После обновления(прививки) SQL исчез рабочий стол? Такое случается?
раскрыть ветку (5)
В sql есть такая тема как инъекция. Это внедрение вредоносного кода в текстовые поля в интерфейсе.
Например, если клиент, веб-сервер или сервер приложений сам формирует исполняемый sql код, а не использует процедуры, или же если в процедурах sql на основе текстовых данных от клиента формируется динамический код. И при этом доступ к БД настроен так что всем всё можно. То есть риск инъекций.
Например, у тебя в клиенте есть следующий код:
sql="select * from table1 where id='"+idValue+";'";
Где sql - строка с кодом, который выполняется на сервере sql, a idValue - значение из текстового поля, который вводит пользователь
Тогда злоумышленник может сделать так, что в переменной sql будет, например, храниться:
select * from table1 where id=''; drop table table1; select ''
Шутка в том, что ему с помощью инъекции запустили drop table(команда удаления таблицы), по английски table - это как таблица, так и стол.
Вообще-то SQL-ъекции - это как раз про криворукость бэкендеров. Причем тут разработчики БД?
раскрыть ветку (15)
При том, что это не бэкендеров дело писать запросы и хранимки с ними. Только плиз, не надо писать про орм.
раскрыть ветку (14)
В смысле не бэкендеров? А чьё же? Фронтендеров? Или бэку SQL специальные люди писать должны для взаимодействия с БД? Вот это сегрегация!
Если у тебя в проекте такая ДЫРИЩА в бэке, что туда пользователь может просунуть свой... SQL-запрос, то тут не DBA виноват, а косорукий программист, который не понимает, что такое валидация параметров, как правильно экранировать входные данные в SQL и как правильно пользоваться API используемой БД.
раскрыть ветку (13)
Как-то у тебя все так намешано, что я уже пожалел что взялся отвечать. Приплел зачем то ДБА, хотя они тут вообще не при чем. Почему то предположил что должны писать фронтендеры, хотя в посте прямо указано кто это должен делать (да и в твоем первом сообщении тоже). Упомянули какие то АПИ к базам данных, которого в некоторых случаях просто не существует. У СУБД Оракл такого точно нет. И что не так в специальных людях для написания логики работы с данными, я так и не понял. Для меня слово "сегрегация" не ругательное. Или разделение на бек и фронтенд - тоже зло?
раскрыть ветку (12)
Ок, фронтендера я помянул в сердцах. Но в посте-то речь про SQL-инъекции. Причем тут логика внутри СУБД?
Делать так, чтобы SQL-инъекции были невозможными - это задача бэкенд-разработчика. АПИ у БД, конечно же, есть у любой. Для чего бы кому-то пригодилась база данных без интерфейса? На всякий случай напомню, что интерфейс - это не обязательно что-то графическое. В данном случае API - это программный интерфейс и работать он может через вызовы функций динамической библиотеке или через промежуточный биндинг к тому или иному языку. В конечном итоге почти любая современная БД обычно предосталяет API через TCP-соединение.
Но давайте всё же подумаем какие такие SQL-инъекции могут оказаться на совести разработчика БД... Вообще тот еще вопрос что разрабатывает этот разработчик в отрыве от бэкенда. Струкутуру? Связи? Индексы? Ок. Засовывает бизнес логику в хранимые процедуры (такая себе идея, конечно, особенно если это все живёт вне системы контроля версий)?
Короче, если пользователи могут подать куда-то на вход данные, которые поломают нормальную работу SQL сформировав недопустимый запрос, то это проблема бэкенд разработчика, который неправильно работает с API БД или техлида проекта, который допустил прямой доступ пользователей к выполнению запросов в БД, а разработчик хранимок наваял там такой логики, что без должного экранирования наконкатенировал там запросов, способных при должной инъекции поломать всё.
раскрыть ветку (11)
Что живет вне системы контроля версий, а что внутри, вообще не должно влиять на архитектуру систему, это сугубо проблемы разрабов и и удобство их работы. Писать говно код потому что так удобнее, как раз таки и есть так себе идея. Код из хранимок вполне нормально хранится в системах контроля версий, потому что представляет собой обычный текст.
Ничто лучше субд не справляется с работой с данными, поэтому всю логику работы с данными как раз таки должно хранить на уровне субд, если эта логика обещает быть сколько-нибудь сложной (а она почти всегда становится такой, когда у заказчика возникает больше хотелок). А ведь есть еще процессы, который должны запускаться регулярно по ночам (джобы, короче говоря), их тоже выносить из хранимок и хранить то что работает только в бд за пределами этой самой бд? Как тебе такая идея? А как тебе идея хранить в бэк енде функции, которые используются в фильтрах запроса? А если они используются в function-based индексах? А если функция кроме как в запросах больше нигде не используются и ей не плохо нацепить pragma udf, такую тоже хранить на бэк енде?
И именно разработкой этих хранимок и занимается разработчик БД. И я никогда не называю хранимки как API к базе, так как они являются таким же кодом проекта как и все остальное и оно не поставляется вместе с субд. И эти хранимки сложно использовать коряво, т.к. ты просто передаешь параметры и получаешь результаты в виде курсоров или готовых значений (или кодов ошибок). И если разработчик хранимок "наваял там такой логики, что без должного экранирования наконкатенировал там запросов, способных при должной инъекции поломать всё" то это проблема разработчика хранимок, а не бэк-ендера, который эту хранимку тупо вызвал.
раскрыть ветку (10)
Ух... че-то я шевельнул...
Что живет вне системы контроля версий, а что внутри, вообще не должно влиять на архитектуру систему, это сугубо проблемы разрабов и и удобство их работыНа архитектуру влиять не должно - это да, но не хранить ВЕСЬ код в системе контроля версий того или иного проекта - это дилетантство.
Писать говно код потому что так удобнее, как раз таки и есть так себе идеяПричем тут говнокод? Говнокод можно написать и хранить где угодно. Речь не об этом. Есть еще и говноархитектура.
Код из хранимок вполне нормально хранится в системах контроля версий, потому что представляет собой обычный текст.Отлично. Я рад, что вы это понимаете. А-то есть чудаки мудрые, которые держат и редактируют код хранимок исключительно и напрямую в БД, а не накатывают в рамках миграций на чистую базу.
Ничто лучше субд не справляется с работой с данными, поэтому всю логику работы с данными как раз таки должно хранить на уровне субд, если эта логика обещает быть сколько-нибудь сложной (а она почти всегда становится такой, когда у заказчика возникает больше хотелок).СТОП, ЧТО!!!
В смысле хранить логику в БД?! БД - это база данных, там данные нужно хранить. Ещё там приходится хранить структуру (таблицы, связи, индексы), некоторые складывают в БД хранимые процедуры. Первоисточник их лежит в коде и код при деплое умеет их накатывать вместе со структурой с помощью миграций. Если у вас в БД лежит код хранимок, которого нет в системе контроля версий и в миграциях, то этот код временный для экспериментов или какой-то аварийной аналитики. Иначе вы рискуете разъехаться логикой с бэкендом. Разработчики-то сидят на разных ветках и версиях, а еще есть CI\CD, интеграционные тесты и прочее. Они могут работать со стейджинговыми БД, бэкапами и срезами.
Можно какую-то логику помещать в БД, но помещаться оно туда должно в рамках какого-то процесса деплоя и с отслеживанием версий.
хранить то что работает только в бд за пределами этой самой бд? Как тебе такая идея?Отличная идея! Хранить код нужно в системе контроля версий. Размещаться в точке его выполнения код должен в рамках процесса деплоя.
я никогда не называю хранимки как API к базе, так как они являются таким же кодом проекта как и все остальное и оно не поставляется вместе с субдЯ тоже не называл ваши хранимки API. API - это интерфейс выполнения SQL-запросов к БД и получения результатов.
И если разработчик хранимок "наваял там такой логики, что без должного экранирования наконкатенировал там запросов, способных при должной инъекции поломать всё" то это проблема разработчика хранимок, а не бэк-ендера, который эту хранимку тупо вызвал.Это исключительно проблема техлида, который не провел ревью и не надавал по шапке за такие уязвимости. Передавать паремтры в любые запросы к БД нужно либо через специальные механизмы передачи параметров в рамках API, либо очень тщательно очищая и валидируя их на бэке.
раскрыть ветку (9)
Спасибо за комментарии, которые в основном правда представляют собой цепляние к словам.
Но что сказать то всем этим хотел? Что кроме говнокода есть говноархитектура? Ну если детализировать, то да.
Прицепился к слову "хранить", и все сообщение доказывал что хранить нужно в системе контроля версий. Как будто с этим кто то спорил. Рассказывал про правильный деплой, как он работает и прочее. Но как это все отвечает на вопрос "кто наговнокодил так, что возникла возможность sql-инъекций"? Ведь суть разговора, напомню, была именно в этом.
P.S. API к БД как "интерфейс выполнения sql-запросов" я добавлю в свою коллекцию перлов, с твоего позволения.
раскрыть ветку (8)
Добавь лучше к перлам своё изречение, будто у БД не бвывает API и мысль, будто бы хранимки - это API. Тут не цепляние уже
раскрыть ветку (7)
Мысль, будто хранимки - это API пришла мне после прочтений твоих высказываний. Без твоего помощи мне бы это в голову не пришло. Мыслей наподобие той, что компилятор pl/sql который выполняет команду create or replace package - это оказывается API. И парсер sql-запроса, это тоже API. Почитай что ли вначале что такое API, а потом уже заявляй что взаимодействие с базой происходит через него. И вообще видимо если что то с чем взаимодейтсвует, то обязательно через API.
А потом еще можно будет обсудить перлы о том, stored procedure из БД должна храниться (stored) вовсе не в бд, а в vcs. И должны появляться в базе после деплоя, и вообще называться видимо deployed procedure.
раскрыть ветку (6)
ох...
API (программный интерфейс приложения, интерфейс прикладного программирования) (англ. application programming interface, API [эй-пи-ай][1]) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола (например, RFC[2]), программного каркаса (фреймворка)[3] или стандарта вызовов функций операционной системы[4]. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
Кошмар.
раскрыть ветку (5)
И? Чем из всего этого является компилятор или парсер?
Впрочем, можешь называть это все API, мне не жалко. Важно чтоб ты сам понимал, как в эту твою парадигму ложится твоя же фраза про "правильное использование API". С твоего позволения фразу "написание говнокода" я лично никогда не буду приравнивать к фразе "неправильное использование API". А то выглядит косоязычно. И притянуто на глобус.
Главное во всем этом то, что у тебя не осталось вопроса, почему бэкендеры обычно не при делах, когда дело касается правильного извлечения данных из БД. А именно с этого все и началось.
раскрыть ветку (4)
Нет. всё начиналось с того, что возможность SQL-инъекций - это исключительно ответственность бэкендера и правильного использования библиотек доступа к БД. Например передача параметров в звпросах конкатенацией SQL вместо использзования специальных параметров в API библиотеки.
А что вы там так абстрактно и загадочно пишете про "правильное извлечение данных из БД" я даже разбираться не хочу. Какая разница? Опять скажете "косоязычно" цепляюсь к словам, а мы ж тут не филологические прения устраиваем. косноязычность нас тут волновать не должна.
Срезюмирую. Если в проекте отдельный человек (а почему-то не бэкендер) занимается "разработкой базы данных" (хотя что там разрабатывать, обычно испольльзуется ORM и БД описывается декларативно кодом моделей в бэке), и этот человек наделал хранимок, уязвимых для SQL-инъекций (то есть злоупотребил выполнением SQL, полученного путём сборки сырых строк из входных данных), то в проекте уже большие проблемы с архитектурой.
Это всё, что я хотел сказать. С чем вы тут хотели поспорить?
раскрыть ветку (3)
С чем вы тут хотели поспорить?
С тремя вещами:
Например передача параметров в звпросах конкатенацией SQL вместо использзования специальных параметров в API библиотеки.
У БД нет никаких API библиотек, нет никаких методов и нет никаких специальными параметров. Взаимодействие с БД осуществляется набором dml, ddl комманд, различными админ командами и написанием кода на встроенном в бд языке программирования. Это и есть тот интерфейс работы с бд, которая бд предоставляет. (Есть еще низкоуровненвые вещи наподобие Oracle Call Interface, это я готов назвать API, но отношение к sql-запросам он имеет весьма опосредованное).
Если вы с этим не согласны, то приведите тогда пример метода, после вызова которого Оракл вернет вам курсор запроса.
(хотя что там разрабатывать, обычно испольльзуется ORM и БД описывается декларативно кодом моделей в бэке)
Обычно - это в простеньких проектах которые никогда не столкнуться со сложной логикой работы с данными, от которых все эти ОРМ начинают творить лютую дичь. Я уже привел вам кучу примеров логики, которая выполняется только на уровне БД и в которой ОРМ вообще не при делах. Вы думаете кто то научил компьютер программировать и теперь можно просто говорить ему что нужно, а он сам накодит sql-запрос? Это тоже самое что думать что конструктор сайтов заменит веб-программирование. Если вам встречались только проекты где всего этого достаточно, то это не значит что сложных проектов нет. Там где то есть комментарий человека, который считал что ОРМ на все хватает, посмотрите сколько с ним согласны, а сколько нет.
Если в проекте отдельный человек и этот человек наделал хранимок, уязвимых для SQL-инъекций (то есть злоупотребил выполнением SQL, полученного путём сборки сырых строк из входных данных), то в проекте уже большие проблемы с архитектурой.Это как раз таки означает что в проекте опытный архитектор который уже видел к чему может привести ОРМ. И понял что ОРМ не дает и половины функционала самой БД. И понял что источник гуано в лице ОРМ в его проекте ему не нужен и выделил специального человека. Который уже мог написать говнокод, но это проблемы уже не архитектора. Вот к таким людям я и адресовал шутку.
Вы случайно не ORM называете API к базе данных? Тогда есть 4-й вопрос.
АПИ у БД, конечно же, есть у любой. Для чего бы кому-то пригодилась база данных без интерфейса?
Вы же понимаете что кроме API-ORM у базы данных остается достаточно интерфейсов? И что ОРМ вообще не является частью БД? Или вы думаете что без ОРМ к данным из базы никак не подобраться?
раскрыть ветку (2)
У БД нет никаких API библиотек, нет никаких методов и нет никаких специальными параметров. Взаимодействие с БД осуществляется набором dml, ddl комманд, различными админ командами и написанием кода на встроенном в бд языке программирования.
Это происходит не на пользовательском уровне. Пользователь работает с фронтом, фронт ходит через бэк, а бэк работает с БД через биндинг - либу, которая занимается безоасным формированием DDL и DML в ответ на вызовы методов и функций. Большая ошибка писать собственный велосипед для экранированиия параметров. Всегда есть огромное количество спецаильных библиотек для работы с БД из любого языка программирования.
SQL-инъекции пресекаются именно на этом этапе.
Если вам встречались только проекты где всего этого достаточно, то это не значит что сложных проектов нет.
Мне встречались легаси-проекты. в которых тысяча таблиц и полторы тысячи хранимок. Часть бизнес логики засунут в эти хранимки, а часть сделана в толстом клиенте. Это был ужас и кошмар. Если есть возможность не пихать логику в базу, нужно так и делать. Нужно по возможности отделать данные от логики, иначе с этим работать будет очень некомфортно.
Да, безусловно есть специальные случаи и исключения. Мне приходилось писать гиганстские SQL-запросы на несколько экранов с кучей подзапросов и всё это снабжать планами, потому что автоматически индексы выбирались не эффективно. Обычно такое было связано со сложной аналитикой или одноразовой подготовокой данных в рамках больших миграций.
Я в ваши оракловские сани со своим уставом лезть не буду, коллега. ораклом не работал, но после файрбёрда и посгреса, после того как глубоко потрогал монгу, после вот этого всего я для себя четко уяснил, что данные и код смешивать следует минимально.
Я не утверждал никогда. что ORM-панацея, просто нужно стараться избегать оверинженеринга. Иногда гораздо лучше и эффективнее себя показывает NoSQL подход.
Это как раз таки означает что в проекте опытный архитектор который уже видел к чему может привести ОРМ. И понял что ОРМ не дает и половины функционала самой БД. И понял что источник гуано в лице ОРМ в его проекте ему не нужен и выделил специального человека.
"Может привести", а может и не привести. Всякому инструменту свое применение. Так-то и микроскопом можно гвозди забивать, а молотком зубы лечить, но специальные инструменты ко всему применять правильнее. А такой категоричный подход меня малость пугает. Вот, оказывается, все беды из-за ORM, а мужики-то не знают...
Ничего плохого в ORM нет, если умеешь его использовать и понимаешь области его применения. Тем более ничто не мешает смешивать подходы и что-то извлекать без всякого ORM.
Вы случайно не ORM называете API к базе данных?
Нет.
И что ОРМ вообще не является частью БД?
Да блин, да откуда у вас такие помыслы вообще, сударь? Какая, блин ОРМ часть БД?=0
Или вы думаете что без ОРМ к данным из базы никак не подобраться?
Пипец... ОРМ - это просто одна из возможных прослоек, чтобы не иметь дела с запросами в простых случаях, а иметь дело с разу с модельными объектами предметной области.
Если у вас есть несколько слоёв. то между слоями есть API. Функции с сигнатурами. которые следует вызывать, чтобы работать с БД - это тоже API. Протокол и датаграммы общения с базой через сокет - это тоже API, но низкоуровневое.
Модели ОРМ тоже имеют своё API, чтобы с ними взаимодействовать.
Слои.
Так это устроено. Разные люди пишут разный код и чтобы этот код разных людей мог обращаться к другому коду других людей есть API.
SQL-инъекции возникают, когда программист вместо правильного использования API-библиотеки биндинга вызывает SQL напрямую строковой конкатенацией подставляя в него параметры так, что этот SQL ожет поломаться из-за кустарно-велосипедного экранирования и злонамеренно составленных входных данных при атаке.
Правильно - не давать неопытным разработчикам писать свои велосипеды в таких ответственных и непрозрачных местах, как обмен данными между базой и бизнес-логикой. Нужно проверять, чтобы разработчики бэка реализуя бизнес логику ПРАВИЛЬНО использовали готовые КАЧЕСТВЕННЫЕ библиотеки биндинга к БД, а не сооружали опасные SQL-запросы из данных пользовтаеля вручную на коленке.
раскрыть ветку (1)
Вы так рассуждаете, как будто реализация логики работы с данными на уровне бэк енда - это априори правильное и богоугодное дело, а все остальное - костыли и велосипед. Однако для меня это просто мечтания отдельных личностей, которые разбились о суровую реальность. Я уже вам приводил примеры, когда этой логике нечего делать в бэк-енде. Но вы толи игнорируете эти примеры, то ли ожидаете что кто то будет разделять логику работы с данными на уместную и неуместную в бэке, на простую и посложнее и эта логика будет лежать и в бэке и в базе. И тогда уже никто не сможет сходу сказать где лежит искомая реализация и надо будет искать во всех возможных местах.
"Может привести", а может и не привести. Всякому инструменту свое применение. Так-то и микроскопом можно гвозди забивать, а молотком зубы лечить, но специальные инструменты ко всему применять правильнее. А такой категоричный подход меня малость пугает.
А вы перестаньте навешивать ярлыки на хранимки и такой подход перестанет пугать. То что вам было с ними тяжело ни о чем не говорит. Вернее ничего не говорит о хранимках.
Вот, оказывается, все беды из-за ORM, а мужики-то не знают...Может ваши мужики и не знают, а вот эти вот знают:
(см видео внизу)
И куча других мужиков с которыми я общался лично тоже знают. И все говорят что за пределами CRUD операций ORM усложняется в разы. И начинаются костыли в виде prepareStatement (в лучшем, а в худшем монструозное использование ORM от которого все вешаются). Так что говорите только за себя, а не за всех мужиков.
Да блин, да откуда у вас такие помыслы вообще, сударь? Какая, блин ОРМ часть БД?=0Да потому что я уже вторые сутки пытаюсь понять что вы называете API и через какой это API лично я работаю с БД и почему я не вызываю никаких методов и не понимаю как правильно и как неправильно в эти невидимые методы передавать параметры. И уже отчаялся это понять. Так что не начинайте плиз по второму кругу. Пусть у вас всё будет через АПИ, а у меня не всё.
P.S. Сорри, хз как кошерно вставить видео. Не обессудьте
YouTube●50:53
YouTube●58:12
IT-юмор
7.1K пост53.2K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору