| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Права пользователей в программе [D7, dBase, FoxPro, Paradox]
jiny © (2006-08-04 11:57:00)я создал программу складского учета, которая уже успешно применяется 1 год в одной организации, при этом права пользователей не учел, это большой минус, но тогда все создавалось быстро и некогда было думать о разграничении прав в программе.
Возникла проблема, из-за кривых и пытливых ручек пользователей, а именно : они лезут в журналы, в которые им не нужно открывать, изменяют цены на позиции, которые не в их компетенции и вообще открывают формы которые относятся к компетенции других отделов.
Вопрос следующий :
Какие существую алгоритмы/методы разграничения прав, как в 1С, например, где можно вплоть до каждой формы пользователю разрешить, либо запретить.
На уровне базы данных сделать можно, но только в FireBird, но сама программа крутится под Paradox, даже если доступ распределен на уровне базы данных, то программа все равно даст юзеру открыть определенную форму, где доступ к базе запрещен и это, я считаю немного неправильным. Как сделать так, чтобы данные о правах на определенные объекты (формы, эдиты, кнопки и т.д.) хранились в определенной таблице и как это вообще делается ? Это перед открытием каждой формы мне нужно сверяться с таблицей ролей и разрешений, есть ли разрешение у данной роли открывать эту форму или нет ?
Я представляю себе схему так :
1) создаю роли ;
2) задаю права на роли ;
3) создаю пользователей, где присваиваю им соответствующие роли ;
Каким образом это делается, пока не педставляю, долго искал в интернете примеры подобного, но так и не нашел ничего стоящего, надеюсь вы дадите мне советы, в каком направлении работать. Если будут ссылки - тоже буду признателен
Dok (2006-08-04 14:30:00) [41]
> не думаю что из за 200 объектов доли секунд будут иметь
> большое значение, у меня остатки на товары из 6 логич.журналов
> формируются за доли секунды, причем товаров за одну выборку
> около 30,
200 обьектов - записи или таблицы?
Ты не думай, ты возми сделай тесты: селект с условием где 3 ора (с подселектами) или селект с одним условием на миллионе записей.
> Это не есть бред ? Когда у тебя просят совета, можешь -
> советуй, не можешь не советуй, а риторикой и я богат. Извини
> за прямоту.
А можно уточнить - что Ваше Величество посчитало бредом?
Sergey13 (2006-08-04 14:27:00) [42]> [12] jiny (04.08.06 14:14)
Я так думаю, что каждый контрол прописывать - лишнее. Он или есть или его нет - зависит от типа доступа читатель/писатель.
jiny (2006-08-04 14:27:00) [43]>>Dok (04.08.06 14:18) [13]
ты парень как то агрессивно настроен, никто тебе и не сказал что это постулат, которого надо придерживаться, это всего лишь догма, мое предположение, а насчет скорости, не думаю что из за 200 объектов доли секунд будут иметь большое значение, у меня остатки на товары из 6 логич.журналов формируются за доли секунды, причем товаров за одну выборку около 30, ну даже если это и так, буду искать оптимальный вариант. А высказываться типа :
> Да уж... Парава , права и еще раз права....
> Отказаться от Парадокса и ему подобных...
> Выбрать FireBird, MS SQL, Oracle - любую, слава богу есть
> бесплатные варианты.
> Создать вьюхи, дать нужные права на них и спать спокойно
> + реализовать проверку на клиенте.
Это не есть бред ? Когда у тебя просят совета, можешь - советуй, не можешь не советуй, а риторикой и я богат. Извини за прямоту.
Dok (2006-08-04 14:18:00) [44]
> 1 PermissionsType, где указаны все объекты к разрешению
> вот здесь ступор: только формы и контролы на форме указывать
> ? ну что-то типа :
>
> Форма;
> Контрол (если есть необходимость)
бред. Данными надо оперировать а не формами. от данных надо отталкиваться, если на поле нет доступа , то или контрол дизейблить или крывать.
> 2 Roles, роли ;
роли должны бить такими же пользователями.
> 3 FinalPermissions, подчиненная к Roles таблица, где указывается
> роль и разрешение на конкретный объект, в итоге имеем список
> разрешений к конкретной роли
забудь о скорости
jiny (2006-08-04 14:14:00) [45]Я правильно понял ? хочу просто уточнить,
создаю таблицы:
1 PermissionsType, где указаны все объекты к разрешению
вот здесь ступор: только формы и контролы на форме указывать ? ну что-то типа :
Форма;
Контрол (если есть необходимость)
2 Roles, роли ;
3 FinalPermissions, подчиненная к Roles таблица, где указывается
роль и разрешение на конкретный объект, в итоге имеем список разрешений к конкретной роли
что-то типа :
Роль
Форма
Контрол (если есть необходимость)
Тип доступа (два поля, т.к. можно запретить пользователю вообще открывать Форму/таблицу)
4 Users, где есть поле принадлежности к той или иной роли
> Плюс (вернее минус) - при таком подходе нужен администратор
> этого
> программного комплекса и инструмент для его работы.
А насчет этого я не буду переживать , потому как все нас не убивает, делает нас сильнее (кажись так)
Администратор есть, только надо сделать инструмент
Dok (2006-08-04 14:12:00) [46]
> Уж извините, пожалуйста за резкость, но это и ежу понятно,
> что надо, и это надо уже делается !
Извини за резкость, тогда какого ты тут все долбаешь?
> modul;FormName;TableName;CanSelect;CanModify
RecordID, UserID, GroupID, CanRead, CanWrite, CanDelete, CanGrant
Sergey13 (2006-08-04 13:59:00) [47]> я так думаю, что нужно создать в таблице структуру типа
> modul;FormName;TableName;CanSelect;CanModify
Можно и по этому пути пойти. Только структура, ИМХО, должна быть
Юзер (или роль)
Форма
Тип доступа (чтение/изменение)
Плюс (вернее минус) - при таком подходе нужен администратор этого программного комплекса и инструмент для его работы.
jiny (2006-08-04 13:51:00) [48]>>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:05:00) [49]> [4] jiny (04.08.06 12:15)
> как мне запретить доступ
> к конкретным формам, кнопкам на формах, закладкам пейджконтролов
> приложения, уже на уровне таблицы БД FireBird.
Например, можно перед визуализацией формы открывать основной запрос, в ней отображаемый. При неимении прав на какую либо таблицу запрос обломится. Надо поймать этот облом и культурно послать юзера в сад.
Petr V. Abramov (2006-08-04 12:42:00) [50]А аксесс перелить, там хоть как-то с правами разрулено.
Dok (2006-08-04 12:26:00) [51]Да уж... Парава , права и еще раз права....
Отказаться от Парадокса и ему подобных...
Выбрать FireBird, MS SQL, Oracle - любую, слава богу есть бесплатные варианты.
Создать вьюхи, дать нужные права на них и спать спокойно + реализовать проверку на клиенте.
Desdechado (2006-08-04 12:19:00) [52]Разграничение прав на уровне данных и операций бизнес-логики вполне хорошо взаимодополняют друг друга. Поэтому заявлеие [1], имхо, несколько безапелляцоинно звучит. Если даже вся бизнес-логика на сервере, то даже в этом случае залезть в какой-то режим и не иметь возможности в нем что-то сделать несколько странно смотрится. Лучше уж совсем туда не пускать.
Автору
Самый простой вариант (не самый лучший, конечно) - это в БД прописать в спецтабличке список защищаемых элементов бизнес-логики (права на табличку только для чтения у пользователей). И группам/ролям соотнести, какие из них доступны для выполнения. Но это не отменяет защиту данных на уровне БД.
jiny (2006-08-04 12:15:00) [53]Допустим я перевожу базу не на ОРАКЛ, т.к. это сильно круто для организации, где всего 100 документов в день вноситься, да и лицензии не дешевые, а на FireBird. Представьте, что мой вопрос не касается db а уже FDB, как мне запретить доступ к конкретным формам, кнопкам на формах, закладкам пейджконтролов приложения, уже на уровне таблицы БД FireBird.
>>ANB © (04.08.06 11:59) [1]
>>Разграничение доступа на уровне клиента - вчерашний век. Пытливые
>>пользователи тогда будут лазить в базу и править прямо там.
Если я им дам роль(на уровне FireBird), которая будет видеть роли и права только на уровне select, то не будут.
Да и все-таки мне нравится разграничение ролей в 1С, хотелось бы освоить этот метод, даже для себя.
ANB (2006-08-04 12:04:00) [54]
> Johnmen © (04.08.06 12:02) [2]
Нет, конечно, но мне он больше всего нравится :)
Johnmen (2006-08-04 12:02:00) [55]
> срочно переводи систему на Оракл XE
Хм... Это единственный вариант?
ANB (2006-08-04 11:59:00) [56]Разграничение доступа на уровне клиента - вчерашний век. Пытливые пользователи тогда будут лазить в базу и править прямо там.
Совет - срочно переводи систему на Оракл XE, тогда сможешь защитить все на уровне БД. Способов для этого там - целая куча.
| |
Страницы: 