К вопросу об администрировании и распределению прав... в прогах при работе с данными на SQL сервере.

Этот вопрос к работе любого сервера (не только на IB и др.), но ведь вы с базой все равно на какой-нибудь проге работаете...

Задал вопрос на Delphi и чей-то, как-то, никому и никак...
Хочу узнать как делают это другие...

НАПРИМЕР: при вводе данных необходимо обеспечить распределение прав между пользователями типа:
- занесение заказов (заявок)
- простановка дат изготовления (планирование)
- заполнение технологии (порядка работы)
- ...

При этом на одной форме операций разные пользователи заносят данные только в свои поля...

Если делать только на уровне прав базы - то не приятно нажав Ок получить сообщение что у вас нет прав... Лучше вообще не давать это делать...
Делать отдельные формы для каждого - глупо (сегодня у него одни права, а завтра - другие).

Я создал служебные таблицы в которых храню 'Имена форм', 'Имена объектов на формах' и 'Права доступа к объектам'.

На OnCreate формы считываю этот список в массив, а на OnShow раставляю своийства Enabled и Visible в соответствии со списком прав пользователя (который получаю при входе в систему)...

При этом 'запрещенные' кнопки, меню... - серенькие или нет совсем.
Для удобства элементы разбиты на группы по панелям (чтоб не задавать для каждого).

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

При этом все реализуется просто (цепляешь по две функции к формам) и правами рулиш без изменения проги (вплоть до права печати отчетов)...

Поделитесь своим опытом, кто что знает и какие у кого в этом вопросе проблемы...

GoldПосмотри IBXUserProfile - потом и нам расскажешь, а то у меня времени небыло смотреть :-(

Благодарю... хоть что-то... бум смотреть...

А что больше это никому не нужно? Или уже давно решеный вопрос?
Тогда дайте хотябы ссылку...

Спасибо за обсуждение, не успел ничего спросить… (рабочий день кончился).

Пару слов от себя:

GoldПосмотри IBXUserProfile - потом и нам расскажешь, а то у меня времени небыло смотреть :-(

Посмотрел… Ну что сказать… Возможно кого-то заинтересует… но хранение прав в BLOB меня не прельщает…

Winni-Pooh
А почему бы не просматривать RDB$USER_PRIVILEGES…
…это универсально.

Хоть это форум IB и др., но если говорить об универсальности то, как быть с Oracle, MS и др.
Каждый варится в собственном соку… У меня сегодня IB – а завтра его могут уничтожить как класс и все делать на Oracle (на нем - зарплата и сие от меня не зависит).

Winni-Pooh
…ВСЕ ДОЛЖНО ХРАНИТЬСЯ В БАЗЕ ДАННЫХ, даже схемы обработки документов.

Разве в RDB$USER_PRIVILEGES есть перечень прав к формируемым отчетам? Или предлагаешь их туда занести?

Igor Elyas
Уровень прав на приложении не совсем хороший тон. Часть прав все равно надо делать на уровне БД.

Проверка прав прогой вовсе не исключает наличие прав в БД.
Я согласен, что безопасность - это комбинация приложения и БД, но разве есть какая-то разница между работой через ХП с ограниченными правами и заданию этих же прав на элементы прогой?

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

Главное - я уяснил – что сделал не так уж и плохо…
мож кто истчо чо добавит…

alex_k
В моем случае пользователи работают не с таблицами, полями или процедурами, они работают с документами и свойствами документов.


Что значит - работают с документами?

Если это таблица с полями свойств и BLOB полем для хранения файла документа - то какая разница?

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

Соответственно, если все визуальные элементы будут перечислены с правами доступа, то любое действие в проге можно рулить...

И пускай не смущает 'большой' перечень прав... ведь в твоей проге они серано задаются и проверяются... а на деле перечень окажется не очень большим.

У меня есть таблица групповых прав и состав групп

Например: Технические службы->Конст.Тех.отдел->Технологи->Ведущий технолог

Задав юсеру право 'Ведущий технолог' - он автоматом получает и все остальное...
Чем ниже право - тем больше, но уже.
Можно задать любую группу включив туда всего помаленьку...
Весь перечень прав я получаю по ХП одним запросом...

Dik76Посмотри здесь. имхо: это то что доктор прописал :)))

