Веб-разработчик сказал, что прямые запросы SQL не получится приделать к REST API на сайте на webasyst.

Слушай парня и делай как он говорит, не пытайся понять.

Благо ты 1С занимаешься, а не настоящей разработкой, иначе бы тебя следовало немедленно уволить за непрофпригодность.

Произвольные запросы в БД прям с фронта — ололо, настолько очевидно, даже аргументировать лень.

Веб-разработчик сказал, что прямые запросы SQL не получится приделать к REST API на сайте на webasyst.

Спросите у него - «Можете ли приделать мои кривые запросы?»

ололо, настолько очевидно, даже аргументировать лень.

Пока не очевидно. Может все же разъясните, а то у самого чешутся руки приделать их в обход веб-разработчика.

Пока не очевидно. Может все же разъясните, а то у самого чешутся руки приделать их в обход веб-разработчика.

Он не знает как защита от инъекций производится

Вот в чем вопрос

Владимир 123

Спросите у него - «Можете ли приделать мои кривые запросы?»

select value_id from shop_product_features_selectable where product_id=XXX and feature_id=XXX

И в чем кривость?

Переделай сам, т.к. это огромная дыра в сервисе, переделав сам ты возьмеш ответственность на себя.

Какие инъекции, лол, он предлагает произвольные запросы в БД проксировать.

drop table shop_product_features_selectable

Так понятнее?

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

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

Какие инъекции, лол, он предлагает произвольные запросы в БД проксировать

Обычно в конфигурации 1С много объектов и обычно устанавливают права и роли для доступа к их данным.
Так что халява не пройдет …
А вот подмена запроса с учетом вышесказанного на ура отработает.
Это и есть инъекция.

Владимир 123

А вот подмена запроса с учетом вышесказанного на ура отработает.

Собственно это азы.
Пусть в inet погуглят для начала …

Владимир 123

Пока не очевидно. Может все же разъясните, а то у самого чешутся руки приделать их в обход веб-разработчика.

DBA есть?

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

если нет DBA, то см. страшилки выше.

Погугли для начала sql injection, потом зацени насколько это плохая идея с сайта напрямую пропускать запросы к базе

Я то думал, он в десяток строк на php организует перенаправление запроса сразу в MySql.

Но ты же ведь не с дебилами работаешь? Или?..

И в чем кривость?

А теперь представь, что твою морду сломал очередной бот, коих нынче полно. И ушло в БД вместо селекта дроп или еще что похуже.

Можете объяснить, зачем такое?

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

Теперь наброшу. :) Строго говоря, при грамотном проектировании структуры БД и раздаче прав (группы, права только на нужные таблицы, там, где нужно - права только на представления) все эти дыры успешно закрываются и на стороне сервера.

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

Теперь наброшу. :)

там у веб-разработчика явно ORM головного мозга.

2TC: надо было делать сразу на SQL, если 1С cвой )))

там у веб-разработчика явно ORM головного мозга.

Кто ORM для вэба не сделал, тот не вэб разработчик ...

Владимир 123

Но веб-разработчик предлагает в том числе и селекты делать интерпретатор, что видно по его ответу: «каждое условие надо обрабатывать например использование операторов < > sum(), или join для select запросов».

Я здесь умолчал про то, что в постановке была маломальская защита на запросы изменяющие данные. А системные таблицы как здесь упоминули, и как я и предполагал, блокируются правами доступа.

Так что все равно пока не понял, в чем цель такой реализации, кроме как раздуть задачу?

Нужна не мало-мальская, а нормальная защита. А это не так просто. Иначе даже просто селектом по «безопасным» таблицам можно получить DDOS, например пачкой джоинов.

Но веб-разработчик предлагает в том числе и селекты делать интерпретатор

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

в чем цель такой реализации

Цель в том, чтобы в результате работы такого «конструктора» получались только определённые запросы, а не любые.

Собственно твоё предложение равнозначно «давайте выкинем API и будем подключаться к базе напрямую». Вариант конечно возможный, но при чём тут разработчик API? Пробросьте базу через vpn (чтобы не торчать голой жопой в интернет) и всё.

Если конечно это всё ваша внутреняя кухня. Если нужно чтобы запросы поступали от третьей стороны (контрагентов, клиентов), то конечно придётся городить API. Впрочем, замутить обобщённый запрос для селекта с джойнами и набором фильтров не такая уж большая проблема.

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

Тогда это выглядит похоже на GraphQL.

В любой БД безотносительно 1C доступы можно настроить, к чему ты это? И, ещё раз, он именно произвольные запросы хочет пропускать, инъекции не требуются. Делаешь нужный тебе запрос и всё.

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

Да какие блинн инъекции, если клиент запрос напрямую шлёт. Просто шлёшь нужный и всё. Чего за тупняк у владимиров в этом треде?

Он нет, а коллеги да. Ему же отказали.

Он нет, а коллеги да. Ему же отказали.

Это был тонкий намек ТСу =)

Даже при ограничении прав, и раздаче нужных ролей, ты никак не спасёшься от DoS твоего СУБД-сервиса.

