В приложении есть генератор отчётов(Report Builder для Delphi), в нём пользователи могут менять SQL.
то, что там пропускаются штуки типа "drop table" - это полбеды. В конце концов можно не давать пользователю прав на такое. Но нельзя не давать прав на update. А с ним можно наделать делов не меньше:



Как бы запретить пользователю в определённых режимах делать что-то кроме SELECT, в рамках его привилегий?

Есть конечно вариант прикрутить какой-нибудь "проверяльщик SQL строки на безопасность". Если таковые есть - тоже вариант. Подскажите. Понятно, что DROP, CREATE, UPDATE и DELETE я сам могу выпилить, а какие ещё засады могут встретиться?

X-Cite,
Репорт билдер никак не ограничивает SQL statement, можно хоть DROP засунуть (но он сработает, естественно, только с учётки админа). Отчётов - сотни, пользователи должны их менять (иначе айтишникам кранты)

ёёёёё,

Ну да, и кривым селектом. Но это не страшно (убить процесс не проблема) - страшна потеря данных. Тридварасов нет, но люди ошибаются.

ёёёёёVictor Cookin,

юзеры не будут отчёты менять, тем более - с применением sql.


А кто сотни отчётов в таком случае наструячил?

ёёёёё,

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

DimaBr,

активных отчётов 553, всего за 10+ лет - 12548. Все в базе хранятся.

GatorЗа 10 лет вполне можно было устаканить права на объекты и расписать роли
(sorry for offtop)
интересно как в Оракле, например, можно дать пользователю возможность работать на изменение только с одной записью? Триггеры не предлагать.

asutp2а потом ты жалуешься, что юзеры могут использовать update или delete :-)
жалуюсь, да. Мне кажется в отчётах пособные запросы должны блокироваться.

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

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

_Vasilisk_Так же как и везде - через View. Можно даже с одним полем
не понимаю как

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

Да нет никакого хаоса. Ну да, меняют. Год поменялся, НДС поменялся...

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

У Кайта много книг. В основном как раз для профессионалов. Какую конкретно книгу Вы рекомендуете.

softwarerА что ещё не предлагать? Опубликуйте, пожалуйста, весь список. SELECT, INSERT, UPDATE и DELETE туда войдут?

Нет, только триггеры не предлагать.

Мимопроходящий
у Оракела тоже.


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

softwarerНапример, через роли

Да, это наиболее адекватный вариант.

Да, это наиболее адекватный вариант.

PS Это, правда, вариант RO, а не ограничения изменений одной записью, но это даже и лучше

DimaBrВы проверьте, каждый второй одинаковые

Ну и что? Ну будут ~250 различных

ёёёёёПроцедуры можно использовать, которые наделены соответствующими правами, не?

ага... А поле переназвали, и процедура стала инвалидом. К тому ж не уверен что RB адекватно будет работать с таким источником данных, как процедура... Как там сделать rbDataPipe из процедуры ?

Всё проще - надо сделать специальный коннекшн для специального юзера - ReportBuilderUser. Этому юзеру ограничить права только на чтение. И переходить на него при работе с ReportBuilder.

_Vasilisk_Отобрать права на доступ к таблице и выдать права на доступ к вьюхе
Основное приложение работать перестанет - там запросы именно к таблицам.

ёёёёёНу ты попробуй хотя бы. Как минимум - узнаешь, как процедуры в качестве источника данных применять. :)

Прочитал. Понял, как в РБ можно процедуры ... Только зачем?
Выберет пользователь вместо процедуры таблицу - и понеслось UPDATE ...WHERE 1=1

ёёёёёМожно процедуру использовать именно для сохранения отчета в базе. Юзеру запись запретить совсем, а сторед процедуре - разрешить. И юзера до этой SP допустить.
Да с сохранением отчёта вообще проблем нет. Пусть сохраняют как хотят.

Мимопроходящийтаблицу переименуй.
оберни её во вьюху с исходным именем таблицы.


А что случится если в приложении случится
INSERT INTO ORDERS (Order_ID, ... VALUES (23512234,...

Мимопроходящийслучится инсёрт во вьюху


А что случится если в случится
INSERT INTO ORDERS SELECT 434 000 000 records?

Мимопроходящийслучится отлуп, если ты правильно сделаешь RLS.

А зачем View делать? Я точно так же могу RLS на таблице настроить, нет?

Мимопроходящийps: не нужно растекаться мыслями по всем форумам сразу.


Вопрос - на стыке. Можно ведь просто сделать анализ SQL строки средствами Дельфи перед тем как она будет отдана из RB в базу Oracle.

Мимопроходящийсделай.


Во-первых, это некрасиво...

эндичто за дичь, у вас там пользователи что под правами админа работают чтоли?
Под собой они работают. Слава богу, не владельцы схемы. А когда я захожу, могу спокойно даже DROP TABLE сделать из Report Builder.

эндидоступ к объектам и строкам спокойно делается встроенными средствами практически любого вменяемого sql сервера.
Тут вообще-то скорее по Дельфям форум, а не по Ораклу. По Ораклу я спросил в том форуме

эндиПричем как Вам уже сказали выше, роли, разграничение доступа, хранимки, вьюшки, кое где и права на отдельные строки таблицы можно.
Роли достаточно. Хранимки, вьюшки - не дают абсолютно ничего. RLS - - возможно

эндиЧто вы опять сову на глобус натягиваете
Интересно иметь on the table все возможности