Интерфейс клиента...

← →
Cranium (2003-06-09 14:29) [0]

Вопрос в следующем... Поделитесь способом решения формирования интерфейса клиента в зависимости от роли пользователя... Мне на ум проиходит два варианта решения, это
1)Писать для каждого пользователя(набора прав свое приложение):((
2)Формировать интерфейс динамически...
а)Хрнить в базе таблицу соответствия доступности элементов интерфейса пользователя (пункты меню, формы и т.д.) и формировать интерфейс при запуске клиента (лучший вариант на мой всгляд в связки с ActionList)
б)Читать права на доступность к таблице, тригеру, ХП и т.д. во время выполнения приложения
в)....?
Кто что может присоветовать?

← →
Alexandr (2003-06-09 14:46) [1]

это очень сложный и многогранный вопрос.
тут нет единственно верного решения.
И каждый разработчик разрабатывает свои метод на этот счет.
Никая универсализация тут пока невозможна.
И разработчики не очень-то торопятся раскрывать свои секреты в этой области.
Короче все зависит только от твоей квалификации. Чужие советы и наработки тут практически бесполезны.

← →
AkaSaint (2003-06-09 14:47) [2]

Вариант б), по-моему, самый нормальный. Ты можешь при логине пользователя проверить все эти параметры сразу и установить Visible=false для недоступных данному ползователю элементов упрвления. Вариант а) имхо себя не оправдывает - слишком большая трудоемкость, а эффект - как от б).

← →
roottim (2003-06-09 14:57) [3]

я сам ориентируюсь на написании АРМ.. в этом случае отличий форм пользователя мало...

приблизительное решение...
1. по запросу получаеш уровень доступа пользователя (0,1,..,2 и тд)
2. у всех контролов всегда есть св-во tag, если оно незаюзано, то именно сюда и пиши уровень доступа
3. по созданию формы - для контролов с tag > уровень доступа - делаеш то что тебе необходимо.

← →
Nikolay M. (2003-06-09 15:42) [4]

Я храню права юзеров на сервере. После авторизации юзера передаю назад клиенту информацию о его правах (просто битовая комбинация), соответственные кнопки (или ActionItem-ы) делаю (не)доступными. Но при таком подходе никто не мешает послать в твою формочку EnableWindow и разрешить все кнопки. А по поводу того, как лучше сделать ограничение прав на сервере (в случае с тонким клиентом) я спрашивал тут:
http://delphimaster.net/view/3-1054731566/
Буду делать так: проверять на сервере действие, выполняемое юзером и, если у него нет на это действие прав, генерировать ошибку.

← →
Cranium (2003-06-09 16:39) [5]

> Но при таком подходе никто не мешает послать в твою формочку
> EnableWindow и разрешить все кнопки

Да, но я говорил при интерфейс, уровень доступа к данным определяется правами пользователя на таблицы, ХП и т.д. Сервер все равно не даст выполнить доступ к данным....

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

← →
Sandman25 (2003-06-09 16:44) [6]

В крайнем случае можно написать процедуру проверки доступа и засунуть ее вызов в каждый обработчик (кнопки и т.д.).
Но лучше сразу строить только то, что нужно. Кроме как создания форм в runtime я способов не вижу.

← →
Cranium (2003-06-09 16:44) [7]

> roottim (09.06.03 14:57)

> ... tag > уровень доступа

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

← →
Sandman25 (2003-06-09 16:49) [8]

Cranium © (09.06.03 16:44)

А вот это реализуется с помощью механизма View либо продвинутой системой (с заведением справочников типов документов, предоставления к ним доступа и т.д.)

← →
Cranium (2003-06-09 16:54) [9]

> А вот это реализуется с помощью механизма View либо продвинутой ......

Об этом и речь....

← →
Sandman25 (2003-06-09 17:10) [10]

Если View, то например
create view viw_my_docs as select * from all_docs where creator = user;
revoke all on all_docs from public;
grant select, delete, update, insert on my_docs to public;
В viw_my_docs будут только те док-ты, которые завел сам пользователь (в informix sql есть функция user, равная login"у пользователя, при записи по триггеру или в хранимой надо записывать данное поле)

Если продвинутая, то тут уже все только от тебя зависит. Какие объекты охраняются, какие уровни доступа и т.д. Короче, от предметной области зависит. Изучи, проклассифицируй, с заказчиком пообщайся.
У нас, например, в спец. таблице записаны, номера молов, к товарам которых имеет доступ конкретный пользователь. В другой таблице записаны типы справочников, которые пользователь может изменять. В третьей таблице записаны типы док-тов, к которым имеет доступ пользователь. И еще много разных таблиц...

← →
Sergey13 (2003-06-10 09:10) [11]

2Cranium © (09.06.03 16:39)
>Мне нужно создать механизм динамического формирования интерфейса
Ты хочешь написать одно приложение для ВСЕГО ВААЩЕ? Или же у тебя будут все таки некие АРМы но с разными правами. Первое, ИМХО - утопия, второе, опять же ИМХО, легче всего организовать как у AkaSaint (09.06.03 14:47).

← →
Polevi (2003-06-10 10:49) [12]

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

Sub Init
Self.Button1.OnClick=Button1_Click
End Sub

Sub Button1_Click
Self.Caption="wwdfsdf"
End Sub

← →
Polevi (2003-06-10 10:52) [13]

http://www.compress.ru/Temp/1773/index.htm

← →
Сергєєв Володимир (2003-06-10 11:24) [14]

Я эту фигню подсмотрел в одной проге и щас активно использую в своих программах.

В базе данных есть таблицы "Пользователи", "Меню", и "Меню пользователей".

"Пользователи" состоит из доменов "Код", "Имя", "Пароль" (и еще там кое-что но это неважно)
"Меню" - "Код меню", "Код предка", "Заголовок", "Выполнить".(В общем, - классическая древовидная структура, кому не ясно - сходите к деревьям в SQL).
"Меню пользователей" - "Код пользователя"("Пользователи"), "Код меню"("Меню")
Далее ХП выбырает менюшки для данного пользователя в зависимости от логина и пароля.

Указатели менюшек главного меню формы выстраиваются в событии AfterConnect (TIBDataBase). У всех менюшек в таге хранится ее "код" в базе данных. У всех обработчик обытия OnClick, в котором многовложенный блок
if MenusStr.Strings[(Sender as TComponent).Tag]="Тому-то" then
То-то
else
if MenusStr.Strings[(Sender as TComponent).Tag]="Тому-то" then
То-то
else
........
if MenusStr.Strings[(Sender as TComponent).Tag]="Тому-то" then
То-то
В событии BeforeDisconnect(TIBDataBase) менюшки грохаются.

Таким образом мы имеем динамически выстраиваемые меню программы в зависимости от прав пользователя. Так что SendMessage тута не поможет (посылать просто некому :)))

Если есть вопросы, то могу поделиться готовым компонентом (TIBMainMenu & TIBMainMenuSecure)для работы с такой структурой(писалось для себя под InterBaseExpress). Обращаться на мыло.

Интерфейс клиента... Найти похожие ветки