Пользовательский доступ

[Чудик]

У меня есть программа с главной формой + с подчиненными формами + независемые самостоятельные формы. Данная программа является многопользовательской. На данный момент все пользователи имеют равный доступ ко всем функциям на выше перечисленных формах. Я хочу ограничить доступ, чтобы один пользователь имел доступ только к одним функциям, а другой только к другим, а третий и к тем и к другим.
Решение - Хочу на каждом компе каждого пользователя в реестр прописать некий код доступа, который будет проверяться при открытии любой из форм и если такой код будет отсутствовать в списке данной формы, будет выдаваться соответствующее сообщение. А при наличии в условии необходимого кода будут выставляться ряд Enable с True или False для данного кода соответственно.
Не уверен, что данное решение лучшее. В связи с чем буду услышать любые советы, рекомендации или критику.
Тем более, что список кодов доступа собираюсь проверять в модуле каждой формы путем констукции If x1 or x2 or x3 or x4 or x5 Then ..., что вызывает еще большие сомнения в рациональности данного приема.

[xolod]

Способ нормальный. Только конечно пароли в реестре в открытом виде хранить не стоит

[tyomitch]

Способ не самый плохой, но ломается крайне быстро...

[xolod]

Нет.. можно конечно замарочиться и сделать поддержку сертификатов и лицензий + авторизацию через БД на удаленной машине. Тока думаю он 3dsMax пишет, посему жестоко защищать ему не сильно надо

[GM]

1.Тока не делай, что-та типа этого:

Код: Выделить всё

cmdDelete.enabled = IsSuperAdmin


А то есть такая ф-ция как EnableWindows.
2.Такая защита предпологает, то что я спокойно могу экспортировать ветку с доступом одного компа, и импортировать себе и при этом буду иметь те же права, что и первый.
Так что ключ должен быть зависим от компа.
Пока все.

[Чудик]

Сильно напрягаться по ходу защиты, я считаю, нет необходимости - внешняя защита обеспечивается нашим админом (мы все в домене), а внутренняя (т.е. именно сам доступ программы) может иметь уровень, расчитанный на обычного пользователя. Хотя высказывание GM насчет зависимости ключа от компа заинтересовало. Может, тогда, помимо ключа задействовать и список самих пользователей (название компов)?
Плюс к сказанному, интересует быстродействие такой системы. Может ее можно как-то логически упростить? Чтоб непосредственно сама программа при работе не притормаживала? Допускаю такую возможность...

[klop086]

1 Конечно надо хранить всех пользователей, иначе ты как дал пользователюодно право доступа, а потом тебе надо его изменить. Как ты ему обьяснишь что менять и на что? Самом придётся идти...
2 пиши не в явном виде, а придумай простенькую, но (!) свою систему защиты инфы.
3 попробуй сделать постоянное обновление базы пользователей, пока я ещё не придумал как, но может кто подскажет...

[Rainbow]

Хм... Почитала...
Я правильно понимаю, что если на Комп1 зашел Пользователь1 и запустил программу, то должно быть одно меню. А если на тот же Комп1 зашел Пользователь2, то другое?

А если Пользователь1 зашел на Комп2, но там для него конфигурация еще не была выполнена, то с какими правами откроется программа?

Проще всего проблема решается заведением отдельных пользователей (или групп пользователей) с определенными паролями для самой программы. Почему этот вариант не подходит? Хочется, чтобы программа зависила от пользователя, зашедшего в систему?

Просто получается противоречие - я админ на машине, но программа должна запуститься с правами как для гостя... Может, тогда определять права для пары юзер-компьютер и хранить их на сервере в укромном месте ?

[Dzhon]

Еще вариант:
Права доступа к меню программы определяется для конкретного пользователя, а значения хранятся на сервере (либо РС с базой), когда пользователь производит подключение - проверяются установленные права и доступными (а также видимыми) становятся только разрешенные для данного пользователя пункты меню. При такой организации проверки пользователь становится независим от РС.
Дюже удобно при администрировании !

[Ennor]

У тебя система какую-нить серверную часть имеет? В смысле, нечто, что используется одно на всех юзеров? Если да, то весь контроль прав производить на ней.

[Rainbow]

Права доступа к меню программы определяется для конкретного пользователя, а значения хранятся на сервере (либо РС с базой), когда пользователь производит подключение - проверяются установленные права и доступными

Так а как пользователя-то определить? Если в конторе есть 2 Александра. Один стажер, другой большой босс. Если программа не запаролена, то как их различать будем?