Не понял юмора... я не такой гигант мысли...

Ну потратил я на создание этих таблиц и форм их редактирования пару дней...

Потом за полчаса переделал программку...

Зато теперь не надо менять прогу из-за того, что кому-то что-то надо разрешить или запретить...

Dik76
…там есть ядро безопасности.
…Переписывать ни чего не надо.

Не для меня все это… В одиночку такое не делают… И что значит ‘ни чего не надо’?

Насколько я понял, сама прога должна быть написана с обращением к объекту ядра…
Что мне писать новую прогу? Времени нет и на текущие дела…
Да и не бесплатно это…

to alex_k

Если прога берет данные не из таблиц – то я пас…
Хотя их наверно тоже можно перечислить и описать (в прогу же закладываешь какую-то логику)

Да и с прямым вводом в грид нужно делать немножко по другому…
Ведь грид – это один объект, а нужен доступ к ячейкам грида…

Я над этим не заморачивался… у меня просто нет прямого редактирования в гридах.

to Igor Elyas

Winni-Pooh этот вопрос продолжил в теме: Multi-Tier, или трехзвенка

Dik76
Сама идея - вот суть.

Идея - это хорошо... а у тебя как реализовано? Или тока идеи?

Dik76
...упрощенная версия ядра...

Ты динамически создаеш ФОРМЫ с меню или только меню на готовых формах?

Если только меню......
А если формы, то на них кроме меню бывает целая куча различных элементов ввода...

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

А на счет модуля Администрирования... дык я на него и потратил 2 дня...
Просто создать таблицы и занести туда права обычным SQL Explorer можно и за час... (немного загнул... смотря сколько форм и прав).

Dik76
...объекты системы...

Насколько я понял твои объекты имеют мало что общего с тем куда ты меня посылал... вот там точно крыша съедит...
Можешь сам посмотреть в разделе 'Проектирование' тема 'Люди свершилось...'

Твой объект 'сотрудник' привязан к полю таблицы или элементу ввода на форме с указаниеп его типа? (Edit, ListBox...)

И вообще под какую задачу пишешь? Или просто заготовка на будущее?

Dik76
...ядро безопасности лишь модуль...
…указывается их визуальное представление...

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

Зри внимательней… там две части: свойства связанные с данными (таблицами, их взаимодействием и защитой) и свойства интерфейса проги… (хотя тоже с правами)

Не нужно их скрещивать (не Мичурин ведь)… Ничего хорошего не выйдет…
А вот визуальные свойства и права их действия для пользователя являются едиными, поскольку относятся к общим объектам.
Например: TEdit.Enabled, Visible, ReadOnly и OnClik… как в прочем и TForm.Height, Width и др.

Dik76
Делаю не зависимую систему…

Нужно быть немного реалистичней, если конечно хош создать нечто, чем заинтересуются другие…
Если сделать модуль (лучше в виде компоненты) который позволит с минимальной доработкой проги ее разрулить… т.е. автоматизирует заполнение таблиц свойств допуска…

Например: поможет из Application выдернуть все формы, из Form все объекты, а из Object его свойства, методы и проставить им соответствующие права…
Тоды любой смогёт это быстро сделать и возможно даже спасибо скажут…
Лично у меня сейчас на это времени нет…
Если интересует могу описать что получилось по подробнее...

mapnn
…использовать простые пользовательские переменные (неважно где их хранить) наподобие ini – файла…


Вот тут я с тобой не согласен… Очень даже важно…
Какой геморрой творится в ini… особенно если этих настоек много… Для этого есть реестр, но…

Если хранить их на сервере – то получишь независимость от компа… Пользователь получит свои настройки на любой машине… И рулить ими легче в одном месте…

А вот считанные данные действительно можно хранить в простом массиве строк, например TStringList.

Я считываю настройки для формы только один раз (при ее создании), а потом уже (при ее выводе) устанавливаю свойства объектов из полученного массива.

При этом все параметры получаю одним SELECT из ХП без особого увеличения нагрузки и времени выполнения…
И при смене пользователя, настройки для форм - те же (не нужно их перечитывать), просто при ее выводе свойства сменятся согласно новым правам…

mapnn
...в виде некоторой структуры в блобе (доп. плюс - возможность шифрования)...

