ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
25 сообщений из 106, страница 2 из 5
  2  все
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576447
-------------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-------------
Участник
Вопрос к гуру - сколько ошибок в такой схеме:
Проверка доступа:
Код: plaintext
EXISTS (Текущий_Пользователь, Запрошенное_Действие, Требуемые_Данные) IN Разрешение(Пользователь, Действие, Данные)

где Разрешение(Пользователь, Действие, Данные) может быть получено, например, из следующего набора отношений:
Код: plaintext
1.
2.
3.
Членство (ID_Роли, ID_Охватывающей_Роли)
Видимость_Данных(ID_Роли, Данные)
Разрешенные_Действия(ID_Роли, Действие, Тип_Данных)

???
схема несколько упрощена, т.е. к примеру, Видимость_Данных() может задаваться несколькими подобными таблицами
...
Рейтинг: 0 / 0
02.03.2006, 12:17
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576657
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeСхема роль+группа дает возможность включения одной роли в несколько групп. Ваш же подход исключает такую ситуацию.
Кто Вам сказал такую глупость?

Код: plaintext
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.
Connected to Oracle9i Enterprise Edition Release  9 . 2 . 0 . 7 . 0  
Connected as system


SQL> create role role1 ;

Role created

SQL> grant select on sys.dual to role1 ;

Grant succeeded

SQL> create role role2 ;

Role created

SQL> create role role3 ;

Role created

SQL> grant role1 to role2 ;

Grant succeeded

SQL> grant role1 to role3 ;

Grant succeeded

SQL>
...
Рейтинг: 0 / 0
02.03.2006, 12:57
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576802
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarer SublimeСхема роль+группа дает возможность включения одной роли в несколько групп. Ваш же подход исключает такую ситуацию.
Кто Вам сказал такую глупость?

[src oracle]Connected to Oracle9i Enterprise Edition Release 9.2.0.7.0
Connected as system


Аналитика+Давайте откинем стандартные возможности СУДБ, таких как гранты Oracle и тому подобное

Насколько я понял тема поднята для обсуждения структуры БД, исключая дополнительные возможности такие как role Oracle.
...
Рейтинг: 0 / 0
02.03.2006, 13:22
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33578978
iamhere
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iamhere
Участник
А что - есть стандартизованное определение термина "роль"? ;)
Можно ссылочку на стандарт?

Утверждение "роли не могут включаться в другие роли" такое же бестолковое, как и утверждение "роли могут включаться в другие роли", потому оба этих утверждения основаны просто на возможностях конкретных программных продуктов (кто уж какие видел...), и на том, что понятие "роль" или "группа" означает в этих продуктах.
...
Рейтинг: 0 / 0
03.03.2006, 10:09
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33579005
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeНасколько я понял тема поднята для обсуждения структуры БД, исключая дополнительные возможности такие как role Oracle.
Вы сказали две глупости - сначала "роль не может включаться в роль", потом - "нельзя организовать включение в несколько ролей". В контексте "обсуждения вообще".

Я показал Вам первый попавшийся под руку пример обратного. Oracle - вполне входит в "вообще"; то, что можно сделать в нем, никто не мешает сделать где-либо еще. Если верить логике, этого достаточно, чтобы опровергнуть Ваше утверждение.
...
Рейтинг: 0 / 0
03.03.2006, 10:15
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33579277
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
можно глупый вопрос?
что будет если:
Код: plaintext
1.
grant role1 to role3 ;
grant role3 to role1 ;
если так низзя - то _явное_разделение иерархии на (иерархические) "группы" и (простые, "аксиоматические"=="базовые") "роли" _кажется_ _мне_ предпочтительным (логически прозрачно, и кажется, можно все то же, что и для более сложной системы иерархии только ролей). (Это же просто напоминает отрезание листов (в данном случае уместнее говорить "корней", что не принципиально) от иерархии, с выделением их в отдельную "базовую" сущность, как правило, оправданное.)

