|
|
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
Коллеги, у кого нить есть готовая модель ведения пользователей, груп пользователей и разграничение прав на объекты ПО(Права на приложение,оконо, вкладки, колонки ) между ползьзователями и группами. Пришлите пожалуйста, а то не хочется изобретать велосипед. спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 15:00 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
Посмотрите в сторону csrc.nist.gov/rbac/ ну и собственно гугл по аббревиатуре rbac в помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 16:07 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
А на русском нет ничего?а то там не очень понятно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 16:29 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
vovan_zПрава на приложение,оконо, вкладки, колонки + данные во всем своем разнообразии с точностью до строк vovan_zне хочется изобретать велосипед Придется :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 17:38 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
_модданные во всем своем разнообразии с точностью до строк Глобальное позаписное разграничение прав доступа (а нормальное оно может быть только в том случае, если автор/владелец любой записи в любой таблице сам может в рамках своих полномочий раздавать полномочия на эту самую запись, ей дочерние и т.п.) вообще мало где есть. Это, во-первых, совсем не "велосипед", а, во-вторых, выходит за рамки заявленного автором "разграничения прав на объекты ПО". Так что я бы не стал пугать автора недвусмысленными намеками "с точностью до строк". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 09:50 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов _модданные во всем своем разнообразии с точностью до строк Глобальное позаписное разграничение прав доступа (а нормальное оно может быть только в том случае, если автор/владелец любой записи в любой таблице сам может в рамках своих полномочий раздавать полномочия на эту самую запись, ей дочерние и т.п.) вообще мало где есть. Именно в такой реализации (пользователь права раздает) иало где есть не только потому, что реализовать тяжело, а потому что пользователю своей работы хватает. А права раздавать это дополнительные затраты времени, да плюс еще же и думать(!) нужно. Нафиг-нафиг! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 10:23 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
474А права раздавать это дополнительные затраты времени, да плюс еще же и думать(!) нужно. Нафиг-нафиг! :) Традиционная концепция автоматической установки значения маркера безопасности по умолчанию с возможностью при необходимости подумать и (в хитрозаумных случаях, опять же в рамках полномочий) указать другие полномочия на запись спасает от пользователей, не желающих думать. Многие юзеры у нас даже не знают о такой возможности, даже, наверное, большинство :) Но кровушки это попило, что верно, то верно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 10:48 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
474 Именно в такой реализации (пользователь права раздает) иало где есть не только потому, что реализовать тяжело, а потому что пользователю своей работы хватает. А права раздавать это дополнительные затраты времени, да плюс еще же и думать(!) нужно. Нафиг-нафиг! :) НЕ ПОНЯТНО!Объясните по другому. Я пранирую что все пользователи подключаются к базе по одному пользователю базы, а разгриничение прав происходит только в интрефесе программы вот такая получается схема из трех таблиц: Пользователи(users) user_id (PK) user_par_id (Для организации дерева, что бы если много пользователей их можно распихать по папкам, Ну и сделаю папку группы, в ней будут пользователи группы) pod_id (поразделение в котором раб пользователь) username password Наследование прав пользователей(пользователи в группах)(user_group) user_group_id (PK) user_par (FK на users.user_id) user_child (FK на users.user_id) права пользователей(rigths) rigths_id (PK) rights_cod (Символьный код права(объек в программе): наименование окна,наименование таблицы, наименование таблицы:имя поля) rights_type (тип права, на один объект может быть много прав(чтение,запись..)!Не знаю как лучше может сделать для каждого права одну колонку?) yes (0,1) (Разрешение права) Так мы можем сделать права на все обекты в программе. а как сделать вот например оргнизовать хранение прав фитра по строкам? вот наример есть у меня справочник внутренних фирм, и есть документы, в каждый документ прописана фирма, и вот мне надо каким то пользователям запретить видеть документы каких то фирм(и другие таблицы программе где есть эти фирмы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 11:03 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
поправка в правах пользователей(rigths) еще есть user_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 11:35 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
vovan_zНаследование прав пользователей(пользователи в группах)(user_group) user_group_id (PK) user_par (FK на users.user_id) user_child (FK на users.user_id) Я бы на Вашем месте делал сначала без наследования. Все равно иерархия пользователей просто делается в любое время потом. То есть, как обкатается решение - тогда уже и завитушки добавляйте. vovan_zвот наример есть у меня справочник внутренних фирм, и есть документы, в каждый документ прописана фирма, и вот мне надо каким то пользователям запретить видеть документы каких то фирм(и другие таблицы программе где есть эти фирмы) Это как раз примерно то, о чем я писал, только в сильно усеченном объеме, без концепции владения и самостоятельного ручного редактирования прав. Также рекомендую это делать отдельно и после, причем сильно после, вообще после всего. Это крайне слабо связано с первым (с разграничением прав на "объекты ПО"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 11:57 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
vovan_zНе знаю как лучше может сделать для каждого права одну колонку?) Для каждого права одну колонку делать не интересно, так как разные по сути объекты могут разграничиваться принципиально разными правами и по качеству, и по количеству. Лучше все права (для объекта и юзера) хранить в одном поле. В этом случае потребуется "парсер" данного поля, причем, как для чтения прав из БД и натягивания их в приложении, так и для редактирования их при администрировании, то есть, в обоих направлениях. Фактически, для каждого типа объекта будет свой парсер, если будет хоть что-то сложнее просто управления enabled/disabed или visible/hidden. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 12:00 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовЭто как раз примерно то, о чем я писал, только в сильно усеченном объеме, без концепции владения и самостоятельного ручного редактирования прав. Также рекомендую это делать отдельно и после, причем сильно после, вообще после всего. Это крайне слабо связано с первым (с разграничением прав на "объекты ПО"). Я так понимаю что эти права раздаются в оболочке управления БД, насколько это удобно?!далеко не всегда есть доспут на правах адимнистратора на сервер. Получается что права на объекты задаются в программе а фильтры на строки задаются в другом месте совсем, да и пользователи везде разные могут быть?!Удобно ли это?!Может все права выдавать в интересфейсе программы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 12:43 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
vovan_z Не понял вопроса, если честно. Но попробую ответить 1. Делать или нет ОТДЕЛЬНУЮ программу для администрирования приложения - как хотите. Важно только обеспечить ограниченный доступ к функциям администрирования. Но вообще-то лучше, если администратор не имеет доступа к тому, что администрирует. Также лучше, если интерфейс администрирования будет унифицированный, но не обязательно в точности повторяющий интерфейс рабочего приложения. 2. Доступ для администрирования приложения может быть никак не связан с административным доступом на сервер БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 12:57 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов хорошо спрошу по другому. правильно ли я понимаю: 1. Фильтр по записям выполняется на уровне СУБД и приложение ничего не знает об этом? 2. Я так понимаю что пользователи и группы которые хранятся в табице users должны быть также пользователми СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 13:09 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
vovan_zФильтр по записям выполняется на уровне СУБД и приложение ничего не знает об этом? Есть разные подходы. Можно все ограничения учитывать во вьюхах или процедурах. Можно пользоваться встроенной в СУБД функциональностью, если таковая есть. Можно с клиента формировать запросы с ограничениями на записи. Зависит от множества факторов. Например, от необходимости видеть, что существуют записи, к которым нет доступа на чтение (например, в составе документа), то есть, что сработало ограничение. Также может быть необходима проверка на полномочия операций в триггерах. vovan_zЯ так понимаю что пользователи и группы которые хранятся в табице users должны быть также пользователми СУБД? Не обязательно. На юзеров БД можно раздавать права стандартно на уровне БД. Если Вам этого не надо, все могут и под одним юзером ходить, или под несколькими разными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 14:10 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовГлобальное позаписное разграничение прав доступа (а нормальное оно может быть только в том случае, если автор/владелец любой записи в любой таблице сам может в рамках своих полномочий раздавать полномочия на эту самую запись, ей дочерние и т.п.) Лучше все-таки администратор, и не на каждую запись, а на группы объектов. Сергей Васкецоввыходит за рамки заявленного автором "разграничения прав на объекты ПО" Дык ведь все равно придется делать рано или поздно, так лучше все придумать заранее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 16:32 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
_модДык ведь все равно придется делать рано или поздно, так лучше все придумать заранее. Отнюдь. Если, например, доступ ко всем счетам-фактурам идентичный, то разграничивать его по заголовкам этих документов смысла нет. Хотя, не скрою, удобства в плане администрирования это дает значительные, особенно в части редактирования справочников номенклатуры и контрагентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2008, 09:57 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовЕсли, например, доступ ко всем счетам-фактурам идентичный, то разграничивать его по заголовкам этих документов смысла нет. В основном так конечно и есть. Но в общем виде задачка может выглядеть так: Роль Р имеет может вводить СФ только от контрагентов типа К , т.е. права на одни объекты распространяются от прав на другие объекты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2008, 11:03 |
|
||
|
Модель прав пользователей
|
|||
|---|---|---|---|
|
#18+
авторавтор Рекомендую посмотреть эту ссылку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2008, 11:20 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=100&tid=1543732]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
2ms |
| others: | 215ms |
| total: | 392ms |

| 0 / 0 |