Большой привет! Я не считаю себя БОЛЬШИМ программистом, да и на форуме недавно…
olol – это от имени (Злобин Олег)…
Сервер не дал назваться Oleg – типа такой уже есть и просто ol нельзя меньше четырех…

Игорь, ну не нравиться мне работа с BLOB... некий кусок непонятно чего...
Это хорошо только если там данные хранятся простым списком...
А шифровать можно и в обычном CHAR (главное не перестараться)...

Ведь нет ни какой разницы, если ты создаешь всего ОДНУ служебную табличку или ДЕСЯТЬ…
Я не против твоей компоненты, но смотри, что получается…

Все данные прекрасно бьются на связанные таблицы (формы, объекты, права…) и не нужно придумывать параметры типа Form1Edit1Enabled…
А потом программно присваивать соответствующей компоненте нужное свойство…

Я потому так быстро и переделал прогу под это управление, что каждой форме задал всего два события:

// В форме…

void __fastcall TForm1::FormCreate(TObject *Sender)
{ SLObj = new TStringList(); SLObj->Sort(); DMS->GetFrmAccess(SLObj, "Form1");
}//---------------------------------------------------------------------------
void __fastcall TForm1::FormShow(TObject *Sender)
{ DM->SetFrmAccess(SLObj, Form1); SelectFirst();
}//---------------------------------------------------------------------------

// В дата модуле…

void __fastcall TDM::GetFrmAccess(TStringList* SL, AnsiString ShFrm)
{ AnsiString s, ShObj,ShAcs;
s = "SELECT ShObj, ShAcs FROM psSFrmShFrm(:ShFrm) ORDER BY IdObj";
quSQL->SQL->Clear(); quSQL->SQL->Add(s);
quSQL->Params->ParamValues["IdExe"] = IdExe;
quSQL->Params->ParamValues["ShFrm"] = ShFrm;
quSQL->Open(); SL->Clear();
TField *FLShObj = quSQL->FieldByName("ShObj");
TField *FLShAcs = quSQL->FieldByName("ShAcs");
while (!quSQL->Eof)
{ ShObj = FLShObj->AsString; s = "";
while (FLShObj->AsString == ShObj && !quSQL->Eof)
{ ShAcs = FLShAcs->AsString;
if (s.IsEmpty()) s = ShObj.Trim() + "="; else s += ";";
s += ShAcs.Trim(); quSQL->Next();}
SL->Add(s);}
quSQL->Close();
}//---------------------------------------------------------------------------
void __fastcall TDM::SetFrmAccess(TStringList* SL, TForm* FM)
{ AnsiString s,ShObj,ShAcs; TComponent *CP; TControl *CT; TMenuItem *MI; bool b;
for (int i=0; i < SL->Count; i++)
{ ShObj = SL->Names ; ShAcs = SL->Strings; ShAcs = LStrGetR(ShAcs, "=");
CP = FM->FindComponent(ShObj);
if (CP)
if (CP->InheritsFrom(__classid(TControl)))
{ CT = (TControl*)CP; CT->Enabled = DMS->CheckAccess(ShAcs);}
else if (CP->InheritsFrom(__classid(TMenuItem)))
{ MI = (TMenuItem*)CP; MI->Enabled = DMS->CheckAccess(ShAcs);}}
}//---------------------------------------------------------------------------

Извиняй что на C++Builder…
Самый простой пример для установки всего одного свойства ‘Enabled’…
Для ЛЮБОЙ компоненты из TControl и TMenuItem…

Это конечно далеко не идеал, максимально упростил для понимания…
И работает только в случае, если каждый объект имеет одно право допуска…
(если есть несколько перекрывающихся, то нужен дополнительный цикл для суммы прав)

Процедура ‘psSFrmShFrm’ получает список прав, а CheckAccess – просто проверяет наличие этого права у пользователя…

Ведь и заполнять эти таблицы можно автоматически, как я говорил раньше…
Если установить этот модуль в прогу, запустить ее и вызвать настройку – она сама переберет все что найдет и заполнит их… (кроме прав, конечно)

А вот с базой она должна работать все-таки через ADO… (IB конечно неплохой, но не единственный…)
К тому же некоторые вещи все равно ODBC требуют, например: Crystal Reports или у нас CAD/CAM Adem…