Комментарии 20
Спасибо за статью! В Оракле чего только нет :) каждый раз жалею, что пока что не довелось с ним поработать.
Скажите, а что такое user в вашем примере policy_func? Это в Оракле так можно получить имя текущего пользователя?
Кстати, почему в выборках вы сравниваете пользователя по имени, а не по id? Так принято в Oracle world?
Скажите, а что такое user в вашем примере policy_func? Это в Оракле так можно получить имя текущего пользователя?
Кстати, почему в выборках вы сравниваете пользователя по имени, а не по id? Так принято в Oracle world?
> В Оракле чего только нет :) каждый раз жалею, что пока что не довелось с ним поработать.
Оу, чего там только нет, ломающего мозг программисту как логикой, так и реализацией… Так что, лучше не жалейте :)
Если хотите более продвинутую СУБД по сравнению с привычной MySQL, то лучше уж смотрите в сторону SQL Server.
Оу, чего там только нет, ломающего мозг программисту как логикой, так и реализацией… Так что, лучше не жалейте :)
Если хотите более продвинутую СУБД по сравнению с привычной MySQL, то лучше уж смотрите в сторону SQL Server.
А почему не postgresql?
Не пугайте потенциального разработчика!!! :)
Именно в базе все просто изящно и логично. Больше шести лет с этой базой и как без нее жить не знаю :)
Если проект бесплатный существует бесплатная версия: Oracle XE.
Именно в базе все просто изящно и логично. Больше шести лет с этой базой и как без нее жить не знаю :)
Если проект бесплатный существует бесплатная версия: Oracle XE.
Я не буду разводить холивар — мне лень. Просто пусть поработает с Ораклом, а потом, например, с MySQL/MSSQL — и дальше сам решит.
Начинающие разработчики — учтите, что Oracle XE — без поддержки Java (ряда пакетов и функционала, там, соответственно, не хватает). Лучше ставьте другие Edition, благо для девелопмента они бесплатные. А дальше захотите — купите. Не захотите — переметнетесь на MySQL/Postgre.
Начинающие разработчики — учтите, что Oracle XE — без поддержки Java (ряда пакетов и функционала, там, соответственно, не хватает). Лучше ставьте другие Edition, благо для девелопмента они бесплатные. А дальше захотите — купите. Не захотите — переметнетесь на MySQL/Postgre.
И не нужно разводить холивар — это низшая форма диалога ;)
Про поддержку Java 100% правда отсутствует полностью.
Но пакетов там нет по другой причине, — это тупо вопрос лицензирования.
Java в стандартных пакетах используется по минимуму — ибо Java код медленнее чем PL/SQL и нативный код подключенный к базе.
Опять же не боятся отсутствия Java не стоит, так как ее практически не приходится использовать. Если аналогичная функциональность в PL/SQL пакетах.
XE удобна тем, что устанавливается либо apt-get'ом, либо за одну команду rpm -Uvh.
Про поддержку Java 100% правда отсутствует полностью.
Но пакетов там нет по другой причине, — это тупо вопрос лицензирования.
Java в стандартных пакетах используется по минимуму — ибо Java код медленнее чем PL/SQL и нативный код подключенный к базе.
Опять же не боятся отсутствия Java не стоит, так как ее практически не приходится использовать. Если аналогичная функциональность в PL/SQL пакетах.
XE удобна тем, что устанавливается либо apt-get'ом, либо за одну команду rpm -Uvh.
Работал с MySQL довольно долго… До сих пор в тихом ужасе и трогать его больше не хочу.
Да, Вы правы, USER — это функция, возвращающая имя залогиненного пользователя.
Имя пользователя в сравнении использовал для наглядности и читабельности примеров.
Имя пользователя в сравнении использовал для наглядности и читабельности примеров.
Угу, контексты и FGAC — все очень знакомо. Спасибо за статью.
Из минусов — сложнее выполняется профилирование запросов, подмена аутлайнов и т.п
Из минусов — сложнее выполняется профилирование запросов, подмена аутлайнов и т.п
картинки умерли
Насколько это влияет на добавление других ограничений? Из того что я понял мы только написали какую-то функцию и «зарегистрировали» её, с тем, что то что эта функция вернёт так добавим в SQL, а вот как с другими ограничениями, JOINами итд… влияет-ли это на структуру SQL вопроса? Или это все транспарентно?
Думаю, стоит также упоямянуть системую привилегию exempt access policy, позволяющую обходить политики RLS, т.е. пользователю возвращается результат в независимости от того, что возвращает политика.
Меня вот мучает такой вопрос, на сколько распространено, что в 3ех и более звенных системах конечный пользователь совпадает с СУБДшным пользователем и такие фишки, как в статье актуальны?
Просто пока я чаще сталкиваюсь с ситуацией, когда конечные пользователи маппятся на одну технологическую учетку со всеми вытекающими.
Просто пока я чаще сталкиваюсь с ситуацией, когда конечные пользователи маппятся на одну технологическую учетку со всеми вытекающими.
Тоже интересует этот вопрос…
Это PL/SQL блок, это значит что в нем можно делать все что угодно.
Стандартная практика для Oracle, это вызвать setContext в самом начале обработки запроса в веб приложении, и в запросах брать значения из контекста. В контексте может быть все что угодно, это просто таблица ключ\значение. У нас например устанавливается id пользователя, язык, регион.
Стандартная практика для Oracle, это вызвать setContext в самом начале обработки запроса в веб приложении, и в запросах брать значения из контекста. В контексте может быть все что угодно, это просто таблица ключ\значение. У нас например устанавливается id пользователя, язык, регион.
Инициализация как я понимаю…
У меня тоже вопрос: насколько реально персонализировать таким образом данные? Если я напишу приложение для OeBS и инициализируюсь по пользователю с ограничениями, в приложение попадут «обрезанные» данные?
Просто в большинстве случаев сталкиваешься с тем что пользователи не смотрят данные из таблиц, а запускают приложения (формы\отчеты), соответственно там дял персонализации есть свои инструменты. Есть ли какой-то плюс в персонализации прямиком в таблицах?
У меня тоже вопрос: насколько реально персонализировать таким образом данные? Если я напишу приложение для OeBS и инициализируюсь по пользователю с ограничениями, в приложение попадут «обрезанные» данные?
Просто в большинстве случаев сталкиваешься с тем что пользователи не смотрят данные из таблиц, а запускают приложения (формы\отчеты), соответственно там дял персонализации есть свои инструменты. Есть ли какой-то плюс в персонализации прямиком в таблицах?
Технология дофольно обширная. Очень легко гуглится, на вскидку можно почитать
www.symantec.com/connect/articles/oracle-row-level-security-part-1
Ответ на твой вопрос в секции «So how does it work — a brief example»
Если упрощенно смотрите на это как будто бы все таблицы вдруг стали view с условием которое берется из policy function. Например если в запросе используется view, который внутри делает агрегацию, то все произойдет как и задумано — сумма\среднее\etc агрегации построится по тем рядкам которые вам доступны.
www.symantec.com/connect/articles/oracle-row-level-security-part-1
Ответ на твой вопрос в секции «So how does it work — a brief example»
Если упрощенно смотрите на это как будто бы все таблицы вдруг стали view с условием которое берется из policy function. Например если в запросе используется view, который внутри делает агрегацию, то все произойдет как и задумано — сумма\среднее\etc агрегации построится по тем рядкам которые вам доступны.
В 99% баз действительно такой функционал не нужен: с базой работает одно приложение под одной учеткой, конечные пользователи работают через это приложение. Но бывают монстры где это может пригодиться: два и более приложений, разработчики из разных подразделений или может даже аутсорсной компании. Хотя все-равно не очень представляю настолько мудреную схему.
Изначально я программист баз данных, с наклоном в Оракл.
«Безопасность на уровне строк» на деле не так проста как пишут многие.
Самая большая сложность в том, что на самомом деле не строки решают, а совокупность таблиц, например, классическое — «Шапка-деталировка», там не одна строчка, да еще и могут быть тысячи строк в деталировке, умножим это на запросы по групппировке и прочему, и получается у нас Монстр, который работает на порядки медлееней чем реализация класической можели Доступа к документам.
«Безопасность на уровне строк» на деле не так проста как пишут многие.
Самая большая сложность в том, что на самомом деле не строки решают, а совокупность таблиц, например, классическое — «Шапка-деталировка», там не одна строчка, да еще и могут быть тысячи строк в деталировке, умножим это на запросы по групппировке и прочему, и получается у нас Монстр, который работает на порядки медлееней чем реализация класической можели Доступа к документам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Oracle. Безопасность на уровне строк