Права пользователей в программе

← →
jiny (2006-08-04 11:57) [0]

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

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

← →
ANB © (2006-08-04 11:59) [1]

Разграничение доступа на уровне клиента - вчерашний век. Пытливые пользователи тогда будут лазить в базу и править прямо там.
Совет - срочно переводи систему на Оракл XE, тогда сможешь защитить все на уровне БД. Способов для этого там - целая куча.

← →
Johnmen © (2006-08-04 12:02) [2]

> срочно переводи систему на Оракл XE

Хм... Это единственный вариант?

← →
ANB © (2006-08-04 12:04) [3]

> Johnmen © (04.08.06 12:02) [2]

Нет, конечно, но мне он больше всего нравится :)

← →
jiny (2006-08-04 12:15) [4]

Допустим я перевожу базу не на ОРАКЛ, т.к. это сильно круто для организации, где всего 100 документов в день вноситься, да и лицензии не дешевые, а на FireBird. Представьте, что мой вопрос не касается db а уже FDB, как мне запретить доступ к конкретным формам, кнопкам на формах, закладкам пейджконтролов приложения, уже на уровне таблицы БД FireBird.
>>ANB © (04.08.06 11:59) [1]
>>Разграничение доступа на уровне клиента - вчерашний век. Пытливые
>>пользователи тогда будут лазить в базу и править прямо там.
Если я им дам роль(на уровне FireBird), которая будет видеть роли и права только на уровне select, то не будут.
Да и все-таки мне нравится разграничение ролей в 1С, хотелось бы освоить этот метод, даже для себя.

← →
Desdechado © (2006-08-04 12:19) [5]

Разграничение прав на уровне данных и операций бизнес-логики вполне хорошо взаимодополняют друг друга. Поэтому заявлеие [1], имхо, несколько безапелляцоинно звучит. Если даже вся бизнес-логика на сервере, то даже в этом случае залезть в какой-то режим и не иметь возможности в нем что-то сделать несколько странно смотрится. Лучше уж совсем туда не пускать.

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

← →
Dok (2006-08-04 12:26) [6]

Да уж... Парава , права и еще раз права....
Отказаться от Парадокса и ему подобных...
Выбрать FireBird, MS SQL, Oracle - любую, слава богу есть бесплатные варианты.
Создать вьюхи, дать нужные права на них и спать спокойно + реализовать проверку на клиенте.

← →
Petr V. Abramov © (2006-08-04 12:42) [7]

А аксесс перелить, там хоть как-то с правами разрулено.

← →
Sergey13 © (2006-08-04 13:05) [8]

> [4] jiny (04.08.06 12:15)
> как мне запретить доступ
> к конкретным формам, кнопкам на формах, закладкам пейджконтролов
> приложения, уже на уровне таблицы БД FireBird.
Например, можно перед визуализацией формы открывать основной запрос, в ней отображаемый. При неимении прав на какую либо таблицу запрос обломится. Надо поймать этот облом и культурно послать юзера в сад.

← →
jiny (2006-08-04 13:51) [9]

>>Dok (04.08.06 12:26) [6]
>>Да уж... Парава , права и еще раз права....
>>Отказаться от Парадокса и ему подобных...
>>Выбрать FireBird, MS SQL, Oracle - любую, слава богу есть бесплатные
>>варианты.
>>Создать вьюхи, дать нужные права на них и спать спокойно + реализовать
>>проверку на клиенте.
Уж извините, пожалуйста за резкость, но это и ежу понятно, что надо, и это надо уже делается !

Desdechado © (04.08.06 12:19) [5]
Спасибо, мне тоже так кажется. Я в одной налоговой программе видел как разграничены права на объекты. Сервак там MS SQL, права на объекты, прописаны в таблице прав для ролей и каждый раз когда пользователь пытается сделать что-то не то, его обламывают, а в другой интерфейс пользователя формируется на основе этих же прав и не то что не дает ему обломится , а вообще не показывает того чего не следует, это же самое реализовано в 1С Конфигураторе.

>>Sergey13 © (04.08.06 13:05) [8]

> Например, можно перед визуализацией формы открывать основной
> запрос, в ней отображаемый. При неимении прав на какую либо
> таблицу запрос обломится. Надо поймать этот облом и культурно
> послать юзера в сад.

В принципе согласен, но как узнать, что форма FrmSomeForm использует таблицу tovar, а может она использует таблицу buh_docs_plat
я так думаю, что нужно создать в таблице структуру типа :
modul;FormName;TableName;CanSelect;CanModify
а есть вообще примеры подобного, может какие то наработки, я все приму с благодарностью !

← →
Sergey13 © (2006-08-04 13:59) [10]

> я так думаю, что нужно создать в таблице структуру типа
> modul;FormName;TableName;CanSelect;CanModify

Можно и по этому пути пойти. Только структура, ИМХО, должна быть
Юзер (или роль)
Форма
Тип доступа (чтение/изменение)

Плюс (вернее минус) - при таком подходе нужен администратор этого программного комплекса и инструмент для его работы.

← →
Dok (2006-08-04 14:12) [11]

> Уж извините, пожалуйста за резкость, но это и ежу понятно,
> что надо, и это надо уже делается !

Извини за резкость, тогда какого ты тут все долбаешь?

> modul;FormName;TableName;CanSelect;CanModify

RecordID, UserID, GroupID, CanRead, CanWrite, CanDelete, CanGrant

← →
jiny (2006-08-04 14:14) [12]

Я правильно понял ? хочу просто уточнить,
создаю таблицы:
1 PermissionsType, где указаны все объекты к разрешению
вот здесь ступор: только формы и контролы на форме указывать ? ну что-то типа :
Форма; Контрол (если есть необходимость)
2 Roles, роли ;

3 FinalPermissions, подчиненная к Roles таблица, где указывается
роль и разрешение на конкретный объект, в итоге имеем список разрешений к конкретной роли
что-то типа :

Роль
Форма
Контрол (если есть необходимость)
Тип доступа (два поля, т.к. можно запретить пользователю вообще открывать Форму/таблицу)
4 Users, где есть поле принадлежности к той или иной роли

> Плюс (вернее минус) - при таком подходе нужен администратор
> этого
> программного комплекса и инструмент для его работы.

А насчет этого я не буду переживать , потому как все нас не убивает, делает нас сильнее (кажись так)
Администратор есть, только надо сделать инструмент

← →
Dok (2006-08-04 14:18) [13]

> 1 PermissionsType, где указаны все объекты к разрешению
> вот здесь ступор: только формы и контролы на форме указывать
> ? ну что-то типа :
>
> Форма;
> Контрол (если есть необходимость)

бред. Данными надо оперировать а не формами. от данных надо отталкиваться, если на поле нет доступа , то или контрол дизейблить или крывать.

> 2 Roles, роли ;

роли должны бить такими же пользователями.

> 3 FinalPermissions, подчиненная к Roles таблица, где указывается
> роль и разрешение на конкретный объект, в итоге имеем список
> разрешений к конкретной роли

забудь о скорости

← →
jiny (2006-08-04 14:27) [14]

>>Dok (04.08.06 14:18) [13]
ты парень как то агрессивно настроен, никто тебе и не сказал что это постулат, которого надо придерживаться, это всего лишь догма, мое предположение, а насчет скорости, не думаю что из за 200 объектов доли секунд будут иметь большое значение, у меня остатки на товары из 6 логич.журналов формируются за доли секунды, причем товаров за одну выборку около 30, ну даже если это и так, буду искать оптимальный вариант. А высказываться типа :

> Да уж... Парава , права и еще раз права....
> Отказаться от Парадокса и ему подобных...
> Выбрать FireBird, MS SQL, Oracle - любую, слава богу есть
> бесплатные варианты.
> Создать вьюхи, дать нужные права на них и спать спокойно
> + реализовать проверку на клиенте.

Это не есть бред ? Когда у тебя просят совета, можешь - советуй, не можешь не советуй, а риторикой и я богат. Извини за прямоту.

← →
Sergey13 © (2006-08-04 14:27) [15]

> [12] jiny (04.08.06 14:14)

Я так думаю, что каждый контрол прописывать - лишнее. Он или есть или его нет - зависит от типа доступа читатель/писатель.

← →
Dok (2006-08-04 14:30) [16]

> не думаю что из за 200 объектов доли секунд будут иметь
> большое значение, у меня остатки на товары из 6 логич.журналов
> формируются за доли секунды, причем товаров за одну выборку
> около 30,

