ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Разграничение прав доступа
5 сообщений из 5, страница 1 из 1
Разграничение прав доступа
    #34887808
Фотография Black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Black
Участник
Добрый день!

Программа разрабатывается под web, будет работать от имени основного пользователя, который имеет доступ ко всем таблицам проекта, а все остальные "пользователи" будут виртуальными => как, предположим, на любом форуме... мы же не регистрируем их в Б.Д, а просто заносим в таблицу, например, members.

Программа, имеет десятки классов, к методам которых предоставляется доступ на основе привелегий к таблицам Б.Д.

Например, есть класс proprietor, в его подчинение ( на уровне программы ) таблицы:
proprietor
proprietor_xxx
proprietor_stats

Если пользователь имеет привелегию select к таблице proprietor, соответственно ему будет позволено пользоваться методом proprietor.view, если имеет привелегию update, то proprietor.edit, и т.п.

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

Привелегии будут даваться на основе ролей, роль в свою очередь может наследовать привелегии другой роли.
Предполагаю, что структура таблицы для ролей будет следующая:
Имя таблицы members_roles
ROLE_NAME TABLE_NAME COLUMN_NAME PRIV
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
	CREATE TABLE "MEMBERS_ROLES" 
	(
		"ROLE_NAME" VARCHAR2( 100 ) NOT NULL, 
		"TABLE_NAME" VARCHAR2( 100 ), 
		"COLUMN_NAME" VARCHAR2( 100 ), 
		"PRIV" VARCHAR2( 10 )
	)  
	TABLESPACE "USERS";

И таблица предоставленных пользователю ролей.
Имя таблицы members_priv
MEMBER_ID ROLE_NAME
Код: plaintext
1.
2.
3.
4.
5.
6.
	CREATE TABLE "MEMBERS_PRIV" 
	(
		"MEMBER_ID" NUMBER( 11 ) NOT NULL, 
		"MEMEBER_ROLE_NAME" VARCHAR2( 100 ) NOT NULL
	)  
	TABLESPACE "USERS";

Создаем роль default_role, которая будем иметь привелегию select к всей таблицы proprietor, proprietor_xxx
Код: plaintext
1.
2.
INSERT INTO members_roles VALUES ('default_role', 'proprietor', NULL, 'select');
INSERT INTO members_roles VALUES ('default_role', 'proprietor_xxx', NULL, 'select');

Если мы хотим предоставить пользователю привелегии роли default_role, нам необходимо в таблицу members_priv сделать insert с значениями ID пользователя, имя роли.
Код: plaintext
1.
INSERT INTO members_priv VALUES ( 1 , 'default_role');
Тут думаю все предельно просто ...

Вопрос для меня в следующем, как правильно спроектировать наследование ролей.

Предположим есть вторая роль second_role, она имеет привелегию update к таблице proprietor_stats.
Код: plaintext
1.
INSERT INTO members_roles VALUES ('second_role', 'proprietor_stats', NULL, 'update');

Теперь попробуем наследовать ролью default_role привелегии роли second_role , для этого создаим третью таблицу members_roles_inheritance
ROLE INHERITANCE_ROLE
Код: plaintext
1.
2.
3.
4.
5.
6.
	CREATE TABLE "MEMBERS_ROLES_INHERITANCE" 
	(
		"ROLE" VARCHAR2( 100 ) NOT NULL, 
		"INHERITANCE_ROLE" VARCHAR2( 100 ) NOT NULL
	)  
	TABLESPACE "USERS";
Код: plaintext
INSERT INTO members_roles_inheritance VALUES ('default_role', 'second_role');

Думаю структура на первый взнляд логична ...

Теперь усложним, предположим роль second_role наследует привелегии роли third_role
Код: plaintext
1.
2.
3.
4.
-- Даем роли привелегии 
INSERT INTO members_roles VALUES ('third_role', 'proprietor', NULL, 'delete');
-- Наследуем 
INSERT INTO members_roles_inheritance VALUES ('second_role', 'third_role');

Получается, что теперь роль default_role имеет привелегии ролей second_role, third_role.

Как Вы думаете, насколько данная структура имеет право на жизнь?

Для меня очень серьезным вопросом остается, как мне потом получить все привелегии для пользователя, если роль наследует роль, та роль в свою очередь наследует еще роль как было показано выше?!

Заранее благодарен за помощь и любые комментарии!
...
Рейтинг: 0 / 0
23.10.2007, 13:45
| Ответить | Цитировать | Написать  
Разграничение прав доступа
    #34893534
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Мы убрали наследование прав внутри ролей. Так прикладные админы больше путались. И еще у нас был принцип-1 пользователь-1 роль,потому как довольно часто наблюдаются перемешивания полномочий внутри "многоролевого" пользователя.
...
Рейтинг: 0 / 0
25.10.2007, 11:02
| Ответить | Цитировать | Написать  
Разграничение прав доступа
    #34893569
Mainframe_старый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe_старый
Участник
Нормально наследование работает, наоборот куча проблем решается - есть роль редактор всех документов некоторого типа. Она наследуется от роли редактор отдельного документа . Т.е. все кто имеют роль редактор документов типа А, сразу становятся редакторами всех документов типа А. Но можно дать пользователю редактирования отдельных документов. При этом при наследовании мы указываем связи по какому параметру наследование идет - в данном случае по типам.
...
Рейтинг: 0 / 0
25.10.2007, 11:09
| Ответить | Цитировать | Написать  
Разграничение прав доступа
    #34893666
Фотография Black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Black
Участник
ShtockМы убрали наследование прав внутри ролей. Так прикладные админы больше путались. И еще у нас был принцип-1 пользователь-1 роль,потому как довольно часто наблюдаются перемешивания полномочий внутри "многоролевого" пользователя.
Как уже сказал Mainframe_старый , данная структура решает очень много проблем, легче управлять пользователями "одним кликом", а для каждого пользователя своя роль, это слишком накладно, а если их 300, 500 ...

То, что я пытаюсь реализовать, основано на разграничение доступа в Oracle, все П.О. я пишу использую данную Б.Д., но сейчас как уже говорил, появилась необходимость написать программу под WEB, и мне не хочется создавать десятки пользователей, которые будут иметь доступ извне.
...
Рейтинг: 0 / 0
25.10.2007, 11:34
| Ответить | Цитировать | Написать  
Разграничение прав доступа
    #34894426
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
BlackТо, что я пытаюсь реализовать, основано на разграничение доступа в Oracle, все П.О. я пишу использую данную Б.Д., но сейчас как уже говорил, появилась необходимость написать программу под WEB, и мне не хочется создавать десятки пользователей, которые будут иметь доступ извне.
Во-первых, десятки пользователей лучше создать без всякого описанного здесь геморроя. Для тысяч - можно поискать другое решение, например, использовать OID.

Во-вторых, даже для тысяч пользователей следует создать серверные роли. Скажем, для упомянутого Вами форума это будут роли "гость", "пользователь", "модератор", "администратор". Каждой такой роли - соотнести серверный account; соответственно, "десятки пользователей" будут логинится под эккаунтом своей роли. В принципе также можно воспользоваться механизмом application role, но имхо это неоправданный геморрой.
...
Рейтинг: 0 / 0
25.10.2007, 14:13
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Разграничение прав доступа
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=34887808&tid=1544225]:
 0ms
get settings:
 5ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 157ms
get topic data:
 7ms
get forum data:
 5ms
get page messages:
 38ms
get tp. blocked users:
 1ms
others: 231ms
total:  457ms
созд. / загр.: 457ms
x
x
Закрыть


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