Сейчас тестирую одну вещь на апексе 3.2...
Система такая: приложение со схемой аутентификации database_account (по пользователям БД).
Есть одна страница с репортом из одной таблицы table1.
Есть два пользователя БД: условно, №1 и №2. Пользователь №1 имеет права на селект, пользователь №2 - нет. Но на странице отчет из этой таблицы видят оба. Я так понимаю, это потому, что апекс работает с БД от имени пользователя APEX_PUBLIC_USER и видит всё, а потом уже права пользователей не проверяет.
Вопрос такой: в версиях 4.0 - 4.2 также? Я так понимаю, все права надо потом самостоятельно повторять с помощью схем авторизации?

suPPLer,

Спасибо за развернутый ответ. Я это интуитивно и сам понимал, просто обсуждали с коллегами применимость апекса для одной нашей задачи и меня сбил с толку вопрос "у пользователя в БД нет права на селект, а когда входит через апекс - есть, нелогично же?" Я написал здесь пост и ушел на обед, а пока обедал, понял, что все логично, просто с этой стороны не задумывался никогда.

alexande26kПодскажите пожалуйста. У меня Вопрос почти схожий.
Приложение также работает со схемой аутентификации database_account (по пользователям БД).
Мне необходимо сделать так чтобы одни пользователи могли видеть одни конктретные объекты, страницы, другие пользователи другие объекты, ... .
Как это можно сделать?? не совсем понятно если честно... Очень прошу помощи..Для этого есть схемы авторизации. Причем апекс может регулировать доступ только к объектам апекс-приложения - страницам, регионам, элементам страницы и т. д., и не регулирует доступ к объектам БД (таблицам, процедурам и т. д.) У каждого элемента в свойствах есть закладка "Security" или "Authorization" - туда смотрите.

alexande26ksuPPLerКонечно, возможно. Главное, чтобы эта страница (или набор страниц) тоже была с доступом, требующим авторизации.

Спасибо за хорошую новость))
Однако я немного теперь запутался.. Если все это возможно, то как все это реализовать.. Допустим у меня есть отчет на нем много различных кнопок, каждую из которых я должен скрыть или показать для определенного пользователя, и хочется все это сделать при помощи простого изменения значения checkbox'a. Это возможно?!
Если да то где в таком случае должна лежать эта "таблица" с этими значениями?? в схеме Апекс?! или не обязательно??

Извините за столь огромное количество вопросов, но мне очень надо разобраться в этой проблеме.По пунктам:
1. Делите все элементы приложения на функциональные группы (эта группа выполняет функцию1, эта - функцию2, и т. д.)
2. Создаете таблицу "Функции", перечисляете там функции
3. Создаете таблицу "Роли", даете каждому юзеру по роли
4. Создаете промежуточную таблицу для соединения ролей и функций отношением "многие ко многим"
5. Указываете, какой роли что можно делать
6. На каждую функцию создаете схему авторизации (схема проверяет, есть ли у данной роли право на выполнение данной функции)
7. Каждому элементу указываете его схему
8. PROFIT!

Это один из возможных вариантов, я так сделал - меня все устраивает.

alexande26krockclimber,

Спасибо огромное за подсказки)) Только подскажите еще одно НО! Где эти таблицы должны находиться?? Внутри схемы Апекса?Когда заходите в SQL Workshop, в меню (вверху, справа) есть выпадающий список с подписью "Schema". Там будет одна или несколько схем. Вот в тех схемах и создавайте.

И еще. Когда создаете новый workspace в администраторском разделе, вы указываете для этого workspace схему. Эта схема будет основной. Потом в workspace можно добавить еще несколько схем, но, елси я все правильно понял, первой схеме на объекты остальных схем надо дать права на select, update, execute и т. д. И указывать названия этих схем в запросах.

alexande26krockclimber,

Спасибо огромное)) Буду делать. А вы не могли бы скинуть код одной из таких схем авторизации. Буду очень признателен. Спасибо заранееНу это уже наглость, вообще-то SQL вы тоже не знаете?
Тип проверки - SQL Exists, код:

suPPLerrockclimber


Не так давно в основном разделе Oracle обсуждались подходы к моделированию статусов, справочников, внешний ключей и так далее: а как вы делаете статусы ? . Пожалуй, в этом случае я согласен, что ключ должен быть символьным кодом с каким-то значением. Определять на глаз, что такое 123, слегка затруднительно. Пусть уж лучше RPT$EMP-CREATE.Лично я сделал у себя отдельную табличку functions и отдельную страничку для этой таблицы типа Tabular Form, и на этой страничке все прекрасно и наглядно видно, что такое 123 и зачем это нужно. Там же можно добавить еще функций, и оттуда же есть ссылка на master-detail страницу, на которой для выбранной функции можно отредактировать список ролей. Такая же Tabular Form есть для списка ролей, с такой же ссылкой на аналогичную master-detail форму, где для роли можно задать список доступных функций, доступ к этим страницам одной из таких функций и регулируется, ну и так далее, и тому подобное...
А самое главное, сделать всю эту красоту можно буквально за пару часов - за что я и люблю апекс.

Serge LarionoffrockclimberПо пунктам:
...
3. Создаете таблицу "Роли", даете каждому юзеру по роли
...
Это один из возможных вариантов, я так сделал - меня все устраивает.

Уважаемый rockclimber, правильно ли я понимаю, что в вашей системе у одного пользователя может быть только одна роль?Только сейчас заметил...
Если еще актуально: да, в моей системе у каждого пользователя может быть только одна роль. Но никто не мешает вам чуть-чуть допилить ее напильником. Простор для творчества на самом деле огромный.