|
|
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Добрый день, коллеги! Я испытываю затруднения с организацией ограничения доступа к объектам APEX. Для каждого объекта (страницы, региона, поля и т.п.) я могу выбрать только одну Авторизационную схему (или ее отрицание). Вы тоже? Тогда как быть, если ролей множество и их права замысловато пересекаются? Я уже настрогал схем типа "Менеджер_Аудитор_Куратор", "Менеджер_Андеррайтер", "Аналитик_Инспектор" и т.п. Скоро начну четырехмерные гибриды вводить :) Разве нельзя, как в некоторых средах разработки, сопоставить объекту набор авторизационных атрибутов (ролей, схем) типа [auditor, manager, curator], что значило бы право доступа для всех 3-х ролей?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 11:22 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльТогда как быть, если ролей множество и их права замысловато пересекаются? ты невнимательно читал. Я тебе говорил, что замысловатость делать ролями оракла. А APEX этого не любит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 11:26 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
вариант: - делай им Рабочее место (АРМ). А не солянку-страницу для Буха-уборщицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 11:29 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Я бы так организовал. 1.Создаю таблицу в виде дерева apexrole id apex_user,role,parent_id (Иерархия нудна для того,чтобы высшая роль подхватывала все привиллегии низших) в apexe в contdition_type pl/sql(можно заранее процедуру сделать) select role into role_ from apexrole connect by prior parent_id=id start with apex_user=:USER; If role_='MANAGER' return true; end if; Для менеджеров и выше компонент будет доступен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 11:40 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
irbis_alв apexe в contdition_type тогда стандарт SECURITY не используется. А condition у меня обычно уже занят БЛ (бизнес-логикой) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 11:52 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Petro123вариант: - делай им Рабочее место (АРМ). А не солянку-страницу для Буха-уборщицы. Ага! Если, например, простому сотруднику нельзя видеть в справочнике сотрудников поле "зарплата", а начальнику - можно, то для них 2 разных АРМа делать? Конечно, что ты скажешь "нет!". Но в моей модели доступа всё так переплетено, что выбор однозначен - в пользу одного АРМ. И по поводу твоего поста "... делать ролями оракла". Какая радость от того, что ты хардкодишь еще больше моего? :) irbis_alЯ бы так организовал. 1.Создаю таблицу в виде дерева apexrole id apex_user,role,parent_id (Иерархия нудна для того,чтобы высшая роль подхватывала все привиллегии низших) Спасибо! Надо обмозговать... Не всегда наследник должен иметь все права родителя. У меня нет такой явной зависимости (в функциональном доступе). В разграничении доступа на уровне данных - да. Там начальник может видеть данные всех своих подчиненных и их подчиненных и т.д. Но это достигается не APEX-авторизацией... Интересно, а в APEX-5 всё так же?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 11:55 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Petro123irbis_alв apexe в contdition_type тогда стандарт SECURITY не используется. А condition у меня обычно уже занят БЛ (бизнес-логикой) Ну может у ТС condition свободен.или расширит бизнеслогику. Если по бизнеслогике + запросу иерархии доступен= значит показывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 11:59 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
irbis_alЯ бы так организовал. 1.Создаю таблицу в виде дерева apexrole id apex_user,role,parent_id (Иерархия нудна для того,чтобы высшая роль подхватывала все привиллегии низших) в apexe в contdition_type pl/sql(можно заранее процедуру сделать) select role into role_ from apexrole connect by prior parent_id=id start with apex_user=:USER; If role_='MANAGER' return true; end if; Для менеджеров и выше компонент будет доступен. И еще нам пришлось кешировать, чтобы ускорить работу приложения. При логоне вычисляются привилегии пользователя, и уже привилегии тянутся из куш таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 12:04 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльЕсли, например, простому сотруднику нельзя видеть в справочнике сотрудников поле "зарплата", а начальнику - можно, то для них 2 разных АРМа делать? Конечно, что ты скажешь "нет!". Но в моей модели доступа всё так переплетено, что выбор однозначен - в пользу одного АРМ. я скажу - да! Т.к. не может начальник и сотрудник хотеть одно и то же)). Сотрудник не может даже список видеть. Не только колонку)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 12:09 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльНо в моей модели доступа всё так переплетено, что выбор однозначен - в пользу одного АРМ. Один АРМ на всю ИС? Ты переплетёшь ещё больше спутав Condition с Security Но, тебе решеть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 12:11 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
А если так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 12:16 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Курдль, извини, но разрешения NTFS не будут в APEX. Он не для этого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 12:21 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльКакая радость от того, что ты хардкодишь еще больше моего? :) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 12:34 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Petro123Курдль, извини, но разрешения NTFS не будут в APEX. Он не для этого. Ты это к чему? Модель, что я привел, - это чаша грааля для любой системы управления доступом. Такая модель доступа в основе oracle, IBM Tivoli и мн.др. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 12:52 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Курдль, ну дак тут, в APEX уже всё сделано....не по этой модели. Например, в NTFS бит "Запрет" имеет приоритет. Если он есть в объекте, то дальше вообще не проверяется. Т.е. можно админу перекрыть доступ....временно)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 13:02 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Курдль, не делайте из APEX монстра. Переходите на другой ЯП. Это и Оракл советует. APEX это access)) и это отлично! IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 13:09 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Petro123, Причем здесь "приоритет"? И почему "в APEX всё сделано не по этой модели"? Приведенная мною схема позволяет обеспечить разграничение доступа к любому объекту приложения APEX. А можно даже назначить доступ не к объектам, а к сущностям предметной области. Только именовать авторизационные схемы надо будет не "Администратор" или "Шеф_Аудитор", а "Зарплата", "Детализация аудита" и т.п. Petro123Курдль, не делайте из APEX монстра. Переходите на другой ЯП. Это и Оракл советует. APEX это access)) и это отлично! IMHO Я думаю, что маркетологи оракла не согласятся с тем, что АРЕХ = это MS Access :) И я перешел из другой среды на АРЕХ, т.к. того требовали НФТ заказчика. Кстати, завидую твоему положению - ты сам можешь придумывать, сколько АРМов и для каких ролей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 13:20 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльИ я перешел из другой среды на АРЕХ, т.к. того требовали НФТ заказчика. Кстати, завидую твоему положению - ты сам можешь придумывать, сколько АРМов и для каких ролей... я "политикой" не занимаюсь. ТЗ так ТЗ. Всё равно технарю приходится говорить заказчику\PM, что ...будет большой оверхед и дорого\долго. Написать можно всё что угодно. Я тоже выполняю приказы)) как и ты. Как говорится - я предупредил (руководство), и моя совесть чиста. Сущность - это таблица в APEX, т.к. тут нет ОРМ. Т.е. Сущность - авторизация - функция авторизации PL 1 к одному к объекту ГУИ. Ты же сам сказал - неудобно. ......... У меня всё сложности в БД, поэтому - Все схемы авторизации простейшие - плоские. Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 13:48 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
плюс, как всегда, исключения - есть несколько мест в коде с той же проверкой. Это уже без оф.схемы авторизации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 13:50 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльЯ думаю, что маркетологи оракла не согласятся с тем, что АРЕХ = это MS Access :) маркетологи всегда имеют линейку решений. Java же куплена Ораклом)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 13:52 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Petro123Сущность - это таблица в APEX, т.к. тут нет ОРМ. Т.е. Сущность - авторизация - функция авторизации PL 1 к одному к объекту ГУИ. Ты же сам сказал - неудобно. ......... Я под сущностью не объект GUI имел в виду. Сущность предметной области не совсем то название. Надо обдумать точнее. Например, вносим в БД сущность "зарплата" как объект доступа. Даем в БД разрешение на просмотр для Шефа и редактирование - для Бухгалтера. Делаем схему "ЗАРПЛАТА" и все элементы GUI, которые отображают или управляют "зарплатой", привязываем к этой схеме (колонки отчета, поля формы, кнопки или целые формы). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 14:00 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльНапример, вносим в БД сущность "зарплата" как объект доступа. у меня вносим роль - "зарплата" как объект доступа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 14:19 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
КурдльДаем в БД разрешение на просмотр для Шефа и редактирование - для Бухгалтера. grant role Зарплата USER в БД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 14:20 |
|
||
|
Авторизация на основе объединения прав
|
|||
|---|---|---|---|
|
#18+
Petro123КурдльНапример, вносим в БД сущность "зарплата" как объект доступа. у меня вносим роль - "зарплата" как объект доступа Так у тебя пользователи АРЕХ = пользователи оракла! Говорю - тебе повезло с заказчиками, безопасники которых такое согласовали :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2015, 14:23 |
|
||
|
|

start [/forum/topic.php?fid=50&msg=38886949&tid=1875069]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
77ms |
get tp. blocked users: |
2ms |
| others: | 204ms |
| total: | 368ms |

| 0 / 0 |
