Ограничение доступа к данным
Народ! Поделитесь опытом, кто как в Билдере организовывает запреты доступа для юзеров? Расскажите на стратегически-организационном уровне - есть справочник пользователей, при загрузке проекта юзер вводит пароль, а дальше что, список кнопок которые надо блокировать? Чего делать-то? Теряюсь в вариантах. Еще нужен раздельный доступ для чтения или редактирования, ну и чтобы добавлять и редактировать права доступа легко можно было. У кого опыт есть?
Пардон. Что-то эксплорер зачудил.
Идея в принципе неплохая. Мы в свое время блокировали кнопки (во времена когда по 3 юзера на компе сидело). Только в справочник не список кнопок а права, типа 1 - полный 2 - чтение и т.д. а потом switch - case и Properties Enabled то-ли True то-ли False и нормально.
Только если у тебя есть нормальный сервер (типа 2000) я бы это на админа скинул и вообще никакие пароли не ставил. Тем более что админам тоже нужно свой хлеб отрабатывать:)
Только если у тебя есть нормальный сервер (типа 2000) я бы это на админа скинул и вообще никакие пароли не ставил. Тем более что админам тоже нужно свой хлеб отрабатывать:)
В том-то и дело что это заказ сторонней мелкой организации где 5 компов и 10 юзеров, так что задача остается ;)
А как права-то назначать? Как понять какая кнопка каким правам соответствует?
по одному на каждую категорию пользователей? :-)
Это, чтобы юзера не обижались, что они чего-то не могут сделать в проге, а видели лишь доступные кнопки. Если этого не надо, то, наверное, можно каждой кнопочке в Tag, например, записать число, характеризующее категорию пользователя, которому кнопа доступна. Тогда после логина можно сделать одним циклом сделать disabled все элементы управления с Tag > чем у текущего юзера.
Это просто идея. Не делал никогда...Но скоро предстоит, кажется...
В том-то и дело что это заказ сторонней мелкой организации где 5 компов и 10 юзеров, так что задача остается ;)
А как права-то назначать? Как понять какая кнопка каким правам соответствует?
Да не мудрили мы ничего сверхестественного. К справочнику юзеров добавляли поле key_access и в TForm ...
switch (key_access)
{
case 1 : // полные права
Button1->Enabled = true;
Button2->Enabled = true;
Button3->Enabled = true;
RadioButton1->Enabled = true;
RadioButton2->Enabled = true;
break;
case 2 : // частичные
Button1->Enabled = true;
Button2->Enabled = false;
Button3->Enabled = false;
RadioButton1->Enabled = false;
RadioButton2->Enabled = true;
break;
case 3 : // просмотр
Button1->Enabled = false;
Button2->Enabled = false;
Button3->Enabled = false;
RadioButton1->Enabled = false;
RadioButton2->Enabled = false;
break;
default : ;
}
сколько нужно секций по case - столько и создавали, может не совсем красиво, но отслеживать и изменения вносить очень легко. Да и форма смотрится неплохо. Можно конечно динамически кнопки и прочее создавать, но тогда внешний вид страдает (пустые прорехи некрасиво смотрятся).
Этот способ удобен (по сравнению с кучей case как в предыдущем сообщении) тем что защита не зашита в программу и соответственно не приходится при изменении её параметров перекомпилировать программу и высылать её заказчикам
Этот способ удобен (по сравнению с кучей case как в предыдущем сообщении) тем что защита не зашита в программу и соответственно не приходится при изменении её параметров перекомпилировать программу и высылать её заказчикам
А, что значит НЕЗАШИТА? У тебя три способа доступа (ну ладно пусть не три, а предположим пять). А заказчик выдумал шестой. Как твоя идея отследит способ доступа, о котором раньше даже речи не было.
А если их три, то чем это отличается от трех case-ов ? И чего тогда переписывать? Чегой-то непонял.
А, что значит НЕЗАШИТА? У тебя три способа доступа (ну ладно пусть не три, а предположим пять). А заказчик выдумал шестой. Как твоя идея отследит способ доступа, о котором раньше даже речи не было.
А если их три, то чем это отличается от трех case-ов ? И чего тогда переписывать? Чегой-то непонял.
"Не зашита" означает что программа пишется без знания того что кому-то будут раздавать права на доступ к отдельным её частям, это делает её код более прозрачным и соответственно надёжным. А весь механизм ограничения прав на доступ делается в совсем другом месте и также не зависит от смысла тех частей программы, доступ к которым нужно ограничить. Таким образом, обе эти части получаются более удобными и надёжными - типичное применение принципа "разделяй и влавствуй".
При этом модификация как программы так и системы защиты может происходить независимо. Допустим если заказчик попросил 6 уровней доступа (не подскажешь, кстати, каких?) вместо 3 - не надо переписывать всю программу, вставляя повсеместно новые case, нужно изменить только небольшую по объёму подсистему защиты.
Допустим если заказчик попросил 6 уровней доступа (не подскажешь, кстати, каких?)
Подскажу. У той-же 2000: Полный доступ,Изменить,Чтение и выполнение,Список содержимого папки, Чтение, Запись.
У Novell таких параметров уже 12, так, что изобрести конкретный доступ не проблема (кстати заказчик, как правило и не знает, что такое доступ), все на уровне "Света должна делать это, Ира - другое, а Саша ... список можно продолжить.
По поводу разделения подсистем - согласен. У нас сейчас подобные вещи в COM сидят, и рассылаем мы DLL. Но говорить о том, что это быстро и просто, а также о том, что переписывать ничего не надо, не приходится.
Похоже мне больше подходит вариант мистера Берга :). Видимо нужно создать табличку с именами юзеров, паролями и списком кодов доступа (1,2,3 ...). После ввода пароля находится нужная строка и нужные коды запоминаем в векторе например. В формах соответственно назначаем tags для кнопок, затем при загрузке форм проверяем соответствие тэга кнопки значениям в векторе и устанавливаем Enabled. Ну и отдельная форма для редактирования прав должна быть. Окиньте мудрым взгдядом - все ли по уму?
Тоже выход.
У нашего коллектива система отображения красотой не отличается, вопросы решены более глобально. Есть форма отображения - куча меню и пустое окно. Есть конфигуратор, который позволяет под конкретного юзера открыть/закрыть/добавить пункты меню. Под пункты меню вешаются формы с возможностью настройки (естественно в ограниченых пределах).
Подскажу. У той-же 2000: Полный доступ,Изменить,Чтение и выполнение,Список содержимого папки, Чтение, Запись.
У Novell таких параметров уже 12, так, что изобрести конкретный доступ не проблема (кстати заказчик, как правило и не знает, что такое доступ), все на уровне "Света должна делать это, Ира - другое, а Саша ... список можно продолжить.
По поводу разделения подсистем - согласен. У нас сейчас подобные вещи в COM сидят, и рассылаем мы DLL. Но говорить о том, что это быстро и просто, а также о том, что переписывать ничего не надо, не приходится.
Я вообще-то говорил о доступе к контролам (типа кнопкам, едит-боксам и т.п.), так что "Список содержимого папки" выглядит несколько экзотично, хотя всё возможно конечно. По текущему опыту выявилось что для _наших_ задач ничего кроме тех 3 уровней доступа не нужно. Но опять же - сколько бы новых уровней доступа не появлялось, если базовая функциональность и защита независимы, то изменить защиту на порядок проще чем лазить по всей программе и выискивать case или расставлять разные значения тегам.
Просто есть люди которые пишут программу в рассчёте что она никогда не будет меняться и потом при изменении условий начинают хвататься за голову и кричать что заказчик не сформулировал до конца все условия и теперь надо всю программу переписывать. А ведь всего-то и нужно - всё время помнить что практически все части программы придётся менять и постараться соломки подстелить уже при написании начальной версии
Если файлы, не дай бог, лежат на локальной тачке, рядышком с клиентом, то защита на уровне отключения кнопочек - этож вообще курам на смех. Так тока Микрософт делает :). В таком случае надо по меньшей мере шифровать данные на диске, а лучше конечно выносить их на сервак.
Или я чёто не понимаю???
А нельзя ли по-конкретнее насчёт того, к чему ограничивается доступ? Если к базе данных, которая лежит на сервере, то тут всё более менее ясно: передаёте юзернейм и пароль, а дальше уже сервак сам решает, какие операции разрешать для данной транзакции.
Если файлы, не дай бог, лежат на локальной тачке, рядышком с клиентом, то защита на уровне отключения кнопочек - этож вообще курам на смех. Так тока Микрософт делает :). В таком случае надо по меньшей мере шифровать данные на диске, а лучше конечно выносить их на сервак.
Или я чёто не понимаю???
Насколько я понял первоначальное сообщение и про что я отвечал - речь идёт про ограничение доступа к функциональности программы. Разумеется защаита данных должна делаться адекватными средствами, например на уровне SQL-сервера
В таком случае надо по меньшей мере шифровать данные на диске, а лучше конечно выносить их на сервак.
Или я чёто не понимаю???
Все ты правильно понимаешь :). Только задача в следующем - мелкая сторонняя контора, там сервак Novell и 5 раб.станций (вынь 98), десяток людей (бухгалтера, менеджеры итд, в основном молодые девицы) каждый вносит свои данные. Заказчик просит сделать так, чтобы народ мог попадать только в "нужные" рабочие области, вот съёбственно и все! Никто там отдельные dbf-ники искать не будет, серого вещества не хватит, да и юзерам времени на это не дадут.
for i:=0 to Form1.ControlCount-1 do
if Form1.Controls.Tag>1 then
Form1.Controls.Visible:=false;
Здесь Tag - уровень доступа к данному компоненту, как тебе и советовали, а 1 - это уровень доступа текущего юзера.
Так будет маленько попроще, чем юзать всякие case, Особенно если сделать это ввиде отдельной процедуры, которой в качестве параметра будет передаваться форма. Вот и всё.
ЗЫ
простите за Паскаль, просто на этой тачке у меня тока Дельфи стоит. и 3-й Билдер.
Вот только категории пользователей добавлять будет проблематично. Хотя можно вместо 0,1,2,3 давать 10,20,30, тогда и запас диапазона будет...:-)
Novell и 5 раб.станций (вынь 98), десяток людей (бухгалтера, менеджеры итд, в основном молодые девицы) каждый вносит свои данные.
Как доступ организовать, тут уже идей много набросали. Доступ, доступом, но в таких случаях (я так понял у тебя файловый сервер) мы делали таблицу с полями что-то типа (давно было) "data_time_change","user_password","N_tabl","N_Zap". Начальству это нравилось:) Т.к. на копм "зашел" один, потом пошел покурить, а другой наворотил. Но отвечать все равно есть кому:)