ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
106 сообщений из 106, показаны все 5 страниц
  все  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33573171
Аналитика+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Аналитика+
Гость
Существует несколько способов ограничения доступа к данным. Давайте откинем стандартные возможности СУДБ, таких как гранты Oracle и тому подобное. Поговорим о структуре БД, которая информацию о доступе пользователей системы к элементам системы хранит в себе, т.е. в своих таблицах. Рассмотрим так называемый "кумулятивный вариант", когда по умолчанию пользователю в системе ничего не доступно. Здесь я вижу сразу три подхода, и любое Ваше мнение о каждом из них хотелось бы услышать:
1. дача прав в разрезе пользователей
2. дача прав в разрезе ролей + назначение ролей пользователям
3. дача прав в разрезе групп пользователей + определение пользователя в группу
В процессе обсуждения я преследую цель получить ответ на вопрос:
Стоит ли изначально проектировать в системе все три подхода вкупе?
СПРАВКА:
В ИСУ ПАРУС присутствует схема 1+2
В ОС MS WINDOWS - схема 1+3
...
Рейтинг: 0 / 0
01.03.2006, 12:04
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33573332
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Баян,копий много было сломано. Поищите по форуму с ключевыми словами "контроль доступа", "безопасность" и не разводите лишний раз флейм!Там и ссылок полно на разные модели, плюсы/минусы рассмотрены.
...
Рейтинг: 0 / 0
01.03.2006, 12:38
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33573537
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Три не стоит. Варианты 2 и 3 отличаются только заменой группа на роль.
...
Рейтинг: 0 / 0
01.03.2006, 13:18
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33573665
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 2. дача прав в разрезе ролей + назначение ролей пользователям
> 3. дача прав в разрезе групп пользователей + определение пользователя

Эти варианты по сути ничем друг от друга не отличаются. Неважно, как назвать объединение пользователей - группа или роль.

> Стоит ли изначально проектировать в системе все три подхода вкупе?

Возьмите нормальную файловую систему (например, ext2 или reiserfs) и посмотрите, как в ней организовано ограничение доступа. Или - что правильнее, но сложнее - посмотрите, как организована SELinux: пожалуй, это наиболее разумная реализация ограничения доступа из существующих.
...
Рейтинг: 0 / 0
01.03.2006, 13:52
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33573859
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Аналитика+Существует несколько способов ограничения доступа к данным
доступ надо давать не к данным а к функциям системы а это совсем другая песня
...
Рейтинг: 0 / 0
01.03.2006, 14:32
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33574384
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
моддоступ надо давать не к данным а к функциям системы
Доступ надо ограничивать и к данным и к функциям системы.
...
Рейтинг: 0 / 0
01.03.2006, 15:58
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33574387
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Да иже начнется флейм: пусть есть набор данных предположим о сотрудниках. У них есть подчиненные. Вы имеете право смотреть только содрудников ниже Вас по иерархии (пусть структура управления иерархическая,а не матричная).Где тут функция? Только не говорите,что должна быть функция "Просмотр данных о сотрудниках своего уровня"?Это словоблудие...

Меньше лозунгов-больше дела.
...
Рейтинг: 0 / 0
01.03.2006, 15:58
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33574399
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ShtockГде тут функция?
Если обобщать, доступ к функции есть частный случай доступа к данным (недоступность функции == пустое множество данных, для которых она доступна). Но такое обобщение представляется мне непрактичным; неудобным ни для рассуждений, ни для реализации.
...
Рейтинг: 0 / 0
01.03.2006, 16:00
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33574470
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Полностью с Вами,softwarer,согласен.Просто тема изначально флеймовая.
...
Рейтинг: 0 / 0
01.03.2006, 16:17
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33574481
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Shtock У них есть подчиненные. Вы имеете право смотреть только содрудников ниже Вас по иерархии (пусть структура управления иерархическая,а не матричная).Где тут функция? Только не говорите,что должна быть функция "Просмотр данных о сотрудниках своего уровня"?Это словоблудие...

Смотреть ? Получать отчет ? Вводить новых ? удалять ? увольнять ?
Где тут данные ? (и где словоблудие)
...
Рейтинг: 0 / 0
01.03.2006, 16:20
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33574574
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kolobok0
Участник
Аналитика+Существует несколько способов ограничения доступа к данным. ....

маленькое замечанице...
распределение прав доступа в клиент-серверных....
и органичение доступа к данным...

это разные весчи...
в клиент-серверных системах права доступа разделяються на...

права ядра..
права коннекшенна..
права некой учётной записи...

про БД - это от лукавого...или по другому - это частный случай...

с уважением
(круглый)
...
Рейтинг: 0 / 0
01.03.2006, 16:38
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575487
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
guest_20040621
> 2. дача прав в разрезе ролей + назначение ролей пользователям
> 3. дача прав в разрезе групп пользователей + определение пользователя

Эти варианты по сути ничем друг от друга не отличаются. Неважно, как назвать объединение пользователей - группа или роль.


Есть некоторое преимущество реализации пунктов 1,2,3 вкупе. Если деятельность некоторой группы пользователей характеризуется набором ролей, то при реализации назначения ролей группе мы получаем преимущества при администрировании такой системы.
...
Рейтинг: 0 / 0
02.03.2006, 06:18
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575609
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Есть некоторое преимущество реализации пунктов 1,2,3 вкупе.

Никаких, кроме дополнительного геморроя. Для любого объединения пользователей могут быть заданы любые дополнительные признаки.
...
Рейтинг: 0 / 0
02.03.2006, 08:39
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575627
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeЕсть некоторое преимущество реализации пунктов 1,2,3 вкупе.....
Это преимущество называется "включение одной роли в другую роль". Никаких "вкупе" для этого не требуется. В данном случае, с учетом приведенных примеров, "группа" и "роль" - синонимы, и желание сделать и то, и другое означает только то, что проектировщик сам не знает толком, чего хочет, просто тащит все что видел без разбора.
...
Рейтинг: 0 / 0
02.03.2006, 08:54
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575639
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarer
Это преимущество называется "включение одной роли в другую роль".


Сам понял что сказал? Роль нельзя включать в другую роль. Никоим образом!
...
Рейтинг: 0 / 0
02.03.2006, 08:59
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575649
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
guest_20040621> Для любого объединения пользователей могут быть заданы любые дополнительные признаки.
Кино и немцы. Для объединения пользователей я знаю только одно понятие - "Группа пользователей". Все ваши "дополнительные признаки" - ни что иное как попытка замаскироать группировку.
...
Рейтинг: 0 / 0
02.03.2006, 09:03
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575708
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeСам понял что сказал?
Понял. И тебе того же желаю.

SublimeРоль нельзя включать в другую роль. Никоим образом!
Жаль, что ведущие вендоры придерживаются противоположного мнения. А так да, конечно, получается очень здорово - сначала придумываем группы, чтобы грантовать им роли, потом придумываем конгломераты, чтобы включать в них группы (их Вы ведь тоже запретите включать друг в друга, верно?) и так далее, пока слов хватает.

Sublime Для объединения пользователей я знаю только одно понятие - "Группа пользователей"
Ну вот и добрались до истока.
...
Рейтинг: 0 / 0
02.03.2006, 09:34
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575752
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Роль и группа это одно и то же. При этом роли могут иметь иерархию со всеми вытекающими.
...
Рейтинг: 0 / 0
02.03.2006, 09:45
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575781
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarer...потом придумываем конгломераты, чтобы включать в них группы (их Вы ведь тоже запретите включать друг в друга, верно?)...

Группы в отличие от ролей могут иметь иерархическую структуру.
...
Рейтинг: 0 / 0
02.03.2006, 09:52
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575820
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> я знаю только одно понятие - "Группа пользователей"

Хм... больше читайте, - Вы и представить себе не можете, сколько всего Вы не знаете. ;))

> Все ваши "дополнительные признаки" - ни что иное как попытка
> замаскироать группировку.

Мои (если Вы настаиваете) дополнительные признаки (включая множественную иерархию, роли _внутри_ групп и пр. хрень) - это удобная, логичная и простая организация пользователей. Это _не синоним_ группировки.
...
Рейтинг: 0 / 0
02.03.2006, 10:04
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33575829
Фотография UK0IAI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UK0IAI
Участник
ShtockДа иже начнется флейм: пусть есть набор данных предположим о сотрудниках. У них есть подчиненные. Вы имеете право смотреть только содрудников ниже Вас по иерархии (пусть структура управления иерархическая,а не матричная).Где тут функция? Только не говорите,что должна быть функция "Просмотр данных о сотрудниках своего уровня"?Это словоблудие...

Меньше лозунгов-больше дела.

Почему нет?. Начальник отдела делегировал право вести табель своему подчиненому. В отделе две (много) подгрупп. Табельщик "не видит" всего списка сотрудников - ибо он где то ниже по иерархии подчинения.

Нужна Бизнес-функция - открыть доступ ко всему (части ) списка.

При этом, легко ВКЛЮЧИТЬ или ВЫКЛЮЧИТЬ "Просмотр данных о сотрудниках своего уровня".

Вот моя любимая схема:

Юзер, Группа Юзеров, Бизнес-функция.
Бизнес-функция имеет (роли БД, ресурсы (строки БД) + коллекции элементов интерфейса...(типа виден-не виден)).

Юзер в итоге получает свои БФ, и через них - уровни доступа к системе.
Юзер это "имеет" по разному = наследуя от Группы или путем прямого назначений.

А при в ходе в систему, юзер никаких прав не имеет.

Каждая Прога имеет "Первую Строку Программного кода", где проверяются привелегии. Если false - Прога САМА прерывает работу.
...
Рейтинг: 0 / 0
02.03.2006, 10:06
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576108
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeГруппы в отличие от ролей могут иметь иерархическую структуру.
То есть до полного идиотизма опускаться не приходится, и то хорошо.

