![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Реализация системы доступа и АРМа Администратора доступа. [IB6.x, MSSQL, MySQL, dBase, FoxPro, Paradox]
_Lucky_ © (2005-12-07 13:51:00)Как в коммерческих системах реализована система доступа, и АРМ Администратора доступа
т.е. на вид это выглядит так:
Администратор доступа запускает АРМ доступа в котором заводит нового пользователя,
дает ему опеределенные права на выполнение операций и т.д. При этом он не пишет SQL команды, а тыкает мышей, отсюда вытекает вопрос реализации этого механизма. Т.е. заводят ли они какие-то специальные таблицы или как?
Далее на аккаунт пользователя налогаются определенные требования безопасности, такие как периодичность смены пароля, не повторяемость определенного количества паролей, сложность пароля, блокирование пользователя в случае не верного ввода пароля несколько раз подряд. Соответственно все тот же администратор доступа может разблокировать пользователя и заблокировать принудительно.
Очень интересна технология реализации, мне лично пришло на ум одно, добавить таблиц которые будут содержать дополнительную информацию, ну например дату последней смены пароля, признак блокирования и т.д. А как на самом деле такие вещи реализуются.
В принцепе все это интересует приминительно к FireBird 1.5, но если есть какие-то базовые методы, то тоже было бы не плохо их узнать. А м.б. FireBird на такое не способен и нужно просто переходить на что-то более мошьное, я лично видел примеры таких систем на MS SQL и Oracle.
Может есть статейки по этому поводу?
_Lucky_ (2005-12-11 13:35:00) [21]А по поводу политики безопасности юзеров? ну т.е. срок жизни паролей, блокирование пользователей, разблокирование, не повторяемость паролей, сложность паролей и т.д.
Кстати у меня система как раз банковская, хотя и не хранящая финансовой информации, но всеже у них есть четкие и жесткие требования к обеспечению безопасности автоматизированных систем.
> не придется, если ты эти sql команды "подвесиш" на кнопочки,
> либо на > "нужных описаниях (типа "Проводка материальных
> счетов")"
Ну это совсем не интересно, потому что допустим у меня порядка 50 операций, делать 50 кнопочек - это не совсем красиво, да и если нужно будет сделать какие-то изменения, то тоже получится напряжно.
Я думал сделать таблицу в которой скажем написать (наименование операции, SQL ит.д.) ну и типа туда забить все операции, просто тут же встала мысль о том, что м.б. где-то в оракле или мс сиквеле это реализованно на уровне самой субд.
Кстати разграничение нужно сделать как на уровне базы, чтобы нельзя было произвести изменение из какой нить sql консоли (там же меню нет), так и на уровне меню, чтобы пользователю не было видно не его пункты меню.
sniknik (2005-12-10 18:23:00) [22]> мне прийдется написать администратору шпору с SQLем, типа напишешь эту команду и пользователь сможет выполнять
> такие операции...
не придется, если ты эти sql команды "подвесиш" на кнопочки, либо на > "нужных описаниях (типа "Проводка материальных счетов")"
> ну вот есть у меня база, сделал я пользователей...
не пользовате лей, а пользовате ля- одного, админа системы, у которого дожна быть реализована возможность самому создавать/настраивать пользователей/права. (один типа системного должен создаваться с базой, и удалятся не должен (возможности чтобы не было))
но вообще все строго индивидуально, к примеру сейчас у меня тз в котором четко прописано три типа пользователей и их права. без заморочек, причем права не на базу/таблицы/операции а просто на доступ к пунктам меню... (такая "защита" липовая конечно, многие могут в чужой программе неактивный пункт активным сделать... но так прописано, и оговорено (специально уточнял), а так как проект заказан с исходниками, ни шага в сторону сделать нельзя. с другой стороны, для них и такая защита "сверхнадежна" судя по их пользователям, да по тому что "ломать" это никому и в голову не придет (выгоды/смысла нет. не банковская прога то). т.е. права чисто для разделения сферы деятельности, случайно в чужое не влезть).
кстати, действительно, не путай права на базу и права юзера в самой программе, в том же самом рассматриваемом АРМ. (вполне возможно там самый "бесправный" юзер работает под учетной записью админа базы... ну просто не может по другому, сделали так, что все под одним. ;))
(у меня кстати в этой проге тоже все под "овнером" базы "ходят" и ничего. и в 1С также сделано (7ке, 8 не знаю), а в программе уже делится)
то что про sql читал это на права на базу, то что таблицами пытаешся реализовать это получается права в программе, "програмным" пользователям .
вот эти "твои таблицы" я сделал просто набором (set of byte) и храню их в блоб поле записи, но не у юзера а у юзерового типа (их три см. up), в общем то все, при логине набор считывается и по проверке tag in set закрываются/открываются пункты меню (tag-и у них заранее прописал), вот и все разделение прав. ;)
и редактировать можно, в проге не реализовано, но если меняются их "жосткие" требования к правам, поменять их мне пара пустяков. (надо сказать менял всего раз. удивлен ;)
"на крайняк" можно и на каждого юзера такое поле завести, добавить только механизм редактирования этого поля, с подписями что какой бит значит, и будут настраиваемые поля для каждого юзера.
_Lucky_ (2005-12-10 16:48:00) [23]Однако жаль, что никто дельного совета не дал.
Про роли читал, тоже впечатлений 0, потому что там одни SQL команды, я допустим с ними разберусь, хотя это вопрос уже другой, ну а по завершении проекта мне прийдется написать администратору шпору с SQLем, типа напишешь эту команду и пользователь сможет выполнять такие операции, напишешь вот эту и у него появится вот такая операция - в коммерческих прогах которые я видел, у админа был АРМ которым к серверу цеплялся и видел всех пользователей, их права, также там были группы которые содержали операции, он мог их изменять, создавать новые, удалять.
Причем все было понятно, потому что SQL писать не приходилось, он просто кликал на нужных описаниях (типа "Проводка материальных счетов") и все.
В этом же арме он мог видеть/настраивать когда пользователю менять пароль, какой сложности должен быть пароль, какой мин длины, блокировать пользователя, разблокировать, ставить количество ошибок в вводе пароля и т.д.
А я вот чего-то не могу понять как мне это сделать с тем же FireBird, ну вот есть у меня база, сделал я пользователей, но у них нет описанных выше свойств, думал может добавить в базу таблицу с пользователями и их не достоющими свойствами, но тогда прийдется заводить их 2 раза, такое же решение и относительно прав пользовалей создать таблицу в котору внести все операции и таблицу груп, но вот терзают смутные сомнения относительно того, а нет ли способов проще?
alex_*** (2005-12-07 14:10:00) [24]то ли на безопастость винды
Sergey13 (2005-12-07 13:58:00) [25]Наверное все (почти) зависит от того как реализована собственно система доступа. То ли это возложено на сервер БД, то ли реализоано в своих таблицах и вшито в приложение, то-ли некая комбинация первого и второго.
Поищи в инете (или еще где) про роли (как совокупность прав пользователя) в БД.