Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Права пользователей в программе [D7, dBase, FoxPro, Paradox]

Страницы: < 1 2 3 >
jiny © (2006-08-04 11:57:00)
я создал программу складского учета, которая уже успешно применяется 1 год в одной организации, при этом права пользователей не учел, это большой минус, но тогда все создавалось быстро и некогда было думать о разграничении прав в программе.
Возникла проблема, из-за кривых и пытливых ручек пользователей, а именно : они лезут в журналы, в которые им не нужно открывать, изменяют цены на позиции, которые не в их компетенции и вообще открывают формы которые относятся к компетенции других отделов.
Вопрос следующий :
Какие существую алгоритмы/методы разграничения прав, как в 1С, например, где можно вплоть до каждой формы пользователю разрешить, либо запретить.
На уровне базы данных сделать можно, но только в FireBird, но сама программа крутится под Paradox, даже если доступ распределен на уровне базы данных, то программа все равно даст юзеру открыть определенную форму, где доступ к базе запрещен и это, я считаю немного неправильным. Как сделать так, чтобы данные о правах на определенные объекты (формы, эдиты, кнопки и т.д.) хранились в определенной таблице и как это вообще делается ? Это перед открытием каждой формы мне нужно сверяться с таблицей ролей и разрешений, есть ли разрешение у данной роли открывать эту форму или нет ?

Я представляю себе схему так :
1) создаю роли ;
2) задаю права на роли ;
3) создаю пользователей, где присваиваю им соответствующие роли ;
Каким образом это делается, пока не педставляю, долго искал в интернете примеры подобного, но так и не нашел ничего стоящего, надеюсь вы дадите мне советы, в каком направлении работать. Если будут ссылки - тоже буду признателен

jiny (2006-08-08 14:26:00) [21]
Прошу прощения был в отъезде, но кое что в дороге успел сделать.
Работы по переводу на FireBird велись мной уже давно,
пробные перебросы делались и нарабатывалась логика на серваке,
вчера окончательно перевел всю программу на FireBird, но не решило всех задач. Создал роли, установил разрешения, привязал пользователей к ролям, но даже если какой-нить юзер попытается лазить в какой-нить журнал документов, СБД ему, конечно, запрет ставит, но сам тот факт, что ссылка на форму журнала дает ему программа меня коробит, так что, все-так без бизнес логики приложения не обойтись (настройка меню и доступ к формам).

> Neo Trinitron © (07.08.06 13:25) [30]
> jiny, имхо проще пересесть на нормальную СУБД. Преимущества
> - все. Недостатков - нет. OracleXE - бесплатна! За чем остановка?
>
>
Насчет этого с тобой полностью согласен, но дело в том что я не особенно знаком с Oracle, поэтому боюсь навредить, с FireBird - попроще, в том смысле, что я его уже знаю.
Уроки по Oracle скачал, но пока все некогда засесть за изучение.

ANB (2006-08-07 14:49:00) [22]

> Бардак на складе не лечится ролями.

Но ими он хотя бы частично предотвращается. А если система вообще не имеет защиты - то это приглашение к ее ломанию.

Dok (2006-08-07 14:26:00) [23]

> Речь шла о правах на бизнес-операции (читай: программы,
> режимы, кнопки). Для этого достаточно одной таблицы.

действительно, мы говорили просто о разных весчах.

> А для таблиц в БД не нужно ничего городить дополнительно
> для раздачи прав на чтение/запись. Это уже есть все в штатных
> механизмах СУБД, в ее системных таблицах.
>

это смотря как реализованны пользователи.

MsGuns (2006-08-07 13:56:00) [24]
>они лезут в журналы, в которые им не нужно открывать, изменяют цены на позиции, которые не в их компетенции и вообще открывают формы которые относятся к компетенции других отделов

Бардак на складе не лечится ролями.
Никакой уракакл на сможет по отпечаткам пальцев на клавиатуре опознать воришку Васю, сбондившего ящик чипсов и срочно "залевшего в журнал" для правки остатка, в то время как завскладом вышел на минутку покурить.

"Разруха - она в головах" (с)

Neo Trinitron (2006-08-07 13:52:00) [25]
>Иногда встречается такая редкая форма насилия - требование заказчика.

Тогда заказчик должен согласиться с тем что безопастность будет охранять базу от деток, но уж никак не от юзеров с шаловливыми ручками, и не морочить светлую голову программера! Конечно и мне хотелось бы из москвича бумер сделать, однако, проще купить тот самый бумер. Однажды я работал юзверем. Была очень хитрая система (dbf) с массой ловушек и всяких причандалов типо безопасность :) За два дня работы я понял что и где там нужно поменять чтобы мне было хорошо :) Именно тогда я понял что никогда не буду делать программу основаную на dbf. Проще отказаться от проэкта чем заниматься такой хренью. Вот у меня заказчики тоже хотели dbf, мол это формат который они знают. Я ответил что это не ко мне, предложил MS Access, обьяснил - согласились, ещё и спасибо сказали. А если бы не согласились, что других заказчиков нет?

Desdechado (2006-08-07 13:43:00) [26]
Neo Trinitron © (07.08.06 13:25) [30]
Иногда встречается такая редкая форма насилия - требование заказчика.