Теперь тебе осталось понять, что слово "роль" ты понимаешь существенно по-особому, отлично от минимум троих твоих собеседников, и постулируемое тобой "в отличие" мягко говоря неубедительно.
...
Рейтинг: 0 / 0
02.03.2006, 11:13
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576147
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
UK0IAIЮзер в итоге получает свои БФ, и через них - уровни доступа к системе.
При рассуждении только через функции становится неудобным опираться на перечислимые справочники. Допустим, скажем, секретать отдела имеет право заказывать кофе для отдела - хорошо, описывается через функцию "заказать кофе для своего отдела". Можно сделать функцию "заказ кофе для любого отдела" - опять же все хорошо. Но допустим, у отдела нет секретарши, и решили что за кофе они должны обращаться к секретарше соседнего отдела. В этом случае придется делать функцию "заказ кофе для отдела номер четыре", потом - "заказ кофе для отдела номер восемь" и так далее.

Тут становится куда удобнее другая модель и рассуждений, и реализации - каждой секретарше соотнесен набор отделов, для которых она имеет право заказывать кофе. То есть подрезка справочника отделов, ограничение на данные.
...
Рейтинг: 0 / 0
02.03.2006, 11:22
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576399
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarer
Это преимущество называется "включение одной роли в другую роль". Никаких "вкупе" для этого не требуется. В данном случае, с учетом приведенных примеров, "группа" и "роль" - синонимы, и желание сделать и то, и другое означает только то, что проектировщик сам не знает толком, чего хочет, просто тащит все что видел без разбора.

Вы мне пытаетесь доказать, что иерархическая структура ролей есть ни что иное как назначение ролей группе. Позвольте реплику. Схема роль+группа дает возможность включения одной роли в несколько групп. Ваш же подход исключает такую ситуацию. Упс! Жду ваших комментариев.
...
Рейтинг: 0 / 0
02.03.2006, 12:09
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576438
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
softwarer
Тут становится куда удобнее другая модель и рассуждений, и реализации - каждой секретарше соотнесен набор отделов, для которых она имеет право заказывать кофе. То есть подрезка справочника отделов, ограничение на данные.
Совершенно верно. Доступ к функциям сопровождается ограничениями на доступ к данным, необходимым для выполнения данной функции.
На самом деле все очень не просто :)
...
Рейтинг: 0 / 0
02.03.2006, 12:16
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576447
-------------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-------------
Участник
Вопрос к гуру - сколько ошибок в такой схеме:
Проверка доступа:
Код: plaintext
EXISTS (Текущий_Пользователь, Запрошенное_Действие, Требуемые_Данные) IN Разрешение(Пользователь, Действие, Данные)

где Разрешение(Пользователь, Действие, Данные) может быть получено, например, из следующего набора отношений:
Код: plaintext
1.
2.
3.
Членство (ID_Роли, ID_Охватывающей_Роли)
Видимость_Данных(ID_Роли, Данные)
Разрешенные_Действия(ID_Роли, Действие, Тип_Данных)

???
схема несколько упрощена, т.е. к примеру, Видимость_Данных() может задаваться несколькими подобными таблицами
...
Рейтинг: 0 / 0
02.03.2006, 12:17
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576657
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeСхема роль+группа дает возможность включения одной роли в несколько групп. Ваш же подход исключает такую ситуацию.
Кто Вам сказал такую глупость?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
Connected to Oracle9i Enterprise Edition Release  9 . 2 . 0 . 7 . 0  
Connected as system


SQL> create role role1 ;

Role created

SQL> grant select on sys.dual to role1 ;

Grant succeeded

SQL> create role role2 ;

Role created

SQL> create role role3 ;

Role created

SQL> grant role1 to role2 ;

Grant succeeded

SQL> grant role1 to role3 ;

Grant succeeded

SQL>
...
Рейтинг: 0 / 0
02.03.2006, 12:57
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33576802
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarer SublimeСхема роль+группа дает возможность включения одной роли в несколько групп. Ваш же подход исключает такую ситуацию.
Кто Вам сказал такую глупость?

[src oracle]Connected to Oracle9i Enterprise Edition Release 9.2.0.7.0
Connected as system


Аналитика+Давайте откинем стандартные возможности СУДБ, таких как гранты Oracle и тому подобное

Насколько я понял тема поднята для обсуждения структуры БД, исключая дополнительные возможности такие как role Oracle.
...
Рейтинг: 0 / 0
02.03.2006, 13:22
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33578978
iamhere
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iamhere
Участник
А что - есть стандартизованное определение термина "роль"? ;)
Можно ссылочку на стандарт?

Утверждение "роли не могут включаться в другие роли" такое же бестолковое, как и утверждение "роли могут включаться в другие роли", потому оба этих утверждения основаны просто на возможностях конкретных программных продуктов (кто уж какие видел...), и на том, что понятие "роль" или "группа" означает в этих продуктах.
...
Рейтинг: 0 / 0
03.03.2006, 10:09
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33579005
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeНасколько я понял тема поднята для обсуждения структуры БД, исключая дополнительные возможности такие как role Oracle.
Вы сказали две глупости - сначала "роль не может включаться в роль", потом - "нельзя организовать включение в несколько ролей". В контексте "обсуждения вообще".

Я показал Вам первый попавшийся под руку пример обратного. Oracle - вполне входит в "вообще"; то, что можно сделать в нем, никто не мешает сделать где-либо еще. Если верить логике, этого достаточно, чтобы опровергнуть Ваше утверждение.
...
Рейтинг: 0 / 0
03.03.2006, 10:15
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33579277
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
можно глупый вопрос?
что будет если:
Код: plaintext
1.
grant role1 to role3 ;
grant role3 to role1 ;
если так низзя - то _явное_разделение иерархии на (иерархические) "группы" и (простые, "аксиоматические"=="базовые") "роли" _кажется_ _мне_ предпочтительным (логически прозрачно, и кажется, можно все то же, что и для более сложной системы иерархии только ролей). (Это же просто напоминает отрезание листов (в данном случае уместнее говорить "корней", что не принципиально) от иерархии, с выделением их в отдельную "базовую" сущность, как правило, оправданное.)

возможно есть преимущества одной из схем в быстродействии, но какой именно - может быть кто-то растолкует? (мне попадались в основном лесовидные иерархии, сильно растущие по части листьев - там их выделение в обособленные сущности спасает, тут же кажется множественное наследование и какие унутре его проблемы - я чесно говоря не знаю)
...
Рейтинг: 0 / 0
03.03.2006, 11:11
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33579756
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
4321что будет если:
Код: plaintext
1.
grant role1 to role3 ;
grant role3 to role1 ;

Думаю, сообщение о циклической зависимости. (проверив) Да, именно так.

4321
если так низзя - то _явное_разделение иерархии на (иерархические) "группы" и (простые, "аксиоматические"=="базовые") "роли" _кажется_ _мне_ предпочтительным (логически прозрачно, и кажется, можно все то же, что и для более сложной системы иерархии только ролей).
Думаю, это философский вопрос. Мне кажется, Вы пренебрегаете мнением старины Оккама.

В любом случае, следует отметить что. В интерфейсе администрирования никто не мешает построить нравящуюся Вам модель. В ней потребуется ввести операцию "преобразовать роль в группу" - но я так понимаю, Вы на это согласитесь. Но! С точки зрения реализации - между этими понятиями нет никакой разницы; это должен быть один механизм, одна таблица с флажком "роль или группа есть данная конкретная запись". Собственно пример на тему:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Connected to Oracle9i Enterprise Edition Release  9 . 2 . 0 . 7 . 0  
Connected as system

SQL> select username from dba_users where substr ( username,  1 ,  1  ) = 'O' ;

USERNAME
------------------------------
OWB
OWBRT_SYS
OWB_RT
OWB_USER
OUTLN
ORDSYS
ORDPLUGINS
ODM
ODM_MTR
OLAPSYS
OE

 11  rows selected

SQL> select role from dba_roles where substr ( role,  1 ,  1  ) = 'O' ;

ROLE
------------------------------
OEM_MONITOR
OWB_OWB
OLAP_DBA
OWBR_OWB

SQL> select name, type# from sys.user$ where substr ( name,  1 ,  1  ) = 'O' ;

NAME                                TYPE#
------------------------------ ----------
OUTLN                                    1 
OEM_MONITOR                              0 
ORDSYS                                   1 
ORDPLUGINS                               1 
ODM                                      1 
ODM_MTR                                  1 
OLAPSYS                                  1 
OWB_OWB                                  0 
OLAP_DBA                                 0 
OE                                       1 
OWB                                      1 
OWBR_OWB                                 0 
OWBRT_SYS                                1 
OWB_RT                                   1 
OWB_USER                                 1 

 15  rows selected

4321с выделением их в отдельную "базовую" сущность, как правило, оправданное.
Оправданность здесь с моей точки зрения - вопрос вкусов. Во всяком случае объективных аргументов в ту и другую сторону мало.

Собственно, несколько месяцев назад мне пришлось по работе выдержать как раз такой спор. Мне пришлось несколько недель повторять коллегам-начальникам, что в той идеологии системы, которую мы строим, понятия "группа" и "отчет" оказываются неразличимыми, целиком совпадают по функционалу и свойствам. Несколько недель люди пытались внести то или иное искусственное различие, прежде чем наконец окончательно убедились, что от этого идет только лишний геморрой.