Если апишка за аутенфикацией (я так понимаю обмен по сути между двумя своими микросервисами, а не в паблике), и запрос выполняется от пользователя, которому грамотно раздали права, а не как принято у вебдевелоперов, от рута, и организовали прочее row level security, то в общем-то единственная причина так не делать — глубоко засевший инстинкт не пихать пользовательский ввод в исполняемый контекст.

Для безопасности. Он все правильно делает.

организовали прочее row level security

Фантазии недодба, не имеющие отношения к реальному миру.

Конечно. Даёшь как можно больше точек отказа в систему. Зачем люди сводят все к единой точке входа непонятно. Дураки какие-то.

В реальном мире видел как порой из 1С пишут и читают напрямую в мускуль сайта, минуя всякие rest api. Как полагается в реальном мире, от рута :)

Он писал

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

Понял не так как вы пишете.
То бишь не с сайта делать запросы, а к сайту прилетает запрос.

Владимир 123

Что такое «сайт»? Как он может принимать запросы? Сайт - это http сервер, и бэкенд сервис обрабатывающий запросы к этому http серверу. В том числе, этот бэкенд посылает запросы в другие сервисы, такие, как например СУБД, получает ответы от этих сервисов, обрабатывает их, и с помощью всё того же http сервера отдает клиенту.

Так кому именно хочет посылать запросы ОП? http серверу, бэкенду или СУБД?

Что такое «сайт»? Как он может принимать запросы?

Понял так, что запросы у него в PHP где-то, то бишь не интерактивно их вводим.
А так да, немного коряво сказал.

Владимир 123

Что такое «сайт»? Как он может принимать запросы?

Может и такое быть …
Когда разрабатывал вэб интерфейс для 1С 7.7, то у меня была предусмотрена возможность получения запроса от 1С.
Потому как при выполнении запроса 1С например могла инициировать диалоговое окно … … …

Владимир 123

выглядит похоже на GraphQL

Как вариант. Можно было изначально какую-нибудь призму прикрутить, если нужно только запросы дёргать.

Если … и … и … и …

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

Все очень просто. Выгрузить остатки из 1с в интернет магазин, закачать заказы обратно.

 1С подключается к сайту
 -> HTTP запрос с скл запросом в параметре
 -> пхп на сайте
 -> база данных MySql
 -> пхп прочитал ответ базы
 -> вложил как тело ответа на HTTP запрос
 -> 1c прочитало ответ сайта

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

Раз под рукой есть вебдевелопер, то заставь его сделать два ендпойнта, /заказы откуда брать заказы и /остатки, куда грузить остатки.

Изобретать ничего не нужно. Просто реализуйте в апишке нужную функциональность и всё. Либо GraphQL, как тебе выше уже предлагали. Но тут уметь надо. Лично я никогда его в глаза не видел.

И в чем кривость?

В самой концепции что фронтэнд бросает произвольные запросы бэкэнду.

Все обращения от фронта должны быть четко детерминированы. А так:

• Ты можешь кинуть произвольный запрос - это очень плохо с точки безопасности

• Ты можешь кинуть запрос плана которого не знаешь а это всегда проблема, особенно если API синхронный

• Ты можешь кинуть запрос с простейшими join которые перемножать хотя бы тройку раз таблицу на лучшем случае несколько тысяч записей и убъют любой SQL сервак - простейший отказ в обслуживании

Добро пожаловать в век elasticsearch и прочих mongodb, тут прокидывают бд прямо на фронт.

то заставь его сделать два ендпойнта

Это слишком сложно. И заставить, и сделать, а потом еще на каждый чих заказчика заставлять это переделывать вместе со своим кодом. Проще одну из частей сделать универсальной, и в данном случае это сайтовская часть, поскольку иначе всю 1с грузить на сайт.

Да делай как хочешь, не слушай никого. До первого drop database будешь собой доволен, потом осознаешь. Наверное.

Понял, спасибо, пошел делать. Если что, скажу что это ты так рекомендовал.

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

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

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

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

Когда разрабатывал вэб интерфейс для 1С 7.7, то у меня была предусмотрена возможность получения запроса от 1С. Потому как при выполнении запроса 1С например могла инициировать диалоговое окно … … …

При отладке на одном мониторе у меня был сайт, а на другом 1С.
Весьма занимательно было видеть как при работе в 1С появляются mirror странички на сайте и vs.
При этом мог в любой момент продолжить работу как на html так и в 1С.
Вообщем нескучный проект.
Кстати он по существу к 1С и не был завязан.
То бишь на стороне сайта есть некий API и на стороне 1С использовался некий протокол.
И этот протокол по существу можно было прицепить к любой программе.
Не стал этот протокол развивать так как ныне это решаю много универсальней …

Честно скажу

WWW - гадостная заливная рыба

Владимир 123

вообще-то разраб прав - ты хочешь дыру в безопасности сделать.

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

сделай сайтовую часть оберткой над процедурой в базе и в случае чего — меняй процедуру. делов-то.