Вот и получается, что либо паролить, либо регистрировать как-то: ну, допустим, при установке указывать специальный ключ (или что-нибудь типа файла с лицензией). И тогда этого пользователя (уникально идентифицировав, например, за счет компа) вносить в базу и указывать там его права. Что-то типа такого...

[Ennor]

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

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

[alibek]

RADIUS

[Ennor]

RADIUS

Не понял. Ты что имеешь в виду, уточни плз. А то я в первую очередь о мониторах подумал, честно говоря...

[Rainbow]

Если чуть-чуть порыться в недрах Мирового Разума, то можно выяснить, что:

GNU Radius is a set of tools for remote user authentication and accounting.
The package includes server daemon, various client utilities, and a set of
administrator tools.


For more information on Radius, including links to file downloads,
please see the Radius web page: http://www.gnu.org/software/radius
and the Radius project page http://savannah.gnu.org/projects/radius

[Чудик]

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

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

Неплохо, вероятно это более совершенный вариант реализации, чем изначальный. Кроме того у нас польская система учета работает именно по такой системе.
Хотя про RADIUS, тоже не понял.

[alibek]

В общем случае, RADIUS (Remote Authentication Dial In User Service) это метод (интерфейс, сервер), обеспечивающий единую авторизацию учетных записей пользователей.
Т.е. пользователь авторизуется лишь однажды на RADIUS-сервере, а прочие системы (AD, почтовый сервер и пр.) авторизуют пользователя через RADUIS.

[Чудик]

Другими словами при помощи Radius можно управлять доступом к любой сетевой программе?

[alibek]

Да, если программа умеет взаимодействовать с RADIUS-сервером.

[Чудик]

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

[Dzhon]

Так а как пользователя-то определить? Если в конторе есть 2 Александра. Один стажер, другой большой босс. Если программа не запаролена, то как их различать будем?

Вот и получается, что либо паролить, либо регистрировать как-то: ну, допустим, при установке указывать специальный ключ (или что-нибудь типа файла с лицензией). И тогда этого пользователя (уникально идентифицировав, например, за счет компа) вносить в базу и указывать там его права. Что-то типа такого...

Пользователя определять по учетной записи, а к компу привязывать нельзя (Ennor уже указал причины).

[Ennor]

У меня есть программа с главной формой + с подчиненными формами + независемые самостоятельные формы. Данная программа является многопользовательской. На данный момент все пользователи имеют равный доступ ко всем функциям на выше перечисленных формах. Я хочу ограничить доступ, чтобы один пользователь имел доступ только к одним функциям, а другой только к другим, а третий и к тем и к другим.
...

Так, еще раз с самого начала. Твои юзеры просто запускают прогу, открывают-закрывают окошки, и все? Или где-то оседает результат их действий - в какой-нить базе данных, в файлах на диске, еще где-нибудь?
Вот доступ к этому хранилищу данных тебе и надо секюрить. Если это база данных, то вопрос снимается - любая мало-мальски серьезная БД в состоянии обеспечить собственную аутентификацию своих пользователей - DBF в расчет не берем, старо. Если же у тебя собственная файловая структура хранилища, тогда... тогда сделай так, как было на моей предыдущей работе, тупо, зато оригинально: на сетевом диске валяется MDW-файл с прописанными в нем юзерами и их правами, при вводе юзером своих логина/пароля прога ломится туда и пытается в этом файле авторизоваться. Если такого юзера/пароля нет, то извините - отлуп. Если же есть, то при любом последующем действии юзера сначала проверяются его права. Тупо и совершенно небезопасно, но видимость создает...

[Dzhon]

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

[Ennor]

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

[Dzhon]

Не спорю! Но при добавлении новых форм в приложение его придется обновлять заново (ерунда если на одной машине, а если гораздо больше)! Кстати тема перекликается http://bbs.vbstreets.ru/viewtopic.php?p=81043

[Ennor]

При добавлении новых форм в приложение тебе и так его обновлять придется, разве нет? А так у тебя будет 2 программы вместо одной.

[Dzhon]

Ну да! Зато код разбит сторого по необходимым кускам и при изменении найти и изменить существующий код гораздо проще. А изменения требуются достаточно часто. А корневую я не хочу компилить каждый раз, поэтому и пытаюсь научиться Dll динамически к пунктам меню привязывать. Ну это я для себя решил что мне так удобней, а для других не факт