• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Нужна помощь

  • Автор темы susinmn
  • Дата начала
S

susinmn

Есть бд и доки, в которых есть поле регион


Необходимо заказчице сделать Справочник сотрудников
далее ее слова...
*В «Справочник сотрудников» предназначен для ввода сотрудников по регионам.
Право на просмотр и редактирование(документов в бд) сотрудникам должен зависимость от региона, в котором сотрудник будет прописан.

Так же необходимо предусмотреть, возможность заведения сотрудников в «корневой каталог», которые будут иметь доступ ко всем документам в БД. *
Мое решение: в каждый документ в Authors добавлять роль "[Регион(тот или иной)]", в адресной книге создавать програмно после создания нового региона группу с именем Региона+в ACL нужно добавлять роль(для этого же нужно быть манагером), а этим справочником будет служить группы из адресной книжке+ и добавлять она(они) будут туда LNAddress*а

Напишите пожалуйста, если есть, свое красивое решение этой задачи

P.S.: что то на русский язык на сайте не переключается, приходится текст в тему копировать...((
 
A

Akupaka

твое решение не корректное...
на ролях это нельзя организовывать. это надо организовывать на полных точных notes-именах, либо на псевдо-группах */someregion/someorg/CO
 
S

susinmn

Как?
В адресной книге группа(назовем XXX) Multi-purpose с LN-Адресами. В ACL эта же группа(XXX как Person group) с ролью [XXX], а в документах региона XXX а поле Authors типа Authors прописываем .....:"[XXX]"
 
R

RAJ

я реализовывал на ролях - полёт нормальный
 
A

Akupaka

в том, что роли так использовать не удобно.
админы постоянно должны следить за изменениями структуры (наличия регионов) и править ТУД, хотя в правильно-организованном приложении этого лучше избегать.
кроме того, кол-во ролей ограничего (в 6-ке - 75, в других не знаю).
кроме того, использование групп для доступа плохо, если предполагается использование локальных реплик - они могут не работать.

для подобных задач лучше всего организовать правильную иерархическую структуру имен и использовать ее. она работает всегда, на сколько мне известно...
имхо :) т.е. другие рабочие варианты возможны, это мое мнение на счет именно решения в 1,3-м посте.
 
R

RAJ

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

да, это справедливо.
Роли и группы не работают в локальной реплике, если в ACL базе не установлен флаг "Enforce a consistent ACL across all replicas"
 
S

susinmn

А что за псевдо-группы?
Есть ли help?
 
A

Akupaka

группы в локальной реплике не по этому не работают.


псевдо-группы - это часть нотес-имени, вернее иерархии, но вместо имени пользователя стоит звездочка
*/SomeRegion/SomeOrganization
т.е. любой пользователь у которого иерархическая часть = /SomeRegion/SomeOrganization будет входить в эту группу.
таким образом, если в организации правильно создана структура на сервере, то это не только удобный, но и мощьный инструмент управления доступом!
 
S

susinmn

С иерархией LNAddress*ов не получится, потому что она идет по департаментам (

если без ролей, а только с группами?

В адресной книге группа(назовем XXX) Multi-purpose с LN-Адресами. А в документах региона XXX а поле Authors типа Authors прописываем .....:"XXX"
 

Cleric-Lviv

Well-known member
03.01.2008
603
0
BIT
0
susinmn


смотрите делаете форму на форме 3 поля
1. назва региона
2. поле типу неймс оператори региона
3. администратор региона

далее, юзер делает заявку, поле авторс, дальше поле в котором отмечени оператори регеина. операторов достаем через @DbLookup, все доку видят только оператори даного региона, и сам автор , + есть еще поле в котором есть администратор региона тоже достаем через @DbLookup

вот и решение, удобно ненадо ролей, администратор бази может бистро опредилить кто к какому региону относится
 
A

Akupaka

С иерархией LNAddress*ов не получится, потому что она идет по департаментам
т.е. один и тот же департаметн в разных регионах имеет одну и ту же иерархию? О.о

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

RAJ

susinmn


смотрите делаете форму на форме 3 поля
1. назва региона
2. поле типу неймс оператори региона
3. администратор региона

далее, юзер делает заявку, поле авторс, дальше поле в котором отмечени оператори регеина. операторов достаем через @DbLookup, все доку видят только оператори даного региона, и сам автор , + есть еще поле в котором есть администратор региона тоже достаем через @DbLookup

вот и решение, удобно ненадо ролей, администратор бази может бистро опредилить кто к какому региону относится
Cleric-Lviv
а если добавляются "операторы региона", то старые доки они не увидят :)

Если у каждого региона свой сервер - пишите просто формулы репликации по названию региона,
тогда на сервак региона поступят только его документы
 

Cleric-Lviv

Well-known member
03.01.2008
603
0
BIT
0
Cleric-Lviv
а если добавляются "операторы региона", то старые доки они не увидят

да тут я с вами полностю согласен......но ето можна исправить посредством ролей.......хотя и геморойно...
 
A

Akupaka

но ето можна исправить посредством ролей
мы тут придумываем как от них ихбавиться ;)

susinmn, в общем, я свою точку зрения выдал... можешь подождать день-два, тут еще пара мастодонтов бегает на этот форум, может кто более толковую мыслю подскажет... :)
 
S

susinmn

Может что-то с Embedded View и Show Single Category придумать? но они хотят что бы некоторые люди видели все доки=(
 
A

Akupaka

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

внедренные виды и т.п. не в ту степь, по-моему...
 
S

susinmn

Скажем так. При входе в бд отображаем форму с табличкой(Show only one row at a time и Users pick row via tab buttons) в первой закладке Embedded View и Show Single Category(получаем по @UserName регион, если он один то показываем закладку и доки этого региона, если их много, то скрываем) вторая закладка все доки(по @username получаем, что ему позволено все видеть и показываем эту закладку, а первую скрываем) а в доках пишем, что их видят и равят все...опасно, но хоть что то толковое.
Не хочу писать агента, который будет бегать вечером по докам и в них прописывать LNAdress*а

To Akupaka


Есть босы, им нужно видеть все.
Всего серваков 2, они на них работают в терминале+есть московкие серваки, на них тоже есть реплика бд
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!