4321возможно есть преимущества одной из схем в быстродействии, но какой именно - может быть кто-то растолкует?
Эти схемы не должны отличаться ни в чем, кроме пары мелочей в интерфейсе. Соответственно все их различие - в восприятии.
...
Рейтинг: 0 / 0
03.03.2006, 13:01
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33580056
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarer SublimeНасколько я понял тема поднята для обсуждения структуры БД, исключая дополнительные возможности такие как role Oracle.
Вы сказали две глупости ... в контексте "обсуждения вообще".
Я показал Вам первый попавшийся под руку пример обратного.

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

softwarer
Oracle - вполне входит в "вообще"; то, что можно сделать в нем, никто не мешает сделать где-либо еще.

И как вы в вашей БД сделаете назначение одной роли нескольким другим ролям? Предвижу ваш ответ: через новую таблицу. И как бы вы назвали эту вашу новую сущность для группировки ролей?
...
Рейтинг: 0 / 0
03.03.2006, 14:03
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33580925
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SublimeВо-первых мы сдесь обсуждаем конкретно поставленную задачу
Это не соответствует действительности.

SublimeВаш "первый попавшийся пример" извините из другой оперы.
Это не соответствует действительности. Этот первый попавшийся пример полностью соответствует формулировке задачи (программа, хранящая информацию о правах доступа к своим элементам в своих таблицах).

SublimeС такими примерами в сад, пожалуйста. Сейчас вы поймете почему:
Я сомневаюсь в Ваших способностях пророка, но независимо от этого просил бы говорить по делу.

SublimeИ как вы в вашей БД сделаете назначение одной роли нескольким другим ролям?
Хм. Связь многие ко многим. Методы реализации известны.

SublimeИ как бы вы назвали эту вашу новую сущность для группировки ролей?
Хм. ACC$ROLE_ROLES, как-нибудь так. Какой будет следующий вопрос - по отсечению циклов? Могу рассказать, тоже тривиально делается.
...
Рейтинг: 0 / 0
03.03.2006, 17:02
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33583017
Sublime
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sublime
Гость
softwarerДумаю, это философский вопрос...
В любом случае, следует отметить что. В интерфейсе администрирования никто не мешает построить нравящуюся Вам модель.
4321с выделением их в отдельную "базовую" сущность, как правило, оправданное.
Оправданность здесь с моей точки зрения - вопрос вкусов. Во всяком случае объективных аргументов в ту и другую сторону мало.

Мне нечего добавить - Вы сами все за меня сказали.
...
Рейтинг: 0 / 0
06.03.2006, 07:58
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33583474
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
softwarer 4321с выделением их в отдельную "базовую" сущность, как правило, оправданное.
Оправданность здесь с моей точки зрения - вопрос вкусов. Во всяком случае объективных аргументов в ту и другую сторону мало.

Соответственно все их различие - в восприятии.
немного поразмыслив, соглашусь:
отдельной сущностью-листами (базисной сущностью) для дерева групп/ролей будут видимо сами правила (доступа). Собирание же их по иерархии групп/ролей в принципе не сильно отличается для обоих подходов. а т.к. кажется нет причин запрещать цеплять элементарное правило к любому уровню иерархии, то и видимо нет особой ценности в выделении отдельной сущности "базовая роль".
...
Рейтинг: 0 / 0
06.03.2006, 11:21
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33674286
Фотография insect
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
insect
Участник
softwarer ShtockГде тут функция?
Если обобщать, доступ к функции есть частный случай доступа к данным (недоступность функции == пустое множество данных, для которых она доступна). Но такое обобщение представляется мне непрактичным; неудобным ни для рассуждений, ни для реализации.
Есть такое понятие из начальной теории построения компьютеров - Машина фон Неймана... там код и данные равноправны ...
И то, что для одних является данными для других является программами... так работают современные операционные системы...
...
Рейтинг: 0 / 0
18.04.2006, 17:27
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33674687
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
insectЕсть такое понятие из начальной теории построения компьютеров
softwarerНо такое обобщение представляется мне непрактичным
...
Рейтинг: 0 / 0
18.04.2006, 19:42
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33684688
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
-------------
Код: plaintext
1.
2.
3.
Членство (ID_Роли, ID_Охватывающей_Роли)
Видимость_Данных(ID_Роли, Данные)
Разрешенные_Действия(ID_Роли, Действие, Тип_Данных)



Видимость_Данных - это одно из Разрешенных Действий.
...
Рейтинг: 0 / 0
23.04.2006, 00:33
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33684801
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>-------------
>Guest
>EXISTS (Текущий_Пользователь, Запрошенное_Действие, Требуемые_Данные)...

Наболевший вопрос.
Если позволите, перефразирую его для многозвенки.
Текущий_Пользователь - удаленный клиент информационной системы, его аутентификация и авторизация производится сервером приложений.
Запрошенное_Действие - функция, выполняемая сервером приложений.
Требуемые_Данные - выборка, построенная сервером данных из допустимых клиенту строк в разных таблицах.
Подскажите пожалуйста, идеи построения схем ограничения доступа клиента к строкам таблиц.
Группировал клиентов (число групп <1024) и закреплял за клиентом и строками таблиц битовое поле (закреплял за клиентом список ему разрешенных групп ).
Но сосет, что-то не так, может есть более быстрые и интересные варианты?.

С уважением, Владимир.
...
Рейтинг: 0 / 0
23.04.2006, 11:03
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685037
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
ВМоисеевПодскажите пожалуйста, идеи построения схем ограничения доступа клиента к строкам таблиц.
Группировал клиентов (число групп <1024) и закреплял за клиентом и строками таблиц битовое поле (закреплял за клиентом список ему разрешенных групп ).
Но сосет, что-то не так, может есть более быстрые и интересные варианты?.

С уважением, Владимир.
распределяйте по Ролям->Пользователям точки входа , а не содержимое. Это единственная, подтверждаемая практикой, модель.
Представьте пример. Вас пустили в зал с товаром, часть которого можно взять, а часть нет. Не находите геммороем? Так почему в ИС его пытаются постоянно создать? Лучше разделить на два зала. Платите деньги и получайте ключ от двери, за которой доступно все.
...
Рейтинг: 0 / 0
23.04.2006, 20:22
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685050
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> распределяйте по Ролям->Пользователям точки входа, а не содержимое.
> Это единственная, подтверждаемая практикой, модель.

Чушь. Как раз на практике моделей больше, чем упоминается в этом обсуждении.

> Представьте пример.

Плохой пример. Политика доступа может (вообще говоря - и обязана) быть конфигурируемой. Прямая аналогия - операционные системы.
...
Рейтинг: 0 / 0
23.04.2006, 20:58
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685102
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Прежде чем называть что-то чушью, приведите реальный пример. Из практики С удовольствием бы проанализировал.
А так эти кнопки (видеть, редактировать, удалять и т.п.) лишнее, хоть и есть и работает. Только не используется, потому что до использования не доходит.
А насчет политики доступа - кто же спорит. Конечно должна быть конфигурируемой. Не оспаривается. Только Вы не о том. О чем.. не понял.
p.s.
Вы в гостинице. Перед Вами несколько дверей. Открываете одну из них. Видите 3 кровати. Одна из них ваша. На 2 других нельзя. Пробуйте.
...
Рейтинг: 0 / 0
23.04.2006, 23:17
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685121
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> приведите реальный пример

Пример чего? Моделей? Легко. Тривиальная модель доступа в общем виде: RBAC + ACL + контекст. Обсуждаемые здесь модели получаются из тривиальной путем удаления соответствующих компонентов. Причем, именно тупым удалением.

> Только Вы не о том.

О том, о том. Вы не допускаете существования альтернативных правил, - это принципиальная ошибка. Ограничивается доступ к содержимому, никаких "точек входа" нет и быть не может. Это Ваша вторая принципиальная ошибка.

> Пробуйте.

Что "пробуйте"?
...
Рейтинг: 0 / 0
24.04.2006, 00:15
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685126
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Скажите сначала в чем ошибка, потом можно продолжать обсуждать.
А то я говорю о ролевом доступе (RBAC, если Вы любите сановские абревиатуры), списках разрешенных точек доступа (ACL для любителей), которые в итоге предоставляют пользователю некий контент, а Вы мне в ответ - это чепуха, с аргументами в цикле. Определитесь и поговорим.
...
Рейтинг: 0 / 0
24.04.2006, 00:32
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685146
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Скажите сначала в чем ошибка

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

> списках разрешенных точек доступа (ACL для любителей)

Здесь нет никаких "точек". Есть список. Разница, надеюсь, понятна?

Вы намеренно опустили контекст? Напрасно. Это наиболее важная часть ограничения доступа. Причем, именно с практической точки зрения.

> с аргументами в цикле

Никаких циклов. Очевидная ахинея imho не требует развернутого объяснения.
...
Рейтинг: 0 / 0
24.04.2006, 01:49
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685197
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
:) Мои пять копеек в эту кашу :)

Как мне кажется, сначала все достаточно просто.
Есть множество пользователей.
Есть множество функций.
Есть множество объектов, над которыми могут выполняться функции.
Требуется с минимальным геморроем управлять отношением (многие ко многим ко многим)
между пользователями, фкнкциями и объектами.
И тут все сразу становится сложно...
Вводятся группировки. Группировка пользователей - это группа. Группировка функций - это роль.
Группировка объектов - это танцы с бубном, натянутые на конкретную схему данных.
А сочетание информационных схем для группировки пользователей, ролей и данных, и, наконец, само отношение (пользователи(группы)-функции(роли)-данные) в результате зависит от целесообразности в каждом конкретном случае и фантазии разработчика...
...
Рейтинг: 0 / 0
24.04.2006, 07:04
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685442
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
?Как мне кажется, сначала все достаточно просто.
Есть множество пользователей.
Есть множество функций.
Есть множество объектов, над которыми могут выполняться функции.

Есть множество пользователей + иерархия групп пользователей
Есть множество функций + иерархия групп функций.
Есть множество объектов + иерархия групп объектов.
Права раздаются группам пользователей на группы функций и группы объектов. После преобразований получаем:
пользователь - функция
пользователь - объект
По этому ре-ту и проверяем права. Не так уж сложно.
...
Рейтинг: 0 / 0
24.04.2006, 10:18
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685636
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
?Группировка пользователей - это группа. Группировка функций - это роль.

Жизнеспособная схема из практики.

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

Группы пользователей имеет смысл использовать для организации доступа к данным. Логически понятие группы пользователей от роли, конечно, практически не отличается. Но в житейском смысле это разные вещи. В типичной СЭД групп пользователей оказывается много, а ролей - очень мало. В типичной OLTP - наоборот. Могут возникнуть какие-то тонкости, в результате которых придется реализовать обе концепции.

Первый же вариант (выдача прав пользователю) реализуется что так, что так, путем создания группы (или роли) из (для) одного пользователя.
...
Рейтинг: 0 / 0
24.04.2006, 11:16
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685730
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Согласен скорее с ?
Пример, когда доступность данных зависит от функции:

Менеджер имеет право видеть только свои накладные и менеджеров по списку, управляемому администратором.
Менеджер имеет право получить информацию о доле стоимости своих накладных в общей сумме накладных.

И за какой дверью лежат накладные?
...
Рейтинг: 0 / 0
24.04.2006, 11:41
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685748
iamhere
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iamhere
Участник
ModelRМенеджер имеет право видеть только свои накладные и менеджеров по списку, управляемому администратором.
Менеджер имеет право получить информацию о доле стоимости своих накладных в общей сумме накладных.


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

Решать, видимо, надо так:
Общим правилом менеджеру разрешается видеть только свои накладные.
Специальная функция, с привелегированным доступом, позволяет посчитать эту самую долю, независимо от прав вызывающего менеджера. И вот право на выполнение этой функции тоже выдано этому менеджеру.
...
Рейтинг: 0 / 0
24.04.2006, 11:48
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685861
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelRПример, когда доступность данных зависит от функции:
Не зависит. Тут есть два разных набора данных:

- данные накладных
- общая сумма по накладным.

Второй доступен всем менеджерам, доступ к первому ограничен указанным правилом.

Почему это разные наборы данных: потому что они несводимы. "Любой менеджер" в этой постановке знает сумму по накладным, но не знает и не должен знать ее распределения по накладным. Будет ошибкой сказать, что ему доступно поле "сумма" из любой накладной - это дает ему излишние права.
...
Рейтинг: 0 / 0
24.04.2006, 12:23
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685962
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
?
Вводятся группировки. Группировка пользователей - это группа. Группировка функций - это роль.гм. У вас какое непонятная аппсолютизация группировок. (группировка у вас имеет объект, но не имеет измерения) А ием не меннее тут нужно измерение -

Группировка ведется по какому-то признаку. Иначе "группировка усеров" == "All". (то же и к иным группировкам). Если группировка усеров произведена по их функциональным возможностям, то чем она отличается от группировки функциональных возможносте по "группам допуска усеров" ?
...
Рейтинг: 0 / 0
24.04.2006, 12:52
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33685969
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
ссори за несопряжение конструкций. - редактировал и не вычитал.
...
Рейтинг: 0 / 0
24.04.2006, 12:54
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686017
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
ModelRСогласен скорее с ?
Пример, когда доступность данных зависит от функции:

Менеджер имеет право видеть только свои накладные и менеджеров по списку, управляемому администратором.
Менеджер имеет право получить информацию о доле стоимости своих накладных в общей сумме накладных.

И за какой дверью лежат накладные?Функции надо бить на части, чтобы не было такой проблемы. Набирать из этих частей пользовательские роли.

Еще можно скрестить парадигму ролей с традиционной парадигмой уровней доступа (общий-служебный-секретно...), но такой сильной травы у меня нет.
...
Рейтинг: 0 / 0
24.04.2006, 13:09
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686078
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> И тут все сразу становится сложно

Сложно становится чуть раньше, когда "есть множество объектов". Собственно, от контекста "объекта" и зависит сложность реализации.

> Группировка функций - это роль.

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

Относительно "танцев" и "целесообразности" - чуть позже.
...
Рейтинг: 0 / 0
24.04.2006, 13:27
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686102
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
guest_20040621Мне написать еще раз то же самое? В этом обсуждении упоминаются только и исключительно кастрированные варианты моделей ограничения доступа. Вы утверждаете, что этих кастрированных моделей для практического применения достаточно. Это не так.

Да приведите же наконец некастрированную модель. Или это просто стиль общения такой: сказать что-то не о чем?
...
Рейтинг: 0 / 0
24.04.2006, 13:38
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686111
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
iscrafm Да приведите же наконец некастрированную модель. Или это просто стиль общения такой: сказать что-то не о чем?Сейчас вас пошлют.
В пешее путешествие по букварям.
Но даже ссылок не дадут

это же бот, ежели вы не фкурсе
...
Рейтинг: 0 / 0
24.04.2006, 13:41
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686149
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
iamhereВообще говоря, это противоречивые правила.
Решать, видимо, надо так:
Общим правилом менеджеру разрешается видеть только свои накладные.
Специальная функция, с привелегированным доступом, позволяет посчитать эту самую долю, независимо от прав вызывающего менеджера. И вот право на выполнение этой функции тоже выдано этому менеджеру.Раз решение есть, значит непротиворечивые:).
softwarerПочему это разные наборы данных: потому что они несводимы. Э, как это не сводимы? Второй - в точности агрегат над первым. Можно даже не хранить. Разные они единственно в силу требований доступа.

Вообще отчеты - отдельная песня в доступе. Как ими рулить: писать запросы через систему доступа (создать кучу представлений, и раздать на них права) или наоборот, их самих считать объектами доступа, а запрос - напрямую, - для меня вопрос неоднозначный.
...
Рейтинг: 0 / 0
24.04.2006, 13:54
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686198
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Да приведите же наконец некастрированную модель.

Хм... Вы читать-то, надеюсь, умеете? Еще раз, для особо хм... непонятливых: RBAC плюс ACL плюс контекст. Вы от меня ddl ждете? Напрасно. Если интересно - ищите, google работает. Не интересно - не ищите, мне это проблем не создает. Просто воздержитесь от безграмотных заявлений, - этим Вы избавите себя от необходимости читать к ним комментарии.

> сказать что-то не о чем

Традиционный совет: больше читайте. Надеюсь, тогда стандартные шаблоны не будут вызывать у Вас столько вопросов.
...
Рейтинг: 0 / 0
24.04.2006, 14:06
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686220
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
Попробуем поточнее сформулировать. сразу оговорюсь, имеется ввиду объектно-ориентированный подход, в котором мы выделим экземпляр объекта, методы, которые к нему применимы (суть функции) и того, кто эти методы применяет (пользователя).
Теперь разберем по частям.
Что такое группа пользователей ни у кого сомнений нет - это множество пользователей. В некоторых системах группы могут быть вложены друг в друга, в некоторых системах жесткая одноуровневая иерархия, где-то вообще несколько фиксированных групп.
В тех системах, на которые я смотрю, группа функций - это роль. Ее вводят для того, чтобы не протыкивать десятки галочек на сотнях объектов, разрешая или запрещая одно и тоже. Чтобы была определенность, давайте договоримся, что функция - это некое значимое для нас действие над объектом (в зависимости от прикладной области): кнопка, нажимаемая пользователем, медод COM компонента, вызываемый контроллером автоматизации, выполняемое приложение и т.д.
Группа объектов в каждой системе выделяется по своим правилам: все записи таблицы, все таблицы одного владельца, все файлы данного каталога и т.д., все зависит от прикладной области.

В момент, когда пользователь "А" хочет применить функцию "Б" к набору данных "В", система должна понять, можно ему это или нельзя...
Как результат ей надо хранить множество разрешений или множество запрещений для того. чтобы иметь возможность вычислить функцию МОЖНО(А,Б,В).

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

Никто не отменял и другие варанты. существует масса вырожденных случаев, когда нецелесообразно выстраивать иерархию вдоль ребер куба (мало точек) или ребро вообще содержит только одно значение, или существуют вполне четкие методы вычисления функции МОЖНО, или функция МОЖНО зависит не только от трех рассмотренных выше параметров, и т.д.

Один из распространенных вариантов нарушения ортогональности этой системы - жесткое закрепление роли за предустановленной группой (системные администраторы, гости и т.д.) Если параллельно действует и полноценное назначение роли пользователю, начинает возникать путаница, куда добавляют пользователя в роль или в группу. На самом деле пользователя можно добавить только в группу пользователей. В случае с ролью Вы создаете связь роли и пользователя, таким образом заготавливая сразу несколько плоскостей функция-пользователь (в вышерассмотренном кубе) под соединение с объектом.
Другие варианты могут, например, не учитывать данные, давая или не давая пользователю право на исполнение некоей функции (запуск исполняемого файла, напрмер, да еще и с правами админа), полагаясь на то, что функция возьмет на себя часть забот системы разграничения прав.
Много может быть еще вариантов. Я продолжаю настаивать на том, что все в результате сводится к пляскам вокруг хранения, редактирования и выборки из объема функций-пользователей-объектов, а реализаций тут может быть масса, и каждая из них диктуется особенностями классификации и группировки сущностей вдоль каждого из ребер куба.
...
Рейтинг: 0 / 0
24.04.2006, 14:12
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686248
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
guest_20040621> Да приведите же наконец некастрированную модель.