Neo Trinitron (2006-08-07 13:25:00) [27]
jiny, имхо проще пересесть на нормальную СУБД. Преимущества - все. Недостатков - нет. OracleXE - бесплатна! За чем остановка? Велосипед уже давно изобретён и модифицирован до уровня сверхзвукового гоночного агрегата с турбоподдувом! Я бы стопудуво перевёл базу, ну, хотябы на MS Access, это на самый худой случай. А так OracleXE - куколка! И чего только пользователям надо? Бесплатная, а всё равно впадлу брать...

Desdechado (2006-08-07 12:23:00) [28]
Dok (07.08.06 12:07) [28]
Ты откуда такое выдумал?!

Речь шла о правах на бизнес-операции (читай: программы, режимы, кнопки). Для этого достаточно одной таблицы.
А для таблиц в БД не нужно ничего городить дополнительно для раздачи прав на чтение/запись. Это уже есть все в штатных механизмах СУБД, в ее системных таблицах.

Dok (2006-08-07 12:07:00) [29]
Для каждой таблицы которая будет администрироваться создавать еще одну - права.

Desdechado (2006-08-07 11:26:00) [30]
> и не в какой-нибудь таблице БД - а таких таблиц сколько,
> сколько таблиц предлагается администрировать.
А по-русски? А то не вник в поток сознания...

Dok (2006-08-05 14:40:00) [31]

> ИМХО, что на FireBird, что Oracle, а также в MSSQL принцип
> раздачи прав примерно одинаков

глубоко заблуждаешся. читай мануал по каждой СУБД. FireBird сильно проигрывает. MS SQL проигрывает Oracle.

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

скроее наоборот. дополнять должна программа(клиент) а не база данных.
и не в какой-нибудь таблице БД - а таких таблиц сколько, сколько таблиц предлагается администрировать.

jiny (2006-08-05 13:14:00) [32]
Ошибочка вышла, прошу прощения :

> В принципе я мог бы решить все на уровне БД, определенная
> часть бизнес-логики уже выполняется на сервере, с распределением
> прав для юзеров и ролей ПРОБЛЕМнет.

jiny (2006-08-05 13:12:00) [33]
В принципе я мог бы решить все на уровне БД, определенная часть бизнес-логики уже выполняется на сервере, с распределением прав для юзеров и ролей нет. ИМХО, что на FireBird, что Oracle, а также в MSSQL принцип раздачи прав примерно одинаков, где то больше дополнительных возможностей, где то меньше (если не вдаваться в подробности), но это никак не сказывается на интерфейсной части программы, и как сказал

> Desdechado © (04.08.06 12:19) [5]
> Разграничение прав на уровне данных и операций бизнес-логики
> вполне хорошо взаимодополняют друг друга.

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

ANB (2006-08-04 18:04:00) [34]

> Jeer © (04.08.06 16:17) [22]

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

Например : "право на разрешение подчиненному отдать товар в долг покупателю, который не полностью расчитался за предыдущие поставки".

Правда к их минусу вся эта защита на клиенте была реализована, посему продвинутые продавцы старательно лазили в оракл напрямую.

Jeer (2006-08-04 16:17:00) [35]
Некоторое время я активно использовал DBISAM от elavatesoftware.com, т.к. был дистрибьютором и, вероятно, единственным в России.

Хорошая файл-серверная СУБД, все в одном exe, затем она развилась в C/S и развивается дальше.

Для разграничения прав пользователей была разработана соответствующая подсистема, доступ к которой имел администратор конкретной инсталляции.
Права сводились к ролям, в пределах которых назначались права (доступность) на пункты главного меню, права на конкретную форму и права на операции на данной форме, права на backup и restore, права на аудит.
Этого вполне хватило для устойчивой работы подобных приложений на многие годы.

Пример:
Для операций на форме (типовой) доступны разграничения прав:
- view;
- edit;
- append;
- delete;
- print;
- export;
- import;

Dok (2006-08-04 15:56:00) [36]

> Прочти другую диагональ, а?

пропроще будь, ок?

ANB (2006-08-04 15:52:00) [37]
Автору - совет из опыта :
достаточно удобно строить список элементарных прав а к нему дерево ролей.
Но потом это дерево довольно медленно раскручивается и при постоянном к нему обращении вызывает тормоза.
В одном знакомом проекте вопрос решили просто - при коннекте к БД достаются права пользователя (раскрутка дерева ролей и прав), а потом это все складывается в плоскую временную таблицу уровня сессии. И уже в нее постоянно лазить. Получается удобно и шустро.

Desdechado (2006-08-04 15:45:00) [38]
> Данными надо оперировать а не формами.
И снова здесь диагональный читатель. Прочти другую диагональ, а?
Начни с [5].

ANB (2006-08-04 15:45:00) [39]

> jiny (04.08.06 12:15) [4]

1. Oracle XE бесплатный. совсем.
2. Используя хранимую логику (пакеты), можно настроить гибкую систему доступа, используя любимые вами роли как в 1С :)

jiny (2006-08-04 15:09:00) [40]
>>Sergey13 © (04.08.06 14:27) [15]
Думаю ты прав, контролы это лишнее, хотя на их признак enabled или visible можно отметку поставить при проверке открытия формы.

>>Dok (04.08.06 14:30) [16]
>>200 обьектов - записи или таблицы?
200 записей
Дальнейшую с тобой перепалку и остро-слово-метание вижу бессмысленными...

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »