|
|
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
Господа! Зашел в тупик =(. Есть у меня таблица с клиентами. Клиенты делятся на несколько разных категорий (количество категорий может меняться со временем). При этом, один клиент может относится к нескольким категориям сразу. Есть пользователи БД, которые тоже деляться на группы (1 пользователь может относится только к одной группе). Пользователи могут совершать над записями о клиентах следующие действия: создание, просмотр, изменение. В зависимости от принадлежности пользователя к той или иной группе, он должен иметь разные права доступа к полям таблицы с клиентами в зависимости от принадлежности клиента к той или иной категории. С созданием новых записей проблем нет - либо пользователь может создавать новую запись (и заполнять все поля таблицы с клиентами), либо не может. С просмотром тоже более-менее понятно - можно сделать нужное количество вьюх и назначить права доступа соответствующим группам пользователей. Но как быть с редактированием?!! Пока я реализовал систему так: Создал таблицу ID группы пользователей, ID категории клиентов, права доступа к полю1, (0 - нет доступа, 1 - чтение, 2 - чтение,запись) права доступа к полю2, .... Создал ХП [1], которая возвращает права доступа к полю1, полю2, ... по ID группы пользователя и ID категории клиента. Создал ХП [2] и [3] для загрузки и редактирования данных по клиенту, которые сначала обращаеются к хранимке[1], и решают, что какие поля можно выдавать пользователю или редактировать, а какие нет. Программа-клиент вызывает ХП [1] и настраивает вид окна по ее результатам (отключает недоступные контролы), после чего вызывает ХП [2] или [3]. На мой взгляд все это очень неустойчиво и плохо модифицируемо. Может быть кто-нибудь сможет подсказать лучший вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2006, 15:08 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
1)По таблице прав - не очень удачно, что объекты доступа задаются позиционно. Лучше ID группы пользователей, ID категории клиентов, имя поля, права доступа к полю (0 - нет доступа, 1 - чтение, 2 - чтение,запись) 2)Интерфейс клиента через хранимые процедуры - по-моему вполне гибкое и настраиваемое решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2006, 16:50 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
И к каждому полю обращаться по имени с помощью хранимки, которая делает проверку его на доступность? - мне кажется тяжеловато серваку будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2006, 17:35 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
> 0 - нет доступа, 1 - чтение, 2 - чтение, запись Есть права уровня объектов базы данных: select, insert, update etc. Есть набор логических прав: чтение, редактирование, добавление и т. д. Я бы не считал их эквивалентными. > Создал ХП [1], которая возвращает права доступа к полю1, полю2, ... по ID > группы пользователя и ID категории клиента. А зачем смотреть на группу пользователя? Достаточно программно обработать отказ в доступе. > На мой взгляд все это очень неустойчиво и плохо модифицируемо. Да. > лучший вариант? Сформулируйте задачу целиком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2006, 17:47 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
2_guest_20040621: Сформулируйте задачу целиком. Задача сформулирована в первом посте. По-сути дела надо осуществлять контроль доступа пользователей к отдельным ячейкам таблицы. Т.е. я не могу запретить или разрешить доступ ко всем строкам выбранного столбца таблицы некоторому пользователю. Насколько мне известно, средствами БД (MS SQL 2000) это не реализуется - вот и извращаюсь. А зачем смотреть на группу пользователя? Достаточно программно обработать отказ в доступе. Данные по клиенту возвращаются хранимкой в виде однострочного датасета. Часть полей доступны, часть недоступны. Для того, чтобы разобрать что доступно, а что нет - делается предварительный запрос (ХП [1]). Можно, конечно, написать отдельную хранимку и обращаться к нужным полям по очереди по имени, но для этого придется делать в несколько раз больше обращений к серверу. Является ли такой подход более рациональным? Есть права уровня объектов базы данных: select, insert, update etc. Есть набор логических прав: чтение, редактирование, добавление и т. д. Я бы не считал их эквивалентными. Не совсем понял к чему это? Работа напрямую с таблицами (через insert, select, update и т.д.) пользователю запрещена. Вся работа идет через хранимки на которые раздаются права. Правда, частично проверка прав будет происходить и внутри некоторых хранимок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2006, 20:07 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
> Задача сформулирована в первом посте. Нет. В Вашем сообщении Вы рассказали о Вашем видении проблемы, а не о задаче. > По-сути дела надо осуществлять контроль доступа пользователей к отдельным ячейкам таблицы. Почему "к ячейкам"? Это есть в техническом задании? Как поставлена исходная задача? Я бы, например, привел ее к стандартной - row-level access control. Тупой декомпозицией. Imho в данном случае - самый разумный путь. > Не совсем понял к чему это? К тому, что Вы делаете типичную ошибку: одновременно проверяете права доступа и на уровне метаданных, и на уровне данных. Причем, используете при этом и систему контроля доступа СУБД, и собственные правила. Каша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2006, 21:48 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
>Задача сформулирована в первом посте. Нет. В Вашем сообщении Вы рассказали о Вашем видении проблемы, а не о задаче. Ок. Тогда так: есть каталог клиентов. Каждый клиент может подпадать под одну или несколько категорий. Примеры категорий: "частый клиент", "оптовый клиент", "VIP клиент" и т.д. Клиенты характеризуются такими параметрами, как персональные данные (ФИО, пасспорт, ...), контактные даннные (телефоны, адрес, ...) и т.д. Пользователи группы А, имеют возможность: Код: plaintext 1. 2. 3. 4. 5. 6. Пользователи группы B, имеют возможность: Код: plaintext 1. 2. 3. 4. 5. 6. Запрет имеет больший приоритет, чем разрешение: если клиент относится к категориям "VIP" и "частый", то пользователи группы А не имеют доступ к информации по клиенту, а пользователи группы B могут читать перс. и контактные данные. Предполагается, что категории клиентов будут добавляться и удаляться. > По-сути дела надо осуществлять контроль доступа пользователей к отдельным ячейкам таблицы. Почему "к ячейкам"? Это есть в техническом задании? Как поставлена исходная задача? Я бы, например, привел ее к стандартной - row-level access control. Тупой декомпозицией. Imho в данном случае - самый разумный путь. Проблема в том, что ТЗ нету. Пишу со слов заказчика, потом переделываю =( Кроме того сама постановка задачи периодически меняется =(((( Последняя формулировка задачи озвучена выше. row-level access control Тупой декомпозицией.[quot] Это есть в MS SQL? (BOL'а сейчас под рукой нету) [quot]Каша. Согласен =\ Если в MSSQL 2000 есть row-level access control - буду пробовать сделать все на уровне БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2006, 23:52 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
> Пользователи группы А, имеют возможность: Понятно. Т. е. access control в чистом виде. > Проблема в том, что ТЗ нету. Пишу со слов заказчика, потом переделываю Не жалко времени? > Это есть в MS SQL? Декомпозиция - как бы безотносительно СУБД. Что есть и чего нет в M$ SQL - не знаю, никогда не сталкивался (надеюсь, никогда и не придется). > буду пробовать сделать все на уровне БД Imho при такой постановке задачи проще сделать на уровне данных. Полагаю, проблема может быть решена декомпозицией структуры данных до состояния, когда контроль доступа осуществляется на уровне строки. Если есть иерархия групп, есть еще более простое решение: разделить понятия уровня доступа и прав (из Вашего пояснения непонятно, есть иерархия групп или нет). Поищите в Сети RBAC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 09:21 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
mr.Garry Можно, конечно, написать отдельную хранимку и обращаться к нужным полям по очереди по имени, но для этого придется делать в несколько раз больше обращений к серверу. Является ли такой подход более рациональным? Зачем по отдельности для каждого поля? Ест таблица поля_таблиц - syscolumns. По ней с указанием таблицы прямо и джоиниться на права и выдавать списком все поля с правами. Все быстро. просто и за один раз. И потому сделать как предложил ModelR - не номер поля а имя. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 09:50 |
|
||
|
Вопрос по проектированию
|
|||
|---|---|---|---|
|
#18+
Всем ответившим спасибо! Нашел нужную статью на РСДН. tygraЗачем по отдельности для каждого поля? Ест таблица поля_таблиц - syscolumns. По ней с указанием таблицы прямо и джоиниться на права и выдавать списком все поля с правами. Все быстро. просто и за один раз. У меня права раздаются не на столбцы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 20:50 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1545429]: |
0ms |
get settings: |
5ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
136ms |
get topic data: |
6ms |
get first new msg: |
3ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 425ms |

| 0 / 0 |
