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

← →
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]

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

← →
Desdechado © (2006-08-07 12:23) [29]

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

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

← →
Neo Trinitron © (2006-08-07 13:25) [30]

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

← →
Desdechado © (2006-08-07 13:43) [31]

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

← →
Neo Trinitron © (2006-08-07 13:52) [32]

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

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

← →
MsGuns © (2006-08-07 13:56) [33]

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

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

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

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

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

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

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

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

← →
ANB © (2006-08-07 14:49) [35]

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

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

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

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

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

← →
Sergey13 © (2006-08-08 14:30) [37]

> [36] jiny (08.08.06 14:26)

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

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

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

← →
Sergey13 © (2006-08-08 14:41) [39]

> [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]
уговорил, да я то уже начал творить, практически заканчиваю, осталось все обхекты вбить в таб и программе предв. проверку включить,
просто, люблю я на чужие примерчики посмотреть, авось что-нить новое увижу.
Ну ладно, я так думаю сессию можно считать закрытой, но если у кого, есть что сказать по данной теме - всегда буду рад выслушать любые советы,
всем спасибо ! :)

> [38] jiny (08.08.06 14:35)

Можно, кстати, еще проще поступить. Проанализировать текущую роль юзера и по результату рисовать менюшки/формочки. Не думаю, что этих ролей будет много для одного exe-шника.

Значит так, доступ на сервере нужно разграничить по максимуму, на клиенте можно извращаться как угодно. Это уже дело фантазии. А если завтра нужно будет клиента переписать, web приложение забецать, например, то все останутся довольны ибо логика не изменилась. Даже если у них откроется форма с данными которые они не могут даже читать, то данные они всё равно не увидят.

← →
jiny (2006-08-08 14:54) [43]

В принципе я по этому пути и пошел, но в голове зудит одна мысль "как же сделать настройку меню как в 1С" - такую же гибкую ! я предполагаю, что пока будет всего 11 ролей :
СуперАдмин
Админ
Директор
Менеджер по закупу
Менеджер по продажам
Менеджер по сертификации
Гл.бухгалтер
Бухгалтер
Кассир
Аналитик
Контролер

← →
jiny (2006-08-08 14:58) [44]

>>Neo Trinitron © (08.08.06 14:50) [42]
Вот насчет этого у меня уже руки чешуться, в принципе Веба тоже нужна на будущее ! (спасибо за мысль), тогда точно на Оракл переходить буду, т.к. говорят что там в плане прав/привилегий ширше можно думать ...:)

> [43] jiny (08.08.06 14:54)

Ну и храни меню в БД - в чем проблема то? Так можно даже, что бы юзера сами себе менюшку рисовали.

ЗЫ: Только лишнее это все ИМХО. Работы добавляет, а функционала нет.

← →
jiny (2006-08-08 15:07) [46]

>>Sergey13 © (08.08.06 14:59) [45]
>>Ну и храни меню в БД - в чем проблема то? Так можно даже, что бы >>
>>юзера сами себе менюшку рисовали.
ты имеешь ввиду в блобе ?
>>ЗЫ: Только лишнее это все ИМХО. Работы добавляет, а функционала нет.
согласен, зато юзеры меньше проблем будут создавать

> [46] jiny (08.08.06 15:07)
> ты имеешь ввиду в блобе ?
Зачем? В иерархической таблице.

> согласен, зато юзеры меньше проблем будут создавать
Думаешь? Я думаю наоборот. Это как с покупкой товара: есть один вид - берешь и идешь в кассу, есть 10 видов одного и того-же - стоишь полчаса и думаешь, что взять. 8-)

← →
jiny (2006-08-08 15:14) [48]

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

Мы подобные наработки пишем уже больше года. Правда, в этом интервале времени не только наработки с правами, но и весь функционал. За это я все время получал неплохую заработную плату. Как ты думаешь, я имею право поделиться с тобой этими наработками?

> [20] ANB © (04.08.06 15:52)

Я при логине открываю хранимку USER_OBJECTS и держу курсор открытым на протяжении всей работы клиента. никаких дополнительных обращений к серверу, разве что при перелогине.

> [22] Jeer © (04.08.06 16:17)
> назначались права (доступность) на пункты главного меню,
> права на конкретную форму и права на операции на данной
> форме

Мы привязываем пункт меню к форме, форму к некоему логическому объекту. Все это, а также пользователи, роли, полномочия (точнее их допустимые значения - select, update, delete, import, export и др.) и многое другое лежит в одной таблице. В другой таблице связей повязаны роли с пользователями и ролями, роли и/или пользователи с объектами и полномочиями. Благо в оракле реализован древовидный select! Запрос получился довольно сложный, но достаточно шустрый (меньше 0,2 сек, причем подозреваю, что в основном это время тратится на fetch строк с сервера).

> [23] ANB © (04.08.06 18:04)
> что в эту схему бы не уложились

Сомневаюсь. Что мешает добавить в систему полномочие РазрешениеОтдатьТоварВДолгПокупателюКоторыйНеПолностьюРасчиталсяЗаПредыдущиеПост авки и привязать его именно к действию на соответствующей форме?

> Правда к их минусу вся эта защита на клиенте была реализована

Меня по началу пытались тоже уговорить, что не фиг сильно заморачиваться с защитой на сервере, достаточно ее реализовать на клиенте. Я понял, что просто разговоры ничего не докажут и ... сделал по-своему. В общем-то недовольства такой реализацией не было. И если и есть какие дыры (а недавно о них ты вроде и говорил), то дыры эти уже не мои, а Оракла :) У меня если и полезут юзера напрямую к Ораклу, то увидят только те хранимые процедуры, которые им дозволено вызывать и из программы, и увидят только те записи, что и из программы. :o)

> [34] Dok (07.08.06 14:26)
> это смотря как реализованны пользователи.

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

> Что мешает добавить в систему полномочие РазрешениеОтдатьТоварВДолгПокупателюКоторыйНеПолностьюРасчиталсяЗаПредыдущиеПост
> авки и привязать его именно к действию на соответствующей
> форме?

Хорошей идеей МВ была сущность "Контрольная точка". Она могла быть в состоянии "Нету", "Есть", "Есть, но под добро начальника", "Возможность давать добро подчиненным". Имея эту инфу можно организовывать сколь угодно сложную логику взаимодействия, в том числе и на уровне хранимок. И опять же по опыту, когда число таких прав накопилось за 5 тысяч и повялось большое количество перекрестных и вложенных привязок, запрос стал немного притормаживать. Никто даже не пытался завязать этот запрос на фильтрацию данных. А в случае плоской временной таблицы - это вполне можно сделать. Кстати, сам оракл в системных вьюхах фильтрует доступ привязкой к правам. А запрос с connect by по линковке особо то не напишешь.

> [50] ANB © (08.08.06 16:12)

connect by я реализовал во вьюхе для определения к какой группе (ветви) относится запись в таблице. То ли это роль, то ли юзер, то ли меню, то ли форма и т.д. А уж далее таблица линков джойнится многократно с этим селектом, pipelined функция пакета выбирает данные и записывает анализируя их в table of TMyType index by binary_integer; и возвращает хитро обработанные строки запросу.
У меня сейчас, правда, еще не 5 тыс. прав (в смысле ролей?), но 1 тыс. записей в структуре объектов и 3,5 тыс. в таблице связей, тоже всевозможные перекрестные связи реализованы, запрос, возвращая сотню связок объект-полномочие, выполняется за 0,2 сек. Меня пока устраивает, хотя первоначальный вариант я уже переделывал с целью оптимизации скорости выполнения.

> evvcom © (08.08.06 16:52) [51]

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

> [52] ANB © (08.08.06 16:56)
> то будет все равно не шустро

Не знаю, может быть. Результат этой функции есть аналог временной таблицы, но без индексов, или полный аналог результата джойна двух реальных таблиц, который естественно уже тоже без индекса. Если джойнить с большой табличкой, то наверняка самым оптимальным окажется HASH JOIN, а ему как известно индексы по барабану, он их не использует.

> если ты сджойнишь большую табличку

А что может быть в этой табличке? У меня сейчас реально джойнится эта функция 4 раза с таблицей-структурой объектов. 1 тыс. записей, конечно, не назовешь большой табличкой, но тем не менее, если количество этих объектов вырастет и до 10 тыс. (что тоже немного, но куда уж больше-то объектов?!), думаю, разницы большой не будет.

> А индексированная времянка - самое оно. Впрочем, я не навязываюсь :)

А нужен он здесь индекс-то? Впрочем, я тоже не спорю :)

← →
jiny (2006-08-09 13:36) [54]

evvcom © (08.08.06 15:26) [49]

