| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Реализация системы доступа и АРМа Администратора доступа. [IB6.x, MSSQL, MySQL, dBase, FoxPro, Paradox]
_Lucky_ © (2005-12-07 13:51:00)Как в коммерческих системах реализована система доступа, и АРМ Администратора доступа
т.е. на вид это выглядит так:
Администратор доступа запускает АРМ доступа в котором заводит нового пользователя,
дает ему опеределенные права на выполнение операций и т.д. При этом он не пишет SQL команды, а тыкает мышей, отсюда вытекает вопрос реализации этого механизма. Т.е. заводят ли они какие-то специальные таблицы или как?
Далее на аккаунт пользователя налогаются определенные требования безопасности, такие как периодичность смены пароля, не повторяемость определенного количества паролей, сложность пароля, блокирование пользователя в случае не верного ввода пароля несколько раз подряд. Соответственно все тот же администратор доступа может разблокировать пользователя и заблокировать принудительно.
Очень интересна технология реализации, мне лично пришло на ум одно, добавить таблиц которые будут содержать дополнительную информацию, ну например дату последней смены пароля, признак блокирования и т.д. А как на самом деле такие вещи реализуются.
В принцепе все это интересует приминительно к FireBird 1.5, но если есть какие-то базовые методы, то тоже было бы не плохо их узнать. А м.б. FireBird на такое не способен и нужно просто переходить на что-то более мошьное, я лично видел примеры таких систем на MS SQL и Oracle.
Может есть статейки по этому поводу?
evvcom (2005-12-15 08:46:00) [1]
> это кто нить как нить реализовывал?
кАнЫчнА!
> Вывод как раз правильный =), я не сказал про пользователей,
> а про операции типа:
> - оборотная ведомость
> - выписка из лицевого счета
> - оборотно-сальдовая ведомость
> - оборотно-сальдовая ведомость с разбивкой по периодам
> - и т.д. 50 штук
> Мне предлагали для каждой такой операции сделать кнопочку
Вывод неправильный. Операции ты эти чем будешь реализовывать? Я делаю через хранимки, кто-то предпочитает вьюхи - разницы (в администрировании) никакой. Для хранимки:grant execute on <ProcedureName> to <UserName | RoleName>;для вьюхи:grant select on <ViewName> to <UserName | RoleName>;И никаких 50 штук кнопок, всего одна. Единственное, что надо будет все же сделать, это создать свою табличку, в которой будет соответствие имени процедуры или вьюхи какому-то осмысленному комментарию.
> т.е. м.б. некоторый чел написал бы бери MSSQL там все это
> делается 2-мя командами =)
> Пока мне фсе равно какая СУБД.
Да никто не даст тебе верного однозначного совета. И двумя командами это не делается нигде. Я пишу сейчас на Oracle, раньше на MSSQL. Oracle мне нравится больше. Но это не значит, что теперь я должен всех ориентировать на Oracle. Oracle надежнее, но дороже и сложнее для понимания. Что выберет твое руководство? Что для него важнее? Надежность или дешевизна? Собирай плюсы и минусы по каждой из претендующих на покупку СУБД и решай с руководством, что вы можете себе позволить, а с чем мириться не согласны.
menart (2005-12-15 08:00:00) [2]в серверных субд все все равно делается SQL командами просто, все реализовано кнопочками. Типа
GRANT SELECT ON table1 TO user1 AS Accounting
_Lucky_ (2005-12-14 19:38:00) [3]
> примерно то самое у меня и есть ([4] последний абзац) только
> названо по другому, у меня даются права типу (админ, менеджер,
> пользователь) а юзеру задается уже этот тип и соответственно
> его права.
> назови это по другому, не тип юзера, а группа предустановленных
> прав юзера, и не храни в одном месте как у меня (т.к. у
> меня жесто задано) а копируй в запись юзера (или храни у
> юзера ссылки на эти группы прав), и будет практически то
> что ты хочеш.
Вот наконец-то растолковывают =)
Дело то в чем, я например бывший студент, отучился, дипломчик защитил, тока в универе почему-то все не дочитывали, ну и типа базы они прочли, курсач мы сделали, к диплому допустили, мы его сделали, только все базы которые я писал себе и др. людям сдающим дипломы не требовали чтобы там были какие либо ограничения (преподы и так понимали - они хоть что нить сдали бы =)), а даже если у кого из моих знакомых и требовались, то на это всегда был один ответ: "ну это типа учебная разработка, времени мало, но вот когда я буду писать настоящую ..."
А поскольку в моем скромном городишке программеры/разработчики не требуются, то я пошел где было место, а именно в банк аудитором, благо в дипломе написано квалификация экономист (ну государство умеет издеватся таким способом), ну и соответственно никакими разработками на работе не занимался около 2-х лет, все писалось и пишется дома в свободное от работы время - типа хоби. И все написанное для работы используется в тихоря, потому как запрещено это все.
Но вот на работе есть направление которое так и напрашивает на разработку и уж коли братся за него, то сделать все нормально, глядишь начальство и оценит, а раз делать нормально то нужно вот это самое разграничение. На работе есть серьезная базка, я видел с десяток раз ее админский модуль, там конечно чего тока нет, видел как админ права (у меня на работе это никак по другому не называется :-)) раздает и т.д. Покапатся в нем мне ессенно не дают, поэтому вникнуть чего там у меня не получилось. Вот и решил узнать тут.
> > отсюда можно сделать один вывод если у меня будет 50 операций,
>
> > то мне понадобится 50 кнопочек, если порядка 500 как
> в
> > той БД которую я видел, значит нужно 500 =)
>
> Неправильный вывод. Завести 10 пользователей - это одна
> или 10 операций? Операций-то 10, но они однотипные и здесь
> достаточно одной кнопки. Ввести роль - еще кнопка. Дать
> полномочия на роль пользователю - еще одна кнопка. И дать
> полномочия роли или пользователю на выполнение хранимой
> процедуры, просмотр вьюхи и т.п. еще одна кнопка. Итого
> 4 кнопки! Реально, конечно, потребуется еще чего-нибудь,
> но я не думаю, что ты выйдешь за границы полутора-двух
> десятков кнопок, но это же не 500! И никаких переделок админмодуля.
>
> Естественно в качестве кнопок может выступать кто угодно
> (кнопки, таблицы, списки и пр.)
Вывод как раз правильный =), я не сказал про пользователей, а про операции типа:
- оборотная ведомость
- выписка из лицевого счета
- оборотно-сальдовая ведомость
- оборотно-сальдовая ведомость с разбивкой по периодам
- и т.д. 50 штук
Мне предлагали для каждой такой операции сделать кнопочку
> > мне прийдется написать администратору шпору с SQLем, типа
> напишешь эту команду и пользователь сможет выполнять
> > такие операции...
>
> не придется, если ты эти sql команды "подвесиш" на кнопочки,
> либо на > "нужных описаниях (типа "Проводка материальных
> счетов")"
> Sergey13 © (13.12.05 16:35) [17]
Ну я то хочу сочитать оба пункта, а вот как получится на самом деле =)
> Anatoly Podgoretsky © (13.12.05 16:38) [18]
> Учитывая заявленый зоопарк (IB6.x, MSSQL, MySQL, dBase,
> FoxPro, Paradox), про штатные средства, да и вообще можно
> забыть.
> Надо снизить аппетиты и определиться с минимумом.
> Последнии тру СУБД практически беззащитны.
Написано все это было для того, чтобы найти нужную СУБД, т.е. м.б. некоторый чел написал бы бери MSSQL там все это делается 2-мя командами =)
Пока мне фсе равно какая СУБД.
С самого начало было интересно кто, как и где хранит эти самые права пользователей, ну т.е. делает ли дополнительные таблицы в БД или наборы как в [4] или еще что-то.
Кстати никто так и не высказал своих соображений по поводу второго абзаца исходного вопроса - это кто нить как нить реализовывал?
evvcom (2005-12-14 11:39:00) [4]А ну если только для тех 3-х... А для остальных это лишнее, так как можно ограничить права пользователей с шаловливыми ручками штатными средствами.
Desdechado (2005-12-14 11:17:00) [5]чтоб особо продвинутые юзвери ручками (сторонними средствами) не лезли, особенно актуально для тех 3 СУБД, что АП упомянул
evvcom (2005-12-14 08:53:00) [6]
> складываешь в зашифрованном виде в БД
а шифровать-то зачем?
Desdechado (2005-12-13 18:59:00) [7]имхо, разделение прав эффективно на уровне операций (пункты меню, кнопки и т.п.) в программах + на уровне метаобъектов БД (таблицы, вьюхи и т.п.)
как это свести в одной админской программе - тут простор фантазии
список пользователей у тебя есть, назначь им роли (уровень метаобъектов) и обеспечь в админмодуле опознавание новых защищенных элементов интерфейса программ и разделение прав по ним для групп пользователей (не ролей).
включаешь пользователя в одну или несколько групп, при этом автоматом или вручную назначаешь роли, все это добро складываешь в зашифрованном виде в БД
пользователь подключается к БД, сразу же в программе при старте считываются права на интерфейсные элементы и поехали...
Anatoly Podgoretsky (2005-12-13 16:38:00) [8]Учитывая заявленый зоопарк (IB6.x, MSSQL, MySQL, dBase, FoxPro, Paradox), про штатные средства, да и вообще можно забыть.
Надо снизить аппетиты и определиться с минимумом.
Последнии тру СУБД практически беззащитны.
Sergey13 (2005-12-13 16:35:00) [9]2[13] _Lucky_ (13.12.05 15:47)
Тебе надо таки определиться - как ты хочешь сделать.
1. Давать право юзеру выполнять некую функцию (например "Формирование балансового отчета") - это значит, фактически что должны быть таблицы с юзерами и этими функциями системы и их пересечение (т.е. кто что может). Читая эти таблицы ты можешь динамически строить интерфейс. Все юзера при этом или будут обладать в БД всеми правами или для каждой функции системы еще надо будет прописывать права на объекты БД. Это геморойно.
2. Дать права на объекты БД ролям (однотипным группам юзеров). Тогда человек сможет читать (например) таблицу счетов независимо от того в какой функции системы он это делает. Или не сможет писать туда, независимо от того, что ему доступен пункт меню "Перелопатить план счетов". БД ему этого не даст.
Можно сочетать эти 2 варианта по разному.
Как только определишься что тебе надо, так будет понятнее (надеюсь) как это сделать.
evvcom (2005-12-13 16:26:00) [10]
> назови это по другому, не тип юзера, а группа предустановленных
> прав юзера
это принято называть ролью, поэтому лучше так и называть, будет понятно всем.
evvcom (2005-12-13 16:23:00) [11]
> отсюда можно сделать один вывод если у меня будет 50 операций,
> то мне понадобится 50 кнопочек, если порядка 500 как в
> той БД которую я видел, значит нужно 500 =)
Неправильный вывод. Завести 10 пользователей - это одна или 10 операций? Операций-то 10, но они однотипные и здесь достаточно одной кнопки. Ввести роль - еще кнопка. Дать полномочия на роль пользователю - еще одна кнопка. И дать полномочия роли или пользователю на выполнение хранимой процедуры, просмотр вьюхи и т.п. еще одна кнопка. Итого 4 кнопки! Реально, конечно, потребуется еще чего-нибудь, но я не думаю, что ты выйдешь за границы полутора-двух десятков кнопок, но это же не 500! И никаких переделок админмодуля.
Естественно в качестве кнопок может выступать кто угодно (кнопки, таблицы, списки и пр.)
sniknik (2005-12-13 16:12:00) [12]> тоже не скажу, что вы понимаете все элементарные вещи.
я этого и не утверждал... элементарные вещи того же бугалтера, их счета проводки, для меня "темный лес" приходится каждый раз разбираться как сталкиваюсь. они же похоже ими думают...
(не понимаю и не комплексую по этому поводу. каждый занимается своим делом)
> Я лично хочу чтобы было нечно вроде
> ДатьПраваПользователю (Юзерь, ИД_Райтз)
> и все
примерно то самое у меня и есть ([4] последний абзац) только названо по другому, у меня даются права типу (админ, менеджер, пользователь) а юзеру задается уже этот тип и соответственно его права.
назови это по другому, не тип юзера, а группа предустановленных прав юзера, и не храни в одном месте как у меня (т.к. у меня жесто задано) а копируй в запись юзера (или храни у юзера ссылки на эти группы прав), и будет практически то что ты хочеш.
_Lucky_ (2005-12-13 15:47:00) [13]
> Я что-то понимаю все меньше и меньше в твоем вопросе. 8-
> )
> Кто писал прогу для юзеров (не админскую)? Как там реализованы
> эти самые права доступа которые надо администрировать? О
> какой вообще БД идет конкретно речь?
Очень жаль, что не понятно.
Прогу никто еще не писал, просто все написанные мною до этого программы, не требовали никакого разграничения, но вот щас мне это стало необходимо, в нескольких коммерческих программах я увидел это и мне стало интересно как у них это реализованно.
СУБД любая, т.е. реально я писал на IB/FB, но если например на FB такое реализовать не возможно или скажем на MS SQL это делается штатными средствами, то значит будуучить новую для меня СУБД.
> по моему ктото когото не понимает...
> никто тебе ни предлагал кнопочку для каждого юзера предзаведенного,
> и каждой операции каждого юзера. предлагали повесить на
> кнопочку команду для установки определенного "права" текущему
> (или любому другому логически выбранному в твоей програме
> (например свежесозданному)), меняеш текущего/логически выбранного
> юзера и кнопочка действенно уже для него...
> (вернее не предлагалось и это, а подразумевалось. а как
> реализовать это не регламентируется. иидивидуально)
Ну видимо так и есть, только вот чего Вы мне предлагали:
> не придется, если ты эти sql команды "подвесиш" на кнопочки,
> либо на > "нужных описаниях (типа "Проводка материальных
> счетов")"
отсюда можно сделать один вывод если у меня будет 50 операций, то мне понадобится 50 кнопочек, если порядка 500 как в той БД которую я видел, значит нужно 500 =)
Да на самом деле это меня интересовало меньше всего, кнопочки там делать или списки или еще какой контрол повесить, интересно было другое как все это автоматизировать, а точнее как это делают другие, чтобы при появлении десятка новых операций не пришлось исправлять исходники админа, чтобы админская прога сама знала какие права ваще можно давать в системе.
> извини но не похоже. мышление не то, елементарные вещи воспринимаеш
> как, как... как менеджер (или даже хуже - бухгалтер!). ;
> о)
Не извиню, это просто хамство. Если я чего-то не знаю, то это еще не означает что я плохой программист - это первое.
Второе если кто там считает, что не похоже, то это также не делает меня хуже.
Ну и на конец последнее - тоже не скажу, что вы понимаете все элементарные вещи. Я лично не спрашивал какие кнопки или спики мне делать и что на них вещать.
Чтобы не огорчать в прогнозах - в действительности я работаю и бухгалтером и менеджером и администратором - аудитор я, хотя учился именно на программера информационных систем, программирование у меня как хоби.
> Вот именно! Напиши функцию, может даже не одну :)
> А еще поищи/почитай про динамический sql
Да ну понятное дело, напишу я функцию, мне же инетесно куда запихнуть все эти права, ну т.е. например создать еще одну табличку в БД и при появлении новых прав писать их туда, а вот уже когда дойдет дело, до админа то ему вывалится список из этой табличек, он выбирет чего давать и нажмет на кнопочку или еще на что-то и вот тогда в функцию подставятся параметы. не писать же мне:
ДатьПраваПользователю (Юзерь, "Проводка счетов")
ДатьПраваПользователю (Юзерь, "Формирование балансового отчета")
ДатьПраваПользователю (Юзерь, "Формирование сальдовой ведомости")
Я лично хочу чтобы было нечно вроде
ДатьПраваПользователю (Юзерь, ИД_Райтз)
и все
> По человечески надо комбинировать и таблицы и штатные средства.
> Правда, можно использовать сервер приложений и штатные
> средства могут оказаться уже не нужны. Прежде чем писать
> АРМ админа, нужно написать саму систему. А уже от ее технологии
> плясать.
> ЗЫ. Частенько не пишут отдельный АРМ админа, а встраивают
> этот функционал прямо в приложение.
> ЗЫЫ. Писать ты это все задерешься, так как SQL, видимо,
> знаешь плохо.
Вот то-то и оно, что хочется узнать как это по человечески, я же не могу знать о бо всем, поэтому и спросил тут. Т.е. например ну не работал я с MS SQL - а м.б. он все это умеет делать штатными средствами, а я буду изобретать велосипед. С другой стороны для решения задача мне хватит и FB, поэтому не вижу причин переходить на что-то другое, тем более, если другая СУБД не решает моей проблемы.
К сожалению точно не знаю чего писать с начала. Но я лично решил написать сначала админа, потому что задача не сложная, в том что с ней справлюсь уверен, а вот админа никогда не делал. При этом не вижу проблем с технологией, тем более что она как-то мне может все испорить (могу сильно ошибатся =)).
Я в курсе что арм админа встраивают прямо в приложение, но из соображений безопасности у нас все разделено.
SQL знаю не так хорошо как хотелось бы, но мне хватает =)
ЗюЫю спасибо за статью.
ANB (2005-12-12 17:41:00) [14]
> _Lucky_ (07.12.05 13:51)
По человечески надо комбинировать и таблицы и штатные средства. Правда, можно использовать сервер приложений и штатные средства могут оказаться уже не нужны. Прежде чем писать АРМ админа, нужно написать саму систему. А уже от ее технологии плясать.
ЗЫ. Частенько не пишут отдельный АРМ админа, а встраивают этот функционал прямо в приложение.
ЗЫЫ. Писать ты это все задерешься, так как SQL, видимо, знаешь плохо.
iva (2005-12-12 15:01:00) [15]На http://www.delphiplus.org/есть статья 'Управление пользователями в ПО на основе СУБД Interbase'
evvcom (2005-12-12 14:41:00) [16]
> мысль о том, что м.б. где-то в оракле или мс сиквеле это
> реализованно на уровне самой субд.
Действительно реализовано путем выполнения sql "create user ...", "create role ...", "grant ..." и т.п.
> так зачем же я буду делать 50 кнопочек и каждый раз лезть
> в исходники и делать новую кнопочку, когда можно взять написать
> функцию предоставления прав, а при появлении новых полномочий
> включать их в список (добавлять в таблицу).
Вот именно! Напиши функцию, может даже не одну :)
А еще поищи/почитай про динамический sql
sniknik (2005-12-12 14:00:00) [17]по моему ктото когото не понимает...
никто тебе ни предлагал кнопочку для каждого юзера предзаведенного, и каждой операции каждого юзера. предлагали повесить на кнопочку команду для установки определенного "права" текущему (или любому другому логически выбранному в твоей програме (например свежесозданному)), меняеш текущего/логически выбранного юзера и кнопочка действенно уже для него...
(вернее не предлагалось и это, а подразумевалось. а как реализовать это не регламентируется. иидивидуально)
> Ну собсна я и есть программист =)
извини но не похоже. мышление не то, елементарные вещи воспринимаеш как, как... как менеджер (или даже хуже - бухгалтер!). ;о)
Sergey13 (2005-12-12 13:46:00) [18]2 [7] _Lucky_ (12.12.05 13:36)
Я что-то понимаю все меньше и меньше в твоем вопросе. 8-)
Кто писал прогу для юзеров (не админскую)? Как там реализованы эти самые права доступа которые надо администрировать? О какой вообще БД идет конкретно речь?
_Lucky_ (2005-12-12 13:36:00) [19]
> Sergey13 © (12.12.05 09:26) [6]
Ну собсна я и есть программист =)
Хотя работаю не программистом, и приглашать его туда никто не будет, это ваще самодеятельность, так сказать перед начальством вы...ся - глядишь чего и получитсо.
По поводу SQL и кнопочек - в юзерской программе тоже достаточно функций, но ведь подумай сам в админской проге предпологается наличие таких функций как добавление нового пользователя, предоставление/изъятие прав, блокирование/разблокирование, сброс пароля, по идее все, ну м.б. чего забыл, не в этом суть, так вот предоставление прав мне что прийдется менять (или писать новую) каждый раз как появится новая функция? фигня.
ведь я не думаю что кто-то, пуская в юзерской программе, делает отчет например условно для счета 42301, а потом когда в балансе появляется счет 70107, то еще дописывает отчет для этого счета, хотя отчеты на самом деле одинаковые, и так каждый раз при появлении нового счете, наверняка делается одна функция отчета, у которой есть параметр номер счета - допустим, который в свою очередь хранится в одной из таблиц, так зачем же я буду делать 50 кнопочек и каждый раз лезть в исходники и делать новую кнопочку, когда можно взять написать функцию предоставления прав, а при появлении новых полномочий включать их в список (добавлять в таблицу).
Sergey13 (2005-12-12 09:26:00) [20]2 [5] _Lucky_ (11.12.05 13:35)
> Ну это совсем не интересно, потому что допустим у меня порядка 50 операций, делать 50 кнопочек - это не совсем красиво, да и если нужно будет сделать какие-то изменения, то тоже получится напряжно.
Интересно, а в юзерской программе (не админовской), у тебя 1~2 функции и ты обходишься без SQL?
ИМХО вам надо программиста приглашать для этой работы.
| |
Страницы: 