возможно есть преимущества одной из схем в быстродействии, но какой именно - может быть кто-то растолкует? (мне попадались в основном лесовидные иерархии, сильно растущие по части листьев - там их выделение в обособленные сущности спасает, тут же кажется множественное наследование и какие унутре его проблемы - я чесно говоря не знаю)
...
Рейтинг: 0 / 0
03.03.2006, 11:11
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33579756
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
4321что будет если:
Код: plaintext
1.
grant role1 to role3 ;
grant role3 to role1 ;

Думаю, сообщение о циклической зависимости. (проверив) Да, именно так.

4321
если так низзя - то _явное_разделение иерархии на (иерархические) "группы" и (простые, "аксиоматические"=="базовые") "роли" _кажется_ _мне_ предпочтительным (логически прозрачно, и кажется, можно все то же, что и для более сложной системы иерархии только ролей).
Думаю, это философский вопрос. Мне кажется, Вы пренебрегаете мнением старины Оккама.

В любом случае, следует отметить что. В интерфейсе администрирования никто не мешает построить нравящуюся Вам модель. В ней потребуется ввести операцию "преобразовать роль в группу" - но я так понимаю, Вы на это согласитесь. Но! С точки зрения реализации - между этими понятиями нет никакой разницы; это должен быть один механизм, одна таблица с флажком "роль или группа есть данная конкретная запись". Собственно пример на тему:

Код: plaintext
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.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Connected to Oracle9i Enterprise Edition Release  9 . 2 . 0 . 7 . 0  
Connected as system

SQL> select username from dba_users where substr ( username,  1 ,  1  ) = 'O' ;

USERNAME
------------------------------
OWB
OWBRT_SYS
OWB_RT
OWB_USER
OUTLN
ORDSYS
ORDPLUGINS
ODM
ODM_MTR
OLAPSYS
OE

 11  rows selected

SQL> select role from dba_roles where substr ( role,  1 ,  1  ) = 'O' ;

ROLE
------------------------------
OEM_MONITOR
OWB_OWB
OLAP_DBA
OWBR_OWB

SQL> select name, type# from sys.user$ where substr ( name,  1 ,  1  ) = 'O' ;

NAME                                TYPE#
------------------------------ ----------
OUTLN                                    1 
OEM_MONITOR                              0 
ORDSYS                                   1 
ORDPLUGINS                               1 
ODM                                      1 
ODM_MTR                                  1 
OLAPSYS                                  1 
OWB_OWB                                  0 
OLAP_DBA                                 0 
OE                                       1 
OWB                                      1 
OWBR_OWB                                 0 
OWBRT_SYS                                1 
OWB_RT                                   1 
OWB_USER                                 1 

 15  rows selected

4321с выделением их в отдельную "базовую" сущность, как правило, оправданное.
Оправданность здесь с моей точки зрения - вопрос вкусов. Во всяком случае объективных аргументов в ту и другую сторону мало.

Собственно, несколько месяцев назад мне пришлось по работе выдержать как раз такой спор. Мне пришлось несколько недель повторять коллегам-начальникам, что в той идеологии системы, которую мы строим, понятия "группа" и "отчет" оказываются неразличимыми, целиком совпадают по функционалу и свойствам. Несколько недель люди пытались внести то или иное искусственное различие, прежде чем наконец окончательно убедились, что от этого идет только лишний геморрой.

4321возможно есть преимущества одной из схем в быстродействии, но какой именно - может быть кто-то растолкует?
Эти схемы не должны отличаться ни в чем, кроме пары мелочей в интерфейсе. Соответственно все их различие - в восприятии.
...
Рейтинг: 0 / 0
03.03.2006, 13:01
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33580056
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarer SublimeНасколько я понял тема поднята для обсуждения структуры БД, исключая дополнительные возможности такие как role Oracle.
Вы сказали две глупости ... в контексте "обсуждения вообще".
Я показал Вам первый попавшийся под руку пример обратного.

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