> Мы подобные наработки пишем уже больше года. Правда, в этом
> интервале времени не только наработки с правами, но и весь
> функционал. За это я все время получал неплохую заработную
> плату. Как ты думаешь, я имею право поделиться с тобой этими
> наработками?

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

> Мы привязываем пункт меню к форме, форму к некоему логическому
> объекту. Все это, а также пользователи, роли, полномочия
> (точнее их допустимые значения - select, update, delete,
> import, export и др.) и многое другое лежит в одной таблице.
> В другой таблице связей повязаны роли с пользователями
> и ролями, роли и/или пользователи с объектами и полномочиями

можно попросить стуктуру табл., хотя бы на e-mail, на всякий пожарный выкладываю сви структуры, получилось 3 табл.
роли
CREATE TABLE USER_ROLES ( ID INTEGER, ROLE_NAME VARCHAR(20) COLLATE PXW_CYRL, ROLE_DESC VARCHAR(30) COLLATE PXW_CYRL );
доступные объекты в программе
CREATE TABLE USER_PERMISSIONS ( ID INTEGER, NAME_FORM VARCHAR(150) COLLATE PXW_CYRL, DESC_FORM VARCHAR(150) COLLATE PXW_CYRL, NAME_TABLE VARCHAR(150) COLLATE PXW_CYRL, DESC_TABLE VARCHAR(150) COLLATE PXW_CYRL, NAME_CONTROL VARCHAR(150) COLLATE PXW_CYRL, DESC_CONTROL VARCHAR(150) COLLATE PXW_CYRL );

Финальные разрешения для ролей
CREATE TABLE USER_PERMISSIONS_FINAL ( ID INTEGER, ROLE_NAME VARCHAR(20), ID_Object INTEGER, CANOPEN SMALLINT DEFAULT 0, CANSELECT SMALLINT DEFAULT 0, CANINSERT SMALLINT DEFAULT 0, CANUPDATE SMALLINT DEFAULT 0, CANDELETE SMALLINT DEFAULT 0, CANGRANT SMALLINT DEFAULT 0 CANIMPORT SMALLINT DEFAULT 0, CANEXORT SMALLINT DEFAULT 0, CANPRINT SMALLINT DEFAULT 0 );

ну и табл. users, где идет привязка юзеров к ролям
может кто-то хочет дополнить/сократить структуру таблиц ?

ИМХО на форуме вопросов о реализации целой подсистемы не стоит задавать, на то и есть профессия программиста. Форум подходит скорее для помощи в случае если не получается что-то небольшое, такой себе гвоздик который не удаётся вытащить, из-за чего останавливается разработка всего проэкта. Автор, Вам тут советов понадавали на три проэкта. Вам написать подсистему? Легко! Но нужно договориться об оплате. Удачи.

> [54] jiny (09.08.06 13:36)
> и как видится я - вам не конкурент

Фу (облегченно) ... Успокоил. А то уж я весь на измене, а вдруг подсидишь? :)

> можно попросить стуктуру табл.,

Ну к примеру:
create table ADM_STRUCTURE ( PK NUMBER not null, PARENT NUMBER, IDX NUMBER not null, IDENT VARCHAR2(50), ALIAS VARCHAR2(60), LINK NUMBER, ICON VARCHAR2(32), SHORTCUT VARCHAR2(16), NOTES VARCHAR2(100), ID_WORKER NUMBER, ID_FILE NUMBER ); create table ADM_STRUCTURE_LINK ( ID_ADM_STRUCTURE_LINK NUMBER(12) not null, ID_OBJECT NUMBER(12), ID_PERMISSION NUMBER(12), ID_DBOBJECT NUMBER(12), ID_USER NUMBER(12), ID_ROLE NUMBER(12), ID_ROLE_INCLUDED NUMBER(12), ID_FILE NUMBER(12), ID_SEPARATOR NUMBER(12), FLAG_REVOKE NUMBER(1) default 0 not null );
Структура почти вся. Есть дополнительные таблицы для хранения различных файлов, работников (чтобы юзера привязать к ФИО), но это уже к безопасности очень косвенно относится. Только тебе эта структура толком не поможет. Ну не сможешь ты на парадоксе (или кажется ты уже на какую-то "нормальную" СУБД согласился?) раскрутить нормально дерево и реализовать такие сложные запросы. А кода у меня процедур, вьюх и пакетов для обработки такой структуры не на одну страницу будет. И трудозатраты на структуру от силы час, а на отлаженный код уже даже не днями считать надо.

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