200 обьектов - записи или таблицы?
Ты не думай, ты возми сделай тесты: селект с условием где 3 ора (с подселектами) или селект с одним условием на миллионе записей.

> Это не есть бред ? Когда у тебя просят совета, можешь -
> советуй, не можешь не советуй, а риторикой и я богат. Извини
> за прямоту.

А можно уточнить - что Ваше Величество посчитало бредом?

← →
jiny (2006-08-04 15:09) [17]

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

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

← →
ANB © (2006-08-04 15:45) [18]

> jiny (04.08.06 12:15) [4]

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

← →
Desdechado © (2006-08-04 15:45) [19]

> Данными надо оперировать а не формами.
И снова здесь диагональный читатель. Прочти другую диагональ, а?
Начни с [5].

← →
ANB © (2006-08-04 15:52) [20]

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

← →
Dok (2006-08-04 15:56) [21]

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

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

← →
Jeer © (2006-08-04 16:17) [22]

Некоторое время я активно использовал DBISAM от elavatesoftware.com, т.к. был дистрибьютором и, вероятно, единственным в России.

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

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

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

← →
ANB © (2006-08-04 18:04) [23]

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

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

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

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

← →
jiny (2006-08-05 13:12) [24]

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

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

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

← →
jiny (2006-08-05 13:14) [25]

Ошибочка вышла, прошу прощения :

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

← →
Dok (2006-08-05 14:40) [26]

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

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

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

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

← →
Desdechado © (2006-08-07 11:26) [27]

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

← →
Dok (2006-08-07 12:07) [28]

Для каждой таблицы которая будет администрироваться создавать еще одну - права.

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

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

jiny, имхо проще пересесть на нормальную СУБД. Преимущества - все. Недостатков - нет. OracleXE - бесплатна! За чем остановка? Велосипед уже давно изобретён и модифицирован до уровня сверхзвукового гоночного агрегата с турбоподдувом! Я бы стопудуво перевёл базу, ну, хотябы на MS Access, это на самый худой случай. А так OracleXE - куколка! И чего только пользователям надо? Бесплатная, а всё равно впадлу брать...

>Иногда встречается такая редкая форма насилия - требование заказчика.

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

>они лезут в журналы, в которые им не нужно открывать, изменяют цены на позиции, которые не в их компетенции и вообще открывают формы которые относятся к компетенции других отделов

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

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

← →
Dok (2006-08-07 14:26) [34]

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

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

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

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

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

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

← →
jiny (2006-08-08 14:26) [36]

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

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

> [36] jiny (08.08.06 14:26)

Ничего такого супер-пуперного Оракл в этом плане не даст. И ни один сервак не даст, ИМХО. Не его это дело - менюшки рисовать. Хочешь - сам рисуй это в БД и пиши функционал.

← →
jiny (2006-08-08 14:35) [38]

>>Sergey13 © (08.08.06 14:30) [37]
Вот и я о том же, но многие мне все равно твердят, что переходи на другой СБД, как ты и сказал ничего он не даст нового, вот так никто примерчика и не дал...неужели никто с этим не сталкивался ?!

> [38] jiny (08.08.06 14:35)
> Вот и я о том же, но многие мне все равно твердят, что переходи
> на другой СБД,
Некоторые при всех проблемах, советуют винду переставлять. Всем таким советам следовать - работать некогда будет. 8-)

> вот так никто примерчика и не дал...неужели никто с этим
> не сталкивался ?!
Какой примерчик то? У тебя в [12] jiny (04.08.06 14:14) все нормально "придумано" (с учетом [17] jiny (04.08.06 15:09) ). Вот и твори.

← →
jiny (2006-08-08 14:46) [40]

>>Sergey13 © (08.08.06 14:41) [39]
уговорил, да я то уже начал творить, практически заканчиваю, осталось все обхекты вбить в таб и программе предв. проверку включить,
просто, люблю я на чужие примерчики посмотреть, авось что-нить новое увижу.
Ну ладно, я так думаю сессию можно считать закрытой, но если у кого, есть что сказать по данной теме - всегда буду рад выслушать любые советы,
всем спасибо ! :)

Права пользователей в программе Найти похожие ветки