Авторизация и роли пользователей в Oracle Apex?
Таким образом, у Apex есть "рабочие пространства", которые позволяют создавать пользователей трех типов - все они являются внутренними по отношению к организации по своей природе. Кроме того, похоже, что у разработчика отдельного сайта в Apex нет возможности иметь "пользователей" только для своего сайта.
Я что-то пропустил?
Мне нужно, чтобы внешние (бизнес) пользователи могли получить доступ только к некоторым функциям сайта, например, бухгалтерский учет может видеть только страницы A и B, в то время как руководители могут видеть A,B и C.
Мне нужно иметь возможность иметь несколько групп людей с разной степенью доступа.
Можно ли это сделать только путем создания рабочих пространств / групп? Или это можно сделать только на моем сайте?
4 ответа
Хотя в APEX есть встроенная концепция управления пользователями под названием "Группы", я должен признаться, что никогда не использовал ее, и быстрое изучение документации не дает мне понять, как вы используете их для контроля доступа (но см . Ответ Тома). вот за что).
Возможно, вам потребуется создать таблицы пользователей / ролей в вашей базе данных и использовать их вместе со схемами авторизации APEX для управления доступом к страницам. Единственная схема авторизации типа "PL/SQL Function возвращающая логическое значение" может быть создана с помощью тела функции:
return my_auth_pkg.is_authorized (p_user => :app_user,
p_app_id => :app_id
p_page_id => :app_page_id);
Затем вы реализуете пакет для поиска привилегий пользователя и решаете, возвращать ли ИСТИНА или ЛОЖЬ для приложения и идентификатора страницы.
В качестве альтернативы вы можете просто выполнить SQL для проверки доступа непосредственно в схеме авторизации:
(NB "user_roles" и "role_pages" - это имена, которые я составил, чтобы представлять ваши таблицы)
Я просто хотел бы расширить ответ Тони, который сам по себе является правильным. Я просто хочу показать вам другой способ, который, как мне кажется, будет проще для начинающего, и в нем нет создания таблиц.
Если ваше приложение использует Apex в качестве схемы аутентификации, то управление вашими пользователями осуществляется посредством администрирования самого рабочего пространства. Вы можете создавать, редактировать и удалять пользователей, но вы также можете определять группы и связывать пользователей с группами. Можно создать несколько пользователей типа "конечный пользователь" и определить пару групп, например "Руководители".
Когда вы создали свою группу, перейдите к пользователю, которому вы хотите назначить эту группу, и добавьте группу в группы этого пользователя.
После того, как вы это настроите, вам все еще нужны схемы авторизации. Факт остается фактом, вам нужны некоторые знания pl / sql, но возможно свести к минимуму кодирование благодаря некоторой удобной API-программе. Current_user_in_group делает то, что говорит: он проверяет текущего пользователя, назначена ли ему указанная группа. С некоторым расширением, используя несколько простых IF-структур, вы можете немного увеличить его!
Не то чтобы я полностью рекомендовал этот метод, я нахожу его немного утомительным, и вам нужно, чтобы кто-то пошел в APEX, чтобы фактически поддерживать пользователей и их группы, но вполне может быть, что это приемлемо в вашей среде. Вы можете использовать его, чтобы начать с однако. Вы можете очень легко отключить схемы аутентификации, и, изменив свои схемы авторизации, чтобы они соответствовали новой схеме аутентификации, вы можете легко и быстро настроить это позже. Конечно, это зависит от ваших приоритетов и целей.
Авторизация - это процесс определения, разрешено ли аутентифицированному / идентифицированному лицу получить доступ к ресурсу или выполнить операцию. Он основан на наборе привилегий или ролей, назначенных пользователю. Например, в базе данных Oracle администратор имеет право планировать задания, а пользователь - нет. Чем Авторизация отличается от Аутентификации? Часто Аутентификация и Авторизация работают вместе. Другими словами, Авторизация следует за Аутентификацией. Аутентификация определяет, кто ты? Авторизация определяет, что вам разрешено делать?
Я знаю, что он довольно старый, но Google привел меня сюда, поэтому я постараюсь внести свои пять центов. Ответ Тома мне очень помог, но я хотел воспользоваться групповыми грантами APEX. Например, у меня есть группы пользователей: основной пользователь, опытный пользователь и пользователь-администратор. Более высокий уровень пользователя должен обеспечивать доступ также к приложениям / страницам более низкого уровня. Если я использую APEX_UTIL.CURRENT_USER_IN_GROUP, мне нужно проверить все группы, которые должны иметь доступ. Если я добавлю еще одну группу пользователей, мне придется добавить эту группу в схему авторизации для каждого приложения. А также все пользователи должны быть во всех группах, к которым у них есть доступ.
Мое решение заключалось в том, чтобы проверить также групповые гранты в APEX. Сначала я добавил пользователя в группу пользователей Admin. После этого я добавил группы базовых пользователей и расширенных пользователей в группу пользователей администратора. Этого недостаточно, и APEX не предоставит доступ администратору для приложений, предназначенных для основных пользователей, и APEX_UTIL.CURRENT_USER_IN_GROUP также не знает об этом. Итак, я внес некоторые изменения в PL/SQL, и моя схема авторизации выглядит следующим образом:
DECLARE
isInGroup BOOLEAN;
userID NUMBER(30);
authGroup VARCHAR2(40);
BEGIN
authGroup := 'Basic User'; -- User group to look for
isInGroup := false;
userID := APEX_UTIL.GET_CURRENT_USER_ID;
FOR a IN (
SELECT wf.group_name AS group FROM wwv_flow_group_users wf WHERE wf.user_id = userID
UNION
SELECT gg.group_name FROM wwv_flow_group_users gu
RIGHT JOIN apex_workspace_group_groups gg ON gg.grantee_name = gu.group_name
WHERE user_id = userID)
LOOP
IF a.group = authGroup THEN
isInGroup := true;
END IF;
END LOOP;
RETURN isInGroup;
END;
Сначала SELECT перед UNION получает имя всех групп, членом которых является текущий пользователь, в моем случае только Admin Users. Второй SELECT после UNION - это список всех групп, к которым группы из первого выбора предоставляют доступ. В моем случае основной пользователь и опытный пользователь. Вся эта группа повторяется в LOOP, и если одна из групп равна authGroup, определенной в начале, вернуть true.
Таким образом, я могу добавлять новых пользователей только в их соответствующую группу, и они получают доступ также к приложениям более низкого уровня.