softwarer
Oracle - вполне входит в "вообще"; то, что можно сделать в нем, никто не мешает сделать где-либо еще.

И как вы в вашей БД сделаете назначение одной роли нескольким другим ролям? Предвижу ваш ответ: через новую таблицу. И как бы вы назвали эту вашу новую сущность для группировки ролей?
...
Рейтинг: 0 / 0
03.03.2006, 14:03
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33580925
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeВо-первых мы сдесь обсуждаем конкретно поставленную задачу
Это не соответствует действительности.

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

SublimeС такими примерами в сад, пожалуйста. Сейчас вы поймете почему:
Я сомневаюсь в Ваших способностях пророка, но независимо от этого просил бы говорить по делу.

SublimeИ как вы в вашей БД сделаете назначение одной роли нескольким другим ролям?
Хм. Связь многие ко многим. Методы реализации известны.

SublimeИ как бы вы назвали эту вашу новую сущность для группировки ролей?
Хм. ACC$ROLE_ROLES, как-нибудь так. Какой будет следующий вопрос - по отсечению циклов? Могу рассказать, тоже тривиально делается.
...
Рейтинг: 0 / 0
03.03.2006, 17:02
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33583017
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarerДумаю, это философский вопрос...
В любом случае, следует отметить что. В интерфейсе администрирования никто не мешает построить нравящуюся Вам модель.
4321с выделением их в отдельную "базовую" сущность, как правило, оправданное.
Оправданность здесь с моей точки зрения - вопрос вкусов. Во всяком случае объективных аргументов в ту и другую сторону мало.

Мне нечего добавить - Вы сами все за меня сказали.
...
Рейтинг: 0 / 0
06.03.2006, 07:58
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33583474
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
softwarer 4321с выделением их в отдельную "базовую" сущность, как правило, оправданное.
Оправданность здесь с моей точки зрения - вопрос вкусов. Во всяком случае объективных аргументов в ту и другую сторону мало.

Соответственно все их различие - в восприятии.
немного поразмыслив, соглашусь:
отдельной сущностью-листами (базисной сущностью) для дерева групп/ролей будут видимо сами правила (доступа). Собирание же их по иерархии групп/ролей в принципе не сильно отличается для обоих подходов. а т.к. кажется нет причин запрещать цеплять элементарное правило к любому уровню иерархии, то и видимо нет особой ценности в выделении отдельной сущности "базовая роль".
...
Рейтинг: 0 / 0
06.03.2006, 11:21
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33674286
Фотография insect
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
insect
Участник
softwarer ShtockГде тут функция?
Если обобщать, доступ к функции есть частный случай доступа к данным (недоступность функции == пустое множество данных, для которых она доступна). Но такое обобщение представляется мне непрактичным; неудобным ни для рассуждений, ни для реализации.
Есть такое понятие из начальной теории построения компьютеров - Машина фон Неймана... там код и данные равноправны ...
И то, что для одних является данными для других является программами... так работают современные операционные системы...
...
Рейтинг: 0 / 0
18.04.2006, 17:27
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33674687
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
insectЕсть такое понятие из начальной теории построения компьютеров
softwarerНо такое обобщение представляется мне непрактичным
...
Рейтинг: 0 / 0
18.04.2006, 19:42
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33684688
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
-------------
Код: plaintext
1.
2.
3.
Членство (ID_Роли, ID_Охватывающей_Роли)
Видимость_Данных(ID_Роли, Данные)
Разрешенные_Действия(ID_Роли, Действие, Тип_Данных)



Видимость_Данных - это одно из Разрешенных Действий.
...
Рейтинг: 0 / 0
23.04.2006, 00:33
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33684801
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>-------------
>Guest
>EXISTS (Текущий_Пользователь, Запрошенное_Действие, Требуемые_Данные)...

Наболевший вопрос.
Если позволите, перефразирую его для многозвенки.
Текущий_Пользователь - удаленный клиент информационной системы, его аутентификация и авторизация производится сервером приложений.
Запрошенное_Действие - функция, выполняемая сервером приложений.
Требуемые_Данные - выборка, построенная сервером данных из допустимых клиенту строк в разных таблицах.
Подскажите пожалуйста, идеи построения схем ограничения доступа клиента к строкам таблиц.
Группировал клиентов (число групп <1024) и закреплял за клиентом и строками таблиц битовое поле (закреплял за клиентом список ему разрешенных групп ).
Но сосет, что-то не так, может есть более быстрые и интересные варианты?.

С уважением, Владимир.
...
Рейтинг: 0 / 0
23.04.2006, 11:03
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685037
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ВМоисеевПодскажите пожалуйста, идеи построения схем ограничения доступа клиента к строкам таблиц.
Группировал клиентов (число групп <1024) и закреплял за клиентом и строками таблиц битовое поле (закреплял за клиентом список ему разрешенных групп ).
Но сосет, что-то не так, может есть более быстрые и интересные варианты?.

С уважением, Владимир.
распределяйте по Ролям->Пользователям точки входа , а не содержимое. Это единственная, подтверждаемая практикой, модель.
Представьте пример. Вас пустили в зал с товаром, часть которого можно взять, а часть нет. Не находите геммороем? Так почему в ИС его пытаются постоянно создать? Лучше разделить на два зала. Платите деньги и получайте ключ от двери, за которой доступно все.
...
Рейтинг: 0 / 0
23.04.2006, 20:22
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685050
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> распределяйте по Ролям->Пользователям точки входа, а не содержимое.
> Это единственная, подтверждаемая практикой, модель.

Чушь. Как раз на практике моделей больше, чем упоминается в этом обсуждении.

> Представьте пример.

Плохой пример. Политика доступа может (вообще говоря - и обязана) быть конфигурируемой. Прямая аналогия - операционные системы.
...
Рейтинг: 0 / 0
23.04.2006, 20:58
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685102
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Прежде чем называть что-то чушью, приведите реальный пример. Из практики С удовольствием бы проанализировал.
А так эти кнопки (видеть, редактировать, удалять и т.п.) лишнее, хоть и есть и работает. Только не используется, потому что до использования не доходит.
А насчет политики доступа - кто же спорит. Конечно должна быть конфигурируемой. Не оспаривается. Только Вы не о том. О чем.. не понял.
p.s.
Вы в гостинице. Перед Вами несколько дверей. Открываете одну из них. Видите 3 кровати. Одна из них ваша. На 2 других нельзя. Пробуйте.
...
Рейтинг: 0 / 0
23.04.2006, 23:17
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685121
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> приведите реальный пример

Пример чего? Моделей? Легко. Тривиальная модель доступа в общем виде: RBAC + ACL + контекст. Обсуждаемые здесь модели получаются из тривиальной путем удаления соответствующих компонентов. Причем, именно тупым удалением.

> Только Вы не о том.

О том, о том. Вы не допускаете существования альтернативных правил, - это принципиальная ошибка. Ограничивается доступ к содержимому, никаких "точек входа" нет и быть не может. Это Ваша вторая принципиальная ошибка.

> Пробуйте.

Что "пробуйте"?
...
Рейтинг: 0 / 0
24.04.2006, 00:15
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685126
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Скажите сначала в чем ошибка, потом можно продолжать обсуждать.
А то я говорю о ролевом доступе (RBAC, если Вы любите сановские абревиатуры), списках разрешенных точек доступа (ACL для любителей), которые в итоге предоставляют пользователю некий контент, а Вы мне в ответ - это чепуха, с аргументами в цикле. Определитесь и поговорим.
...
Рейтинг: 0 / 0
24.04.2006, 00:32
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685146
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Скажите сначала в чем ошибка

Мне написать еще раз то же самое? В этом обсуждении упоминаются только и исключительно кастрированные варианты моделей ограничения доступа. Вы утверждаете, что этих кастрированных моделей для практического применения достаточно. Это не так.

> списках разрешенных точек доступа (ACL для любителей)

Здесь нет никаких "точек". Есть список. Разница, надеюсь, понятна?

Вы намеренно опустили контекст? Напрасно. Это наиболее важная часть ограничения доступа. Причем, именно с практической точки зрения.

> с аргументами в цикле

Никаких циклов. Очевидная ахинея imho не требует развернутого объяснения.
...
Рейтинг: 0 / 0
24.04.2006, 01:49
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685197
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
:) Мои пять копеек в эту кашу :)

Как мне кажется, сначала все достаточно просто.
Есть множество пользователей.
Есть множество функций.
Есть множество объектов, над которыми могут выполняться функции.
Требуется с минимальным геморроем управлять отношением (многие ко многим ко многим)
между пользователями, фкнкциями и объектами.
И тут все сразу становится сложно...
Вводятся группировки. Группировка пользователей - это группа. Группировка функций - это роль.
Группировка объектов - это танцы с бубном, натянутые на конкретную схему данных.
А сочетание информационных схем для группировки пользователей, ролей и данных, и, наконец, само отношение (пользователи(группы)-функции(роли)-данные) в результате зависит от целесообразности в каждом конкретном случае и фантазии разработчика...
...
Рейтинг: 0 / 0
24.04.2006, 07:04
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685442
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
?Как мне кажется, сначала все достаточно просто.
Есть множество пользователей.
Есть множество функций.
Есть множество объектов, над которыми могут выполняться функции.

Есть множество пользователей + иерархия групп пользователей
Есть множество функций + иерархия групп функций.
Есть множество объектов + иерархия групп объектов.
Права раздаются группам пользователей на группы функций и группы объектов. После преобразований получаем:
пользователь - функция
пользователь - объект
По этому ре-ту и проверяем права. Не так уж сложно.
...
Рейтинг: 0 / 0
24.04.2006, 10:18
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685636
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
?Группировка пользователей - это группа. Группировка функций - это роль.

Жизнеспособная схема из практики.

Роли объединяют функции (соответственно становятся доступными некие данные, пункты меню и т.д. и т.п.). Роли используются для выдачи прав конкретным пользователям. Роли не объединены в иерархию. Любой администратор безопасности будет затрудняться думать в терминах ролей и пытаться сделать из ролей полноценные наборы должностных обязанностей (потом у него будут проблемы, когда люди начнут в силу объективных причин совмещать часть функций от разных должностей). Но вообще схема достаточно гибкая, не думаю что стоит делать проще. Без группировки функций можно очуметь, выдавая пользователям по нескольку десятков разрешений. Однако средство просмотра набора прав доступа пользователя должно иметься, просто показать список ролей недостаточно.

Группы пользователей имеет смысл использовать для организации доступа к данным. Логически понятие группы пользователей от роли, конечно, практически не отличается. Но в житейском смысле это разные вещи. В типичной СЭД групп пользователей оказывается много, а ролей - очень мало. В типичной OLTP - наоборот. Могут возникнуть какие-то тонкости, в результате которых придется реализовать обе концепции.

Первый же вариант (выдача прав пользователю) реализуется что так, что так, путем создания группы (или роли) из (для) одного пользователя.
...
Рейтинг: 0 / 0
24.04.2006, 11:16
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685730
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Согласен скорее с ?
Пример, когда доступность данных зависит от функции:

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

И за какой дверью лежат накладные?
...
Рейтинг: 0 / 0
24.04.2006, 11:41
| Ответить | Цитировать | Написать  
25 сообщений из 106, страница 2 из 5
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=33685050&tid=1545286]:
 0ms
get settings:
 6ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 152ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 70ms
get tp. blocked users:
 1ms
others: 202ms
total:  459ms
созд. / загр.: 459ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]