Хм... Вы читать-то, надеюсь, умеете? Еще раз, для особо хм... непонятливых: RBAC плюс ACL плюс контекст.

iscrafmя говорю о ролевом доступе (RBAC, если Вы любите сановские абревиатуры), списках разрешенных точек доступа (ACL для любителей), которые в итоге предоставляют пользователю некий контент, а Вы мне в ответ - это чепуха, с аргументами в цикле. Определитесь и поговорим.
...
Рейтинг: 0 / 0
24.04.2006, 14:24
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686467
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
?Что такое группа пользователей ни у кого сомнений нет - это множество пользователей. +многабуков
множество ползателей - это "Олл".
множество ползателей с некими функциональными возможностями - это "рол"

иде промеж "Олл" и "рол" ваша круппа? (одна, мля, сама, мля, безансамля)

все кажется упирается в то, что при неирерахическом ведении групп приходится (удобно) вводить дополнительную сущность "рол", при этом группа владеет правами посредством приписанных ролей.
при иерархическом, а именно множественном (наследовании) прав группы от групп, можно наследовать (и перекрывать ?) права от разных групп не связываясь с избыточным посредником "роль" (они, "роли" т.е., тут становятся просто "более базовыми" группами). Нет?
...
Рейтинг: 0 / 0
24.04.2006, 15:18
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686505
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
4321при иерархическом, а именно множественном (наследовании) прав группы от групп, можно наследовать (и перекрывать ?) права от разных групп не связываясь с избыточным посредником "роль" (они, "роли" т.е., тут становятся просто "более базовыми" группами). Нет?Зависит от того, как определять роль. Если как "единый и неделимый" набор прав доступа, то иерархией тут не пахнет. Роль - это именно функция, выполняемая пользователем и доступная пользователю, и есть. Другое дело что технически она может включать в себя несколько каких-то "галочек", и смысл существования роли в некоторой степени будет и в том, чтобы думать в терминах 50 ролей, а не 200 галочек.
...
Рейтинг: 0 / 0
24.04.2006, 15:27
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686541
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
Dogen Зависит от того, как определять роль. Если как///я гдето говорю иначе? см. старый мой диалог со всовтварером. т.ч. неча мине моими же соображениями тыкать. просто утверждается "при ""иерархическом"" построении ролей, т.е.при возможности множественного наследования, нет надобности в дополнительной сущности" - такое построение вполне обслуживает ваше желание смотреть на конечную "роль" как на суперпозицию более простых ролей (, и быть может плюс еще 2-3 галки), а не как на 200 отдельных галок.
...
Рейтинг: 0 / 0
24.04.2006, 15:35
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686608
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> функция - это некое значимое для нас действие над объектом (в зависимости от прикладной области)

;) Опаньки... ну расскажите же скорее, что такое "значимое" действие, а что такое "незначимое"? Поясните, пожалуйста, почему вдруг какие-то действия зависят от предметной области?

> все записи таблицы, все таблицы одного владельца, все файлы данного каталога и т.д., все зависит
> от прикладной области.

Больший бред на sql.ru я читал только в авторстве ЧАЛа.
...
Рейтинг: 0 / 0
24.04.2006, 15:54
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33686905
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
4321 ?Что такое группа пользователей ни у кого сомнений нет - это множество пользователей. +многабуков
множество ползателей - это "Олл".
множество ползателей с некими функциональными возможностями - это "рол"

иде промеж "Олл" и "рол" ваша круппа? (одна, мля, сама, мля, безансамля)

все кажется упирается в то, что при неирерахическом ведении групп приходится (удобно) вводить дополнительную сущность "рол", при этом группа владеет правами посредством приписанных ролей.
при иерархическом, а именно множественном (наследовании) прав группы от групп, можно наследовать (и перекрывать ?) права от разных групп не связываясь с избыточным посредником "роль" (они, "роли" т.е., тут становятся просто "более базовыми" группами). Нет?Разница в том, что наследуется по иерархии. Наследовать можно и пользователей, и права на функции.
Группы, наследующие пользователей суть группы пользователей.
Группы, наследующие функции и права суть роли.
Группы, наследующие только функциии - группы функций однако.
Применяется же и такое:
User --< UG >-- UGroup --< UGFGPrivelege >-- FGroup --< FG >-- Function,
UGFGPrivelege >-- PrivelegeType

Посколько все это исключительно ради экономии крестиков-ноликов, то не знаю, есть ли универсальный рецепт.
...
Рейтинг: 0 / 0
24.04.2006, 17:22
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687004
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelRЭ, как это не сводимы? Второй - в точности агрегат над первым. Можно даже не хранить. Разные они единственно в силу требований доступа.
Не стоит черезчур рано спускаться на физический уровень (хранить - не хранить).

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

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

ModelRВообще отчеты - отдельная песня в доступе. Как ими рулить: писать запросы через систему доступа (создать кучу представлений, и раздать на них права) или наоборот, их самих считать объектами доступа, а запрос - напрямую, - для меня вопрос неоднозначный.
Хм. Это, собственно, вопрос в терминах Oracle - делать процедуру с AUTHID DEFINER или AUTHID CURRENT_USER. Наиболее частый ответ - нужно и то, и другое.

Практически с моей точки зрения первый вариант - дефолт, близкий к обязательному. Сами отчеты могут быть объектами доступа с точки зрения "нефиг выдавать пользователю список ненужных ему отчетов, которые все равно будут пустыми по данным", но "делать дырку в безопасности" особым отчетом - нужно редко и аккуратно.
...
Рейтинг: 0 / 0
24.04.2006, 17:50
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687046
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
ModelR Разница в том, что наследуется по иерархии. Наследовать можно и пользователей, и права на функции.
Группы, наследующие пользователей суть группы пользователей.
вот объясните мне, зачем нужны такие наследственные группы юзеров без каких либо привязанных к ним прав. наверное можно и так. прослоек в цепоке юзер - галочки можно навыдумывать много. в конце концов получим тот же результат: {юзер}->{множество галок}

вопрос думаецца стоит о минимальном наборе прослоек- абстракций, оставляющем умозрительно удобным способ ассоциации юзеров с правами. и видимо никакие группы "просто юзеров" тут не слишком нужны. вполне достаточно иметь иерархию (попросту говоря) "групп с правами", в которые и включать/исключать юзера. А "группа с правами" - это собсно роль (если там есть иерархия). Нет? Вот если нет гибкости в наследовании ролей ролью - то возникает необходимость в прослойке - имитаторе "базовых" или "собственно ролей" ("сложные роли" при этом набираются из них и являют собой "группы"), если наслеование есть - такой непреодолимой потребности нет. Вопрос опять таки в "интуитивной понятности" (которая кстати сказать может быть реализована не на уровне данных). Возможно при наличии разделения на роли и группы она _кажется_ более очевидной. Но так ли это "на самом деле"?
...
Рейтинг: 0 / 0
24.04.2006, 18:04
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687106
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
4321>множество ползателей - это "Олл".
Предлагаю вернуться к институтскому курсу теории множеств, чтобы не вводить аудиторию в заблуждение.
Роль - понятие нечеткое. Я предложил свою трактовку, если вам она не нравится, давайте для множества функций предложим другой термин, а роль возьмите себе.

4321>гм. У вас какое непонятная аппсолютизация группировок.
Во многих системах вы создаете группу и помещаете в нее произвольных пользователей, они не обязаны обладать никакими дополнительными признаками, кроме того, что вы выбрали их для данной группы.

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

guest_20040621>Больший бред на sql.ru я читал только в авторстве ЧАЛа.
Не надо читать бред, умеете писать лучше, пишите :)

ModelR> Группы, наследующие функции и права суть роли.
ModelR> Группы, наследующие только функциии - группы функций однако.
Почти готов согласиться, что ролью можно назвать группу функций, с проставленными правами выполнения, возможно, это даже вернее.
...
Рейтинг: 0 / 0
24.04.2006, 18:29
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687150
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
?4321>множество ползателей - это "Олл".
Предлагаю вернуться к институтскому курсу теории множеств, чтобы не вводить аудиторию в заблуждение.
вот токо ненада передергивать . вас как раз и просили привести измерение, по значениям которого приводится группировка в группы. И показать его отличие от "набора прав". Группировка без такого признака - группировка всех в одну кучу. надеюсь это понятно? Т.ч. отсылка к ТМ и ее курсу - тут риторический прием сомнительного св-ва.

?4321>гм. У вас какое непонятная аппсолютизация группировок.
Во многих системах вы создаете группу и помещаете в нее произвольных пользователей, они не обязаны обладать никакими дополнительными признаками, кроме того, что вы выбрали их для данной группы. я же не спрашиваю вас, как это нарисовано "во мн-ве систем". Я спрашиваю вас, для чего вводить эти группы, и каковы принципы группировки (чем одна группа отличаетс от другой). И, содержательно, кроме как набором прав - ничего в ответ не слышу (не слышу даже и этого). Если группы для наследования прав от ролей - то все это реализуется внутри однородной ирархии ролей - и группы не нужны.
Если же есть соображения на предмет большей (интуитивной) ясности системы из кучи (почти) дублирующих по сути сущностей - т.е. и групп и ролей - то хотелось бы их выслушать.
...
Рейтинг: 0 / 0
24.04.2006, 18:49
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687172
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Не надо читать бред

Может, лучше его не писать?

> умеете писать лучше, пишите

В данном случае писать не о чем: все миллион раз разжевано, реализовано и описано. Hint: google работает.
...
Рейтинг: 0 / 0
24.04.2006, 19:10
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687218
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
>4321
Никто не спорит, что группы создаются, чтобы соединить с ролью или сразу с правами. Но группа - это группировка пользователей. а роль - это группировка полномочий. Всем понятно, что можно обойтись и без групп пользователей и без ролей и каждое атомарное полномочие сношать с каждым пользователем. Но чтобы упростить себе задачу вводят или то или другое или и то и другое (а более общего случая я не встречал).
А по поводу, для чего и то и другое: попробуйте предоставить роль читателя всем пользователям(к примеру, 100 галочек), когда группы ALL у вас нет, но есть иерархия ролей. И попробуйте предоставить пяти группам пользователей по 50 различных атомарных полномочий (5*50=250 галочек), когда нет объединения ролей в группы. Обычно сверхгибкими структурами не увлекаются. Если есть гибкая иерархия групп, то иерархия ролей чаще всего зафиксирована и не подлежит расширению.

guest_20040621> Hint: google работает.
Hint: читайте google.
...
Рейтинг: 0 / 0
24.04.2006, 19:54
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687916
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
?>4321
Никто не спорит, что группы создаются, чтобы соединить с ролью или сразу с правами. Но группа - это группировка пользователей. а роль - это группировка полномочий.нувот, апять! группировка у вас производится на множестве, но признак группировки вы не указываете. На что я вам все время намекаю. (оторвались вы от реалий, аппсалютизируя группировки без какого либо измерения по которому ведецца группировка)

ессли группы только для того, шобы пал на мочи я, то сталабыть группы эти сгрупированны па пал на мочи ям? не правда ли. Вот если группы созданы еще для чего-то - то да есть некий скрытый от нас мекханизм группировки йузеров в хруппы, и смысл хрупп от нас пусь и скрыт, но велико значицца имя эхо. И это осмысленное, но не осознанное образование йузеров мы ужо и помапим на роли. Если же группы лишь часть механизма разадчи полномочий, то группа в этом случае - это группировка пользователей по набору галочек. Далее смотрим - конкретный набор набор галочек у нас ассоциируецца с "ролью" (или объединением ролей).
Внимание, вапрос: "зачем нам пракладка, да исчо и без крылышков?" Что мешает закрепить йузера за ролью (ролями - через объединение ролей).

повторяю еще раз . три слоя оправданы при отсутствии множественного наследования в ролях (если нельзя создать роль, как объединение других ролей). При наличии такого механизма наследования третий слой не нужен.
...
Рейтинг: 0 / 0
25.04.2006, 10:33
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33687957
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
добавлю факк-ультативно:
шо мешает вам создать роль All для вашего, ...., примера? Чем оно буит оличацца от хруппы All? тильки тем, шо панадабицца дапалнительный интерфейз?
...
Рейтинг: 0 / 0
25.04.2006, 10:44
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33688039
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
Если вам удобнее называть группу пользователей ролью, на здоровье, суть от этого не изменится. Предлагаю не спорить больше об этом.
...
Рейтинг: 0 / 0
25.04.2006, 11:04
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33688093
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
?Если вам удобнее называть группу пользователей ролью, на здоровье, суть от этого не изменится. Предлагаю не спорить больше об этом.нет, мне савсем неудобна "называть группу ползателей-ролью". Мне удобно заметить, что вполне достаточно приписать йузеру роль, и нет надобности в прокладках, если "группа" создаёцца лишь в целях объединения палнамочий и ничем не отличаецца от роли. Я и не спорю. Я спрашиваю - зачем (исчо) нужно три абстракции вместо двух.
Фполне допускаю, чтаа причина (терх абстракций), ускользающая от нашего с вами внимания есь. Тока вот, здаецца мне, она завсим не ф том, шо шо-то -хруппировка йузерофф, не-пойми-почём, а чо-та друхое - хруппировка фукций-не-пайми-па-ком. Хателось бы заслушать гаспод в нах-ся в третьей пазиции крутых хуру, но жаль - боты не побалують нас своими откровениями.
...
Рейтинг: 0 / 0
25.04.2006, 11:15
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33688485
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
softwarer ModelRЭ, как это не сводимы? Второй - в точности агрегат над первым. Можно даже не хранить. Разные они единственно в силу требований доступа.
Не стоит черезчур рано спускаться на физический уровень (хранить - не хранить).

В логической модели в данном случае есть две принципиально разных сущности: "детализированная информация по моим накладным" и "сумма по чужим накладным" либо "сумма по всем накладным" - как удобнее. Сущности, как видите, независимые и не то чтобы пересекающиеся.
Если бы не проблема доступа, не вижу смысла вторую сущность вводить в логическую модель. Как не вводят туда все мыслимые запросы. Ее также нет смысла вводить, если право дается на отчет. Отчет тогда считается частью системы, и использует сырые незащищенные данные. Нет?
...
Рейтинг: 0 / 0
25.04.2006, 12:32
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33688560
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
ModelRесли право дается на отчет. Отчет тогда считается частью системы, и использует сырые незащищенные данные. Нет?
Да, право дается группе=роли пользователей на запуск отчета с определенными параметрами. Т.о. разные роли получат один и тот же отчет но разного содержания.
...
Рейтинг: 0 / 0
25.04.2006, 12:48
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33688847
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
Если у человека есть доступ к отчетности по счету расчетов с покупателями, и доступ к информации по конкретному подмножеству покупателей, что ему следует показать в оборотно-сальдовой ведомости по упомянутому счету?


===============================================================================
Отвечать без смысла на это письмо. Сообщение направлено вам роботом доски объявлений.
...
Рейтинг: 0 / 0
25.04.2006, 14:06
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33689058
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
DogenЕсли у человека есть доступ к отчетности по счету расчетов с покупателями, и доступ к информации по конкретному подмножеству покупателей, что ему следует показать в оборотно-сальдовой ведомости по упомянутому счету?

Параметр отчета-группа покупателей
Содержание - только аналитические счета этих покупателей, т.е. только часть всего счета.
Так, наверное
...
Рейтинг: 0 / 0
25.04.2006, 15:06
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33689628
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
мод DogenЕсли у человека есть доступ к отчетности по счету расчетов с покупателями, и доступ к информации , что ему следует показать в оборотно-сальдовой ведомости по упомянутому счету?

Параметр отчета-группа покупателей
Содержание - только аналитические счета этих покупателей, т.е. только часть всего счета.
Так, наверное
Дык, можно понимать и наоборот, что право на отчет перекрывает ограничение на доступ по конкретному подмножеству покупателей. Мутное короче это дело.
...
Рейтинг: 0 / 0
25.04.2006, 17:27
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33689639
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
Я думаю, что конкретно показывать в отчете, должен сказать заказчик при сборе требований. По тому, что сделать можно и так, что пользователь не имеет права знать о существовании объектов на которые у него нет соответствующих прав, тогда он не должен их видеть в любых производных выборках, а может быть так, что он не может видеть объекты там, где сказано, а в отчетах - на здоровье. Все идет от требований, а абстрактно правильных вещей не бывает...
...
Рейтинг: 0 / 0
25.04.2006, 17:31
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33689648
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
ModelR
Дык, можно понимать и наоборот, что право на отчет перекрывает ограничение на доступ по конкретному подмножеству покупателей. Мутное короче это дело.
Да, надо построить модель и следовать ей, чтобы правила были понятны всем.
...
Рейтинг: 0 / 0
25.04.2006, 17:33
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33689731
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelRЕсли бы не проблема доступа, не вижу смысла вторую сущность вводить в логическую модель.
Согласен. Я даже не настаиваю на ее формальном введении. Тем не менее, если мы ставим задачу именно с ограничением доступа - формально должны будем сделать именно так.

Имхо ситуация такова: есть некий формализованный процесс разработки. Любой нормальный человек приспосабливает его к ситуации, в том числе убирая ненужные в данном случае формальности. Однако при этом стоит таки "держать в уме" то, что не сочли нужным записывать на бумаге. Не факт, что я нарисую в ER-ке такую вот суммарную вьюху, но имхо действовать следует так, как если бы она была нарисована; по крайней мере - не противоречить явно. Иначе получится уже "напрасно отменили эти формальности".

ModelRЕе также нет смысла вводить, если право дается на отчет. Отчет тогда считается частью системы, и использует сырые незащищенные данные. Нет?
Нет. Такой подход означает следующее: вместо того, чтобы реализовать защиту в одном месте, она заново реализуется в каждом отчете. Этот подход имеет все минусы копирования кода по сравнению с выделением стандартных подпрограмм. Достаточно подумать о цене тестирования - одно дело протестировать вьюху, не дает ли она кому-либо из двадцати пользователей лишней информации, другое дело - протестировать сотню отчетов, не дает ли он кому-либо из двадцати пользователей лишней информации. Если мы говорим о защищенной информации.... лично я просто не назову "защитой" то, что программист или постановщик может нарушить элементарной рассеянностью.

Поэтому я полагаю что первая часть - обязательна. Второй подход - возможен в порядке исключения в конкретном случае (конкретном отчете).
...
Рейтинг: 0 / 0
25.04.2006, 17:58
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33689831
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
2 softwarer
Конечно, написать код, разграничивающий доступ 1 раз вместо 20 - это очень хорошо, и здесь возражений нет.
Но не все так просто. Случаи, они разные бывают. Почти всегда, когда в систему закладывают ограничение доступа на уровне ядра, почти сразу за этим возникает требования предоставить функции запуска некоторых процедур с полномочиями, более высокими, чем есть у данного пользователя. Вот этот хитрый отчет, судя по всему, тоже так должен сделать: получить на время более высокие полномочия и выполнить обработку, самостоятельно реализуя функции защиты.
...
Рейтинг: 0 / 0
25.04.2006, 18:34
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33690561
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
softwarer- одно дело протестировать вьюху
1. К сожалению не всякий отчет сводится к вьюхе.
2. Ввод параметров всех отчетов реализуется одним набором процедур => проверка прав кодируется один раз.
3. Самое неправильное - это раздавать пользователям права на объекты БД (таблицы, вью и пр.), пользователи про БД вообще не должны ничего знать, даже про ее существование.
...
Рейтинг: 0 / 0
26.04.2006, 09:36
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33690714
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
мод3. Самое неправильное - это раздавать пользователям права на объекты БД (таблицы, вью и пр.), пользователи про БД вообще не должны ничего знать, даже про ее существование.
+1

добавлю: и администратор системы, раздающий доступ, тоже
...
Рейтинг: 0 / 0
26.04.2006, 10:25
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33691454
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
?Почти всегда, когда в систему закладывают ограничение доступа на уровне ядра, почти сразу за этим возникает требования предоставить функции запуска некоторых процедур с полномочиями, более высокими, чем есть у данного пользователя.
Безусловно, возникают. Именно такой случай мы и рассматриваем. Мое утверждение: такие случаи в целом обусловлены недостаточно хорошо выполненной постановкой задачи и недостаточно ответственным подходом к исправлению ошибок постановки.

Обратите внимание, как идет цепь рассуждений. Правильная (с моей точки зрения):

1. Определить объекты доступа и политику ограничений к ним (разная политика - разные объекты).
2. Спокойно работать.

В примере же с дополнительными полномочиями получается следующее:

1. Определить "вроде как один" объект.
2. Наткнуться на то, что невозможно посчитать требуемый отчет.
3. Родить простое и кривое решение - дополнительные полномочия отчета.

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

?Вот этот хитрый отчет, судя по всему, тоже так должен сделать:
Не "должен". Просто "постановщику лень подумать", и он находит "простой путь".

мод1. К сожалению не всякий отчет сводится к вьюхе.
Разумеется. Это просто удобное слово-упрощение. Можно читать "любой объект - источник данных".

Суть в том, что проверка прав должна кодироваться в одном месте, пока нет очень существенной причины отойти от этого правила.

мод2. Ввод параметров всех отчетов реализуется одним набором процедур => проверка прав кодируется один раз.
Это покрывает только простые случаи. Проверка прав не сводится к ограничению допустимого множества параметров, хотя согласен, это типовой вариант.

мод3. Самое неправильное - это раздавать пользователям права на объекты БД (таблицы, вью и пр.), пользователи про БД вообще не должны ничего знать, даже про ее существование.
Я не вижу логики в сказанном Вами и не думаю, что обсуждение этого будет полезным.

Впрочем, мне слегка интересно, каким образом работает пользователь, если он не имеет прав на процедуры, через которые "вводятся параметры отчетов".
...
Рейтинг: 0 / 0
26.04.2006, 13:08
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33691743
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
В практике все сводится к реализации требования "дать пользователю доступ к тому, с чем ему положено работать по должности".

Проблемы же возникают потому, что список того, "с чем положено", не всегда удается получить в достаточно формализованном виде.

Все-таки, как насчет выдачи прав в соответствии с уровнем допуска?..


===============================================================================
Отвечать без смысла на это письмо. Сообщение направлено вам роботом доски объявлений.
...
Рейтинг: 0 / 0
26.04.2006, 14:05
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33691874
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
softwarerВпрочем, мне слегка интересно, каким образом работает пользователь, если он не имеет прав на процедуры, через которые "вводятся параметры отчетов".
Я не раздаю права на процедуры. Грубо говоря, main может вызвать каждый, кто прошел авторизацию, дальше вызов пойдет по правам на функции программы. Если есть право на данный отчет, то процедуры ввода параметров вызовутся, а вот что через них можно ввести, определяется правами на данные.
...
Рейтинг: 0 / 0
26.04.2006, 14:31
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33692053
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
softwarer ?Почти всегда, когда в систему закладывают ограничение доступа на уровне ядра, почти сразу за этим возникает требования предоставить функции запуска некоторых процедур с полномочиями, более высокими, чем есть у данного пользователя.
Безусловно, возникают. Именно такой случай мы и рассматриваем. Мое утверждение: такие случаи в целом обусловлены недостаточно хорошо выполненной постановкой задачи и недостаточно ответственным подходом к исправлению ошибок постановки. Грамотные и продуманные на эн лет вперед постановки - это было бы прекрасно. Но реально получится, что для нового отчета нужно переосмысливать ранее созданные представления, процедуры, создавать новые, отслеживать что в каком отчете используется, а также администратору возится с раздачей прав. Будет ли это надежней чем отладить отчет - вопрос...
softwarer мод1. К сожалению не всякий отчет сводится к вьюхе.
Разумеется. Это просто удобное слово-упрощение. Можно читать "любой объект - источник данных".И грань между отчетом и вьюхой стирается.

В общем одно место как-то все время расползается:( Хотя к идеалу стремиться конечно надо.
...
Рейтинг: 0 / 0
26.04.2006, 15:17
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33692164
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Самое неправильное - это раздавать пользователям права на объекты БД

Вам противопоказано проектирование. Займитесь чем-нибудь попроще.
...
Рейтинг: 0 / 0
26.04.2006, 15:44
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33692238
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621
Свои советы оставьте при себе. Аргументы будут ?
...
Рейтинг: 0 / 0
26.04.2006, 16:02
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33692868
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Аргументы будут ?

Нет.

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

Нельзя столь уверенно нести чушь.
...
Рейтинг: 0 / 0
26.04.2006, 19:41
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33694184
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelRГрамотные и продуманные на эн лет вперед постановки - это было бы прекрасно.
Но не является необходимым или хотя бы названным мной условием. Я нигде об этом не говорил и этого не подразумевал; предлагаю не уводить в сторону.

ModelRНо реально получится, что для нового отчета нужно переосмысливать ранее созданные
Вот это уже плохая постановка, плохо выполненное обследование. Ближе так: время от времени, при изменении бизнеса, нужно переосмысливать некую часть ранее сделанного. Нормальная и естественная задача сопровождения.

ModelRотслеживать что в каком отчете используется,
Нет. Это как раз при "отчетной" модели придется что-то отслеживать. Если права обрезают источники данных - на отчеты становится глубоко наплевать. Можно сотворить хоть тысячу отчетов, можно дать пользователю конструктор отчетов - все равно до скрытых от него данных он не доберется. И программист по рассеянности их ему не откроет.

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

ModelRБудет ли это надежней чем отладить отчет - вопрос...
Отладить один источник данных заведомо надежнее, чем отладить N отчетов.

ModelRИ грань между отчетом и вьюхой стирается.
Непринципиально в данном случае. Отчет - это не источник данных; это в общем случае форма представления дополнительно обработанных данных из нескольких источников. Его можно рассматривать как вторичный источник данных, но в силу вторичности - данные в отчете специфически обрабатываются и фильтруются - у него мал коэффициент повторного использования.

Конечно, можно все на свете обозвать отчетом, но это сугубое теоретизирование.

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

ModelRВ общем одно место как-то все время расползается
Хм. Скажем так, по моим ощущениям расползаться склонно то, что сделано не на месте. Например, если изначально в одной подпрограмме сделали то, что надо было разделить на три - велика вероятность того, что треть ее кода захочется откопировать в другое место. Но правильным будет - выделить подпрограмму.
...
Рейтинг: 0 / 0
27.04.2006, 13:05
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33694275
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
модЯ не раздаю права на процедуры.
В контексте дальнейшего я скорее понимаю это как "я каждому даю права на все процедуры".

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

модЕсли есть право на данный отчет, то процедуры ввода параметров вызовутся, а вот что через них можно ввести, определяется правами на данные.
То есть, если я правильно понимаю, я беру старый-добрый SQL*Plus, подключаюсь к БД, чихая на все права на отчеты, запускаю "процедуры ввода параметров", и остается надеяться на то, что уж они-то не пустят меня к чужим данным.

Не вижу в этой схеме ничего правильного.
...
Рейтинг: 0 / 0
27.04.2006, 13:24
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33695035
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
softwarerя беру старый-добрый SQL*Plus, подключаюсь к БД
Да, конечно, если пользователи могут прямо ходить в БД, то от них надо защищаться, раздавать права. При большом числе объектов БД это трудоемко. Проще, наверное, вообще лишить их всяких прав. Т.е. работать можно только через прикладнуху.
...
Рейтинг: 0 / 0
27.04.2006, 16:10
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33695163
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторПри большом числе объектов БД это трудоемко.
Если правильно сделать систему раздачи прав - нисколько не трудоемко. Несколько взмахов мышой и нажатий на клаву не такой уж большой труд :))

Не могу прокомментировать остальное - пытался следить за топиком, но не смог :)) Теперь уже не понять, что тут :)

По правам вообще - сейчас у нас система прав следующая: есть юзеры - они и логины sql-сервера и прикладные юзеры системы, есть группы юзеров - только прикладные группы, на группу выдаются права на визуальные объекты системы (формы, меню и т.д.) и на запуск ХП (кроме ХП больше ничего). Также есть ограничения бизнес-логики по юзерам или группам.
Чего бы изменить хотелось - группы иметь ролями сервера, тогда перегрантовывать права на каждую процедуру каждому юзеру не нужно, права выдаются один раз на роль. Ну и объекты, на которые действуют права, объединить логически в более обобщенные и уже на них прописывать права через софтину (проще получится админу)
Остальное удовлетворяет вроде пока.

-- Tygra's --
...
Рейтинг: 0 / 0
27.04.2006, 16:38
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33698756
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
модДа, конечно, если пользователи могут прямо ходить в БД, то от них надо защищаться, раздавать права.
OK.

модПри большом числе объектов БД это трудоемко.
Не сказал бы. Раздача прав на один объект малозаметна на фоне разработки и тестирования этого одного объекта. Трудоемко - если сначала сделали кучу всего чер-те-как, а потом подумали, не раздать ли права.

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

1) Был надежен на уровне более чем "тупые пользователи"
2) Не обладал бы куда более существенными минусами, нежели стоимость раздачи прав.

Кроме того, такая постановка вопроса живет ровно до первого интеграционного проекта - когда начинается "а вот мы хотим подключаться к этой БД нашим генератором отчетов", или "мы хотим брать эти справочники для репликации в другую ИС" итп.
...
Рейтинг: 0 / 0
29.04.2006, 00:40
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33698940
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>softwarer
>"а вот мы хотим подключаться к этой БД нашим генератором отчетов" ...

Вы правы на 100%, такая постановка вопроса неизбежна допустима.
Но от этой неизбежности становится как-то не по-себе - создаешь, холишь-лелеешь свои, "идеальные", схемы ограничения доступа, и тут по ним, как серпом по ...

От мысли, что конечный пользователь будет лазить по таблицам, строить Select, генерить выборку ... мне делается дурно.

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

Может и не прав.

С уважением, Владимир.
...
Рейтинг: 0 / 0
29.04.2006, 12:30
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33699042
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ВМоисеевНо от этой неизбежности становится как-то не по-себе - создаешь, холишь-лелеешь свои, "идеальные", схемы ограничения доступа, и тут по ним, как серпом по ...

От мысли, что конечный пользователь будет лазить по таблицам, строить Select, генерить выборку ... мне делается дурно.
И зачем же идти на такие жертвы? Неужели Вы полагаете дурноту по утрам нормальным состоянием программиста после хорошей работы?

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

ВМоисеевНепреднамеренно становишься в позу - только дополнительная функция для СП,
И любой стандартный софт, тот же Crystal Reports, оказывается обязанным уметь работать с Вашим СП. Я бы не назвал такую позицию излишне конструктивной :)

ВМоисеев - она анализирует клиентские параметры, создает что нужно, запускает генератор отчетов, результаты получает в файл, сжимает его, шифрует и по частям - клиенту.
А как действовать, если хочется половину данных - из одной БД, другую половину - из другой?

ВМоисеевПонимаю, что это идилия, но не хочу допускать конечного клиента до схем базы данных, - как какой-то выключатель сидит внутри.
Хм. Я бы не хотел детально расписывать причины, по которым так считаю, но в целом мне это кажется очередной инкарнацией того, что я называю "эскалацией кривизны". Это "не хочется" обусловлено неудачным решением, принятым на более ранней стадии.

Данные программы в большинстве случаев обладают собственной ценностью, не зависящей от ценности программы. Скажем, я однажды был очень приятно удивлен. Среди моих проектов значится некая ГИС для Московской Сотовой - там мне удалось добиться очень удобного отображения информации. Так вот, однажды, приехав к ним, я увидел на стене изображение примерно два на два с половиной метра - явно сделанное из моей карты. Как оказалось, они построили уровни с дополнительной информацией (не обрабатывавшейся у меня), подключили их в мою программу как фон и распечатали на плоттере - именно чтобы иметь на стене нужную им удобную карту Московской области.

Из этого следует естественное желание получать эти данные и следует некорректность их инкапсуляции в программу, оценки их как приватных. И как ни крути, но Ваша программа вовсе не обязана быть пупом Земли и центром мироздания, и "функция для Вашего СП" - ничуть не более правильное решение, нежели "функция какой-нибудь другой программы".
...
Рейтинг: 0 / 0
29.04.2006, 14:13
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33699419
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>softwarer
>... и любому пользователю, который лазит по таблицам, ...

На каком-то этапе развития (саморазвития?) отказался от мысли представлять конечному клиенту схему базы данных - названия таблиц, их структура, хранимые процедуры и прочая, прочая ... - сиё табу для конечного клиента (это сугубо моё мнение). Никакой такой самостоятельности - только функции СП и их параметры доступны ему. Его разумные и естественные пожелания находят (должны находить) своё отражение в ТЗ ( сами понимаете, желание, но реальность - увы), или в обучении его программистов навыкам работы с поставленным ПО.
Возможности СП по доступе к данных значительно превосходят аналогичные возможности конечного клиента. СП может посчитать и представить некоторые интегральные величины, конечному клиенты в принципе не доступные. Так, например, на хим. комбинатах есть особые производства, а пар готовит одна ТЭЦ, а на входе производства счетчика нет, есть только по участкам - а эта информация не доступна диспетчеру ТЭЦ, он знает только производство.

> И любой стандартный софт, тот же Crystal Reports ...
Crystal Reports запускается в среде СП.

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

Относительно карты - поздравляю и Вас и тех ребят, кто её сделал.

С уважением, Владимир.
...
Рейтинг: 0 / 0
29.04.2006, 23:44
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33700299
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ВМоисеевНа каком-то этапе развития (саморазвития?) отказался от мысли представлять конечному клиенту схему базы данных - названия таблиц, их структура, хранимые процедуры и прочая, прочая ... - сиё табу для конечного клиента (это сугубо моё мнение).
Могу Вас заверить, что ИТ-специалисты клиента обладают заведомо другим мнением на этот счет. Если кратко, оно будет сформулировано примерно так: "И эти криворукие ламеры еще пытаются помешать нам хоть как-то эксплуатировать это угробище".

ВМоисеевНикакой такой самостоятельности - только функции СП и их параметры доступны ему.
См. выше. Это просто существенно снижает практическую ценность такой программы.

ВМоисеевЕго разумные и естественные пожелания находят (должны находить) своё отражение в ТЗ
Это называется "подсаживать на поддержку". Требования склонны меняться с течением времени. Либо мы даем пользователю возможность решать некоторые задачи своими силами, либо заставляем по любому чиху бежать к нам. Второе, возможно, финансово выгоднее.... но по понятным соображениям пользователю больше нравится первое.

ВМоисеев ( сами понимаете, желание, но реальность - увы), или в обучении его программистов навыкам работы с поставленным ПО.
Это очень деликатная формулировка, далекая от реальности. Ближе будет "искать способы обойти реализацию ПО".

ВМоисеевВозможности СП по доступе к данных значительно превосходят аналогичные возможности конечного клиента. СП может посчитать и представить некоторые интегральные величины, конечному клиенты в принципе не доступные.
Ээ... судя по всему, Вы утверждаете, что в нашем мире существует магия.

ВМоисеевТак, например, на хим. комбинатах есть особые производства, а пар готовит одна ТЭЦ, а на входе производства счетчика нет, есть только по участкам - а эта информация не доступна диспетчеру ТЭЦ, он знает только производство.
Не понял, чем страшна эта схема и что ей дает СП.

ВМоисеев> И любой стандартный софт, тот же Crystal Reports ...
Crystal Reports запускается в среде СП.
Вы снова выпячиваете свой СП пупом земли. В то время как в нормальной фирме он будет одним из нескольких (или нескольких десятков) эксплуатируемых приложений. И мне, в рамках реализации проекта, допустим "сводная отчетность о деятельности предприятия" нафиг не интересна возможность запускать CR из среды малоинтересного мне СП. Мне нужно запустить CR и сосать в него данные из двух десятков приложений.

ВМоисеевВ информационных системах, мною разрабатываемых, клиент подключается и через Интернет. Не знаю как решить эту задачу - через инет к одной базе данных, локально к другой и суммарно данные в один отчет. Подобную задачу не решал.
Да и не обязательно именно так. Просто представьте себе, что на предприятии стоит Ваша система, и стоит еще чья-либо, реализованная в такой же архитектуре и для интересности картины - на полностью другой технологической базе. Вопрос: как мне построить отчет над данными обеих систем?
...
Рейтинг: 0 / 0
01.05.2006, 15:48
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33700410
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>softwarer
>Могу Вас заверить, что ИТ-специалисты ...
>... существенно снижает практическую ценность такой программы ...
>Требования склонны меняться ...

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

> ... в нашем мире существует магия.
Да, нет все значительно прозаичнее. Конечный пользователь, в данном случае диспетчер, не имеет доступа к соответствующим записям базы данных.
СП имеет, у него свои полномочия и они не тождественны полномочиям текущего клиента.
Конечный пользователь и понятия не имеет к каким таблицам и хранимым процедурам имеет доступ СП, и как он строит SELECT-ы.

>Вы снова выпячиваете свой СП пупом земли. ...

Да нет же.
Есть некоторая теория (СП). Есть конкретная задача (Отчет из двух серверов данных).
Как же не использовать этот оселок для доводки теории?.
Хотя СП далеко не универсальный метод, но многие задачи им решить можно . Если Вы можете запустить отчет на рабочей станции, то что мешает запустить его на сервере приложений.
Ограничение: создать программу запуска и её отладить должен специалист IT.

С уважением, Владимир.
...
Рейтинг: 0 / 0
01.05.2006, 18:52
| Ответить | Цитировать | Написать  
Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
    #33700935
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
softwarer
Интеграция и права доступа - вопрос действительно интересный. Но есть стандартный подход - создание собственных подсхем, вью и синонимов. Внешнее приложение подключается к своей подсхеме и видит только то что ему разрешено видеть. Суть проблемы здесь в том разные приложения могут иметь разные системы прав доступа, которые и вступают в конфликт.
...
Рейтинг: 0 / 0
02.05.2006, 10:13
| Ответить | Цитировать | Написать  
106 сообщений из 106, показаны все 5 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Распределение прав доступа в клиент-серверных приложениях. Сравнение подходов.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1545286]:
 0ms
get settings:
 8ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 150ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 81ms
get tp. blocked users:
 1ms
others: 205ms
total:  468ms
созд. / загр.: 468ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]