Добрый день, уважаемые.
Уже не первый проект появляется необходимость реализовать систему разграничения прав доступа к функциям (объектам, модулям) программы. Приграммы типа клиент-сервер СУБД. Интересует разграничение прав на стороне приложения, а не сервера БД. Поделитесь опытом, как лучше реализовать текое разграничение? Что выбрать в качестве элемента разграничения? Как обеспечить доступ к таким элементам? Ну и все такое.
Заранее спасибо.

На уровне сервера учетные записи однозначно будут. И пользователи там будут. И разграничение в доступе к данным будет. Это не вместО, а скорее вместЕ. Т.е. вместе с разграничением по данным необходимо разграничение по возможностям (функциям) программы. Скажем один пользователь может нажать на кнопку, другой - нет. Как лучше такой подход организовать архитектурно (без динамического создания объектов)?

Инструменты: C# (WPF\WinForms). Интересует именно архитектура вызова методов, чтобы учесть разграничение по функциям.

maytonRoman39,
... Вам-же надо просто отобразить на экране пользователя список тех режимов, форм, отчётов, который соответствует авторизации пользователя.
...

Вообщем да. С методами это я неправильно выразился. Так вот как организовать работу с таким "списком"? Из чего будет состоять такой список? Вот например с кнопкой. Как она будет отражена в таком списке? Т.е. например в конструкторе формы вызвать "что то" что вернет список "чего то", на основе этого списка, например, сделать кнопку неактивной.

to alex_k:
У Вас кнопка создается во время выполнения. Я хотел бы этого избежать. Если не секрет, как у Вас проверяется наличие прав по передаваемой строке?

mayton
Вот в этом и вопрос: на что выдавать гранты? Под кнопкой скрывается некоторая функция, которая либо доступна либо нет.

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

Спасибо за полезную информацию...

mayton
...
Я-бы постарался сделать две формы: одну с просмотром персонала, и другую с просмотром персонала и окладов.
В таком случае придется "плодить" много "родственных " форм. Форма просмотра персонала, Форма просмотра пресонала и окладов, Форма просмотра персонала и обрабатываемых ими заказов, Форма просмотра персонала, обрабатываемых ими заказов и окладов и т.д.
И в результате получится тот же перебор, который Вас "ужаснул". Всегда хочется уменьшить прямой перебор чего либо в программе...

В принципе весь вопрос сводится к централизованному разграничению прав доступа, что бы максимально облегчить процесс сопровождения программы. Не всегда удается предусмотреть все возможные объекты к которым следует ограничить доступ на этапе проектирования ПО.