Форум: "Базы";
Текущий архив: 2002.09.23;
Скачать: [xml.tar.bz2];
ВнизМодель безопасности ? Найти похожие ветки
← →
Vicheslav (2002-08-31 08:50) [0]Уважаемые подскажите пожалуйста!
Необходимо в базе в небольшой торговой организации
(склад+торговые точки+бухгалтерия+клиенты и т.д.)
доступ к данным только по процедурам.
Создать разграничение прав пользователей все пользователи
обращаются к одним и тем же процедурам (по принципу одна универсальная
клиентская программа)
но один получает например Ф.И.О. клиента а другой полную информацию ИНН,Р/СЧ
и т.д.
для всех(но разных таблиц). Назначение только прав доступа к процедурам
явно недостаточно.
А хочется сделать гибкую систему прав.
Пробовал каждую таблицу организовывал в виде дерева (запись-права на
запись)для каждой таблицы
проверка производится в процедуре опираясь на имя пользователя но такой
объём кода получился
а менеджер настолько сложный.
Помогите пожалуйста подскажите пойдя по какому пути можно решить эту
проблему.
← →
Петров Денис (2002-08-31 10:45) [1]Добрый день, Vicheslav.
Как насчет такого варианта?
Пусть в базе данных есть таблица Table1 со структурой записи (Field1, Field2, Field3). Есть два пользователя - один должен просматривать только поле Field1, а другой - только поля Field2 и Field3. Вы создаете в базе две хранимых процедуры, одна из которых возвращает (или изменяет) набор данных для первого пользователя, а вторая - для другого, соответственно.
Для хранения прав доступа (то есть запсией вида "<имя_пользователя>-<таблица>-<имя_процедуры1>-<имя_процедурыN>", где N - максимальное количество операций, которые Вы хотите совершать над таблицами базы) можно использовать вспомогательную таблицу базы данных. Например, если пользователь USER1 не имеет прав на изменение таблицы TABLE1 (допустим, инструкцией UPDATE), но имеет права на просмотр, то запись будет имет примерно такой вид:
...
USER1 TABLE1 <NULL> SP_UPDATE_TABLE1
...
Таким образом, предъявляемое Вами требование гибкости к системе прав сохраняется, так как процесс создания и удаления хранимых процедур на SQL-серверах вешь достаточно легкая. А реализовать раздачу прав можно так: при создании пользователя базы администратор выбирает набор функций, доступных пользователю (например, бухгалтер по работе с первичкой имеет право только создавать платежные поручения), а программа администрирования (написанная, естественно, Вами) создает соответствующие процедуры и раздает права на них. Настоятельно рекомендую создать свой менеджер пользователей и прав!
Что касается кода на Delphi, то, конечно, Вам придется работать исключительно с создаваемыми run-time аргументами хранимых процедур и полями запросов. О создании их во время разработки при такой постановке задачи и речи быть не может.
← →
KSergey (2002-09-02 07:16) [2]Не понятны слова " по принципу одна универсальная клиентская пограмма". Если она одна универсальная - как в ней реализован механизм отображения для одного пользователя одних полей, а для другого - другой? Формочки все же разные для разных пользователей или как? А если разные - тогда уже не универсальная получается... И процедуры тогда можно разные делать...
Или хорошо, такой вариант: процедуры на сервере универсальные в том смысле, что возвращают все возможные поля, но при этом на клиенте отображаются только нужняе поля. Излишняя нагрузка на сеть, да. Критично?
Одним словом, уточните: как на клиенте реализовано отображение различных полей - тогда будет понятно что можно "присоветовать" ;). Или же эту задачу (формирование списка полей) должен выполнять сервер? А клиент что будет делать при этом (если нет какого-то поля)?
← →
maratFromTomsk (2002-09-02 13:20) [3]у нас в самом деле есть одна универсальная клиентская программа
которая понимает определеннный набор входных данных
(xml on HTTP)
чт касается системы прав,
то она написана на уровне объектов их методов и атрибутов
то есть можно указать доступ на уровне классов, экземпляров объектов и т.д.
хотя это достаточно накладно ...
а вообще используется трехуровневая архитектура
← →
Vicheslav (2002-09-02 14:36) [4]{Если она одна универсальная - как в ней реализован механизм отображения для одного пользователя одних полей, а для другого - другой? Формочки все же разные для разных пользователей или как? А если разные - тогда уже не универсальная получается... И процедуры тогда можно разные делать...}
Формы одни а процедура одному возвращает некоторые поля остальные оставляя пустыми а другому заполняет все поля.
То же самое на update,insert... чтоб клиент из постороней программы не мог в обход клиентской программы....
← →
KSergey (2002-09-03 06:26) [5]остальные оставляя пустыми
Т.е. нек. поля на форме просто остаются постыми, я так понимаю (или из процедуры просто вместо них возвр. пустые значения? тоже можно, но несколько хитрее получится)...
Ну тогда, похоже, что Петров Денис (31.08.02 10:45) прав по поводу таблицы с соответствием полей и пользователей. Ну а дальше в процедуре наверное так: при формировании выходной выборки из нее (процедура, что на select) используем USER_NAME и т.п. для определения пользователя, и формируем динамически состав команды select в строковой переменной, выполняя ее по exec(). Аналогично, видимо, можно извернуться с процедурами на insert и update.
[прошу прощения, я только сейчас глянул, что речь про IB сервер. Я все говорил в предположении MS SQL. Понадеюсь, что в IB сервере есть аналогичные механизмы]
← →
maratFromTomsk (2002-09-04 06:27) [6]По поводу того что должен видеть пользователь
Пользователь входит в некоторую группу
Группа определяет права доступа к классам, объектам их атрибутам и методам (список можно поменять).
Я считаю что формочки надо делать по одной на каждую группу пользователей.
По хорошему, пользователь не должен знать более того что он должен видеть (меньше знаешь - лучше спишь). Не дай боже, он увидит некоторое поле, которое ПОЧЕМУ-ТО НИЧЕГО НЕ ПОКАЗЫВАЕТ!!!
это нарушает душевное равновесие
и пользователей
и сопровождающих систему.
И все равно кто захочет тот добъется ...
а вот в таблице другое дело:
- ничего не стоит сделать переменный набор колонок для таблицы,
- а для одного объекта что то типа Object Inspector.
таблицы из двух колонок
наименование_атрибута значение_атрибута.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.09.23;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.009 c