Как защищать ЭДокумент?

[GROMILA]

Документ, как правило, состоит из 3-хчастей:
1. Рабочие поля для логики приложения (изменять могут все)
2. Реквизиты+Само тело ЭДокумента (изменять нельзя вообще - "топором не вырубишь", ну может админ только может)
3. Поля для хранения пользователей и их всяких состояний (каждый пользователь меняет только свои поля)

Защита желательна на уровне документа, а не на уровне UI-классов

Вопрос: Как это реализовать???

 

[GROMILA]

Про поля авторов и ридеров известно, но они действуют на документ в целом.

Требуется разграничить доступ к частям одного документа!!!!!

Секции не обеспечивают защиту на уровне документа!!!!


PS. Domino6, ивини, нечаянно удалил твое сообщение вместо своего.
Лотусовсткая привычка, что управляющие кнопари вверху.

 

[LNTek]

<!--QuoteBegin-GROMILA+8:06:2005, 20:02 -->
<span class="vbquote">(GROMILA @ 8:06:2005, 20:02 )</span><!--QuoteEBegin-->Про поля авторов и ридеров известно, но они действуют на документ в целом.

Требуется разграничить доступ к частям одного документа!!!!!

Секции не обеспечивают защиту на уровне документа!!!!
PS. Domino6, ивини, нечаянно удалил твое сообщение вместо своего.
Лотусовсткая привычка, что управляющие кнопари вверху.

[snapback]20809" rel="nofollow" target="_blank[/snapback]​

[/quote]

Для каждого поля можно задать группу пользователей из ACL, имеющую права чтения/редактирования/изменения/сохранения.

 

[Medevic]

<!--QuoteBegin-LNTek+8:06:2005, 22:28 -->
<span class="vbquote">(LNTek @ 8:06:2005, 22:28 )</span><!--QuoteEBegin-->Для каждого поля можно задать группу пользователей из ACL, имеющую права чтения/редактирования/изменения/сохранения.

[snapback]20823" rel="nofollow" target="_blank[/snapback]​

[/quote]

Это как ?

 

[Domino_Designer]

Для: LNTek


У Вас слишком бурная фантазия.

 

[GROMILA]

Человек имел в виду задать на уровне дизайна формы в свойствах поля.
Но это не то.

По традиции: Где мнение Veselinki?

 

[Domino_Designer]

LNTek
Для каждого поля можно задать группу пользователей из ACL, имеющую права чтения/редактирования/изменения/сохранения.

GROMILA
Человек имел в виду задать на уровне дизайна формы в свойствах поля.


Вот с этого места поподробней пожалуста.

 

[Domino6]

Если задача стоит чтобы не "срубить"

Способ А:
Создать респонсы и там котролировать доступом.

Способ Б:
Создать вычисляемые поля и вносить значения программно. Добавить подпись в поля (если поменяют программеры поле через агента то подпись анулируется о чем скажет в УИ).

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

Итог по-проще.
1- в документе
2.3 - респонсами. Заполняется в самомом документе а при сохранении переносит в респонсы. Когда пользователь зашел взялись данные из его респонса, отредактировал вышел сохранили в его респонс. Плюс добавить встроенный вид который отображает респонсы файл и пользовательские параметры.

 

[Afrael]

я так понмимаю, что это продолжение треда на инретрасте ?

Ссылка скрыта от гостей

в таком случае, если не вникать к конктретную логику конктретного приложения мне лично нравиться совет о "ломов приеме", который Вам дал Константин Червоненко вот тут

Ссылка скрыта от гостей

Если такой способ не подходит, то давайте работать над конкретным условием конкртеной задачи.

 

[GROMILA]

Да. Я хотел новых идей

 

[Domino6]

Для: GROMILA
Это что перепроверка, так мы все тусуемся в одних и тех же местах.
Некоторые с форумами через Notes работают.


Для: GROMILA Конкретезируй получиш не "новую идею" а решение под свою постановку задачи (оптимальную)

 

[nor]

Я вообще ничего не понял.

Защита желательна на уровне документа, а не на уровне UI-классов

Что значит, на "уровне документа"?

Секции не обеспечивают защиту на уровне документа

??? А какие еще уровни есть? Уровень домена - сервера - базы данных - документа - поля. Как можно разграничить досуп к частям документа на уровне документа в целом?
Мое мнение - секции с уровнем доступа обеспечивают все 3 пункта поставленной задачи. Если кто захочет со мной поспорить на 1 кг. мороженого, готов доказать это практически.

 

[Domino6]

<!--QuoteBegin-nor+10:06:2005, 15:46 -->
<span class="vbquote">(nor @ 10:06:2005, 15:46 )</span><!--QuoteEBegin-->Мое мнение - секции с уровнем доступа обеспечивают все 3 пункта поставленной задачи. Если кто захочет со мной поспорить на 1 кг. мороженого, готов доказать это практически.

[snapback]20940" rel="nofollow" target="_blank[/snapback]​

[/quote]

Агентами и кнопками можно менять содержимое полей в полях под секциями если у пользователя есть доступ на документ. 1 кг мороженного можеш себе купить. Только если поля подписываемые то тогда возникает снятие подписи но не более поля можно менять

 

[GROMILA]

ДОМИНО, Объяснил правильно, молодец, я бы так не смог!

Nor, ты мне друг, но истина дороже.


Я из интертраста перешел сюда перед решающей "схваткой"
планирую на выхоодных ТР сделать, но уже чувтсвую, что лучший метод
на IsProtected-ах. Код выложу тут и там.

 

[nor]

Агентами и кнопками можно менять содержимое полей в полях под секциями если у пользователя есть доступ на документ. 1 кг мороженного можеш себе купить. Только если поля подписываемые то тогда возникает снятие подписи но не более поля можно менять

Для определенного пользователя можно запретить запуск агентов (всех или определенных), даже если у пользователя есть доступ к документу. При разработке приложения дизайнер и администратор (если таковы имеются, иначе дизайнер и администратор - одно лицо) работают в тесном взаимодействии, как правило. Админитратор определяет уровни доступа к приложнию для различных групп пользователей, дизайнер приложения - кодирует такой доступ. Не мне тебе объяснять эти истины. Как можно изменить поле (по кнопке, агентом), если у пользователя нету прав соответствующих?
Еще раз - поля изменить невозможно, если грамотно продумана политика безопасности.

Я из интертраста перешел сюда перед решающей "схваткой"
планирую на выхоодных ТР сделать, но уже чувтсвую, что лучший метод
на IsProtected-ах. Код выложу тут и там.

Удачи, я уверен, что ты повторишь мои ошибки. Тебя ждет разочарование, этот метод работает плохо.

 

[Veselinka]

Громила, привет.

Мое мнение следующее:

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

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

Здесь вопрос - как в конкретном случае сделать это наиболее красиво, расширяемо, удобно, производительно и т.д. Это тебе решать или архитектору.

 

[GROMILA]

Супер!!!
Веселинка, это самый правильный ответ!!! Я уверен на все 100%
Твоих слов достаточно оказалось, правда без форума на intertrust
тоже было бы плохо.

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

Все правильно, комбинация методов Константина Червоненко

Здесь вопрос - как в конкретном случае сделать это наиболее красиво, расширяемо, удобно, производительно и т.д. Это тебе решать или архитектору.

А это мне, чтобы не боялся применять

 

[nor]

GROMILA
А не мог бы ты мне объяснить, что ты понял на все 100%. А то я ничего из слов уважаемой Веселинки не понял. В чем состоит суть методов какого-то Константина Червоненко?

 

[nor]

Veselinka

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

А чем тебе не нравится стандартная схема защиты документов? Я так понял, суть метода, который ты предлагаешь состоит в следующем:
1. Работа агентов. Например, пользователь выполняет действие, действие запускает агент, в котором прописано уже, кто и что может делать.
2. Работа системных профильных документов. Пользователь начинает выполнять действие, действие обращается к профильному документу, в котором прописано, кто и что может делать.
Я так все понял?

Давайте нормально обсудим эту тему. А то кто-то что-то понял, а другим не сообщает. Так не честно.

 

[GROMILA]

Давайте нормально обсудим эту тему.

не вопрос, я малость занят, но примерчик за мной 100 пудов.

А то кто-то что-то понял, а другим не сообщает. Так не честно.

Все честно:
Выше Afrael дал все ссылки на форум INTERTRUST, так что я не повторялся.
Константин там проповедовал 2 метода:
- Разделить на 3 и более документов
- Использовать подписанные админом агенты для доступа к защищенным, чтобы иметь возможность изменять рабочие поля (часть п1).

Как работает вся эта кухня сейчас:
1. Вся информация хранится в одном документе, а иначе как вид построить?
2. Служебные поля (ч1) я изменяю только посредством агентов на сервере.
Весь документ защищен, но агенты могут менять поля!.

Теперь к Veselinke идем.
Вся прелесть в том, что она дала определения, а не просто отрывки фраз:
1. Общий документ - интерфейсный документ для управления и вывода в представления
2. Служебный документ - это часть из общего (их 3 штуки для меня)
Такой документ можно зашифровать, защитить, вообще хранить в другой СУБД и т.д и т.п. Так как он ОТДЕЛЬНЫЙ

И разработчику нужно оптимально решить для себя как он будет разделять информацию, чтобы обеспечить требуемые параметры системы:
- призводительность (не менее 2 сек)
- достаточную на экране информативность (View)
- степень защиты ЭД (комплекс Lotus-мер о которых ты говорил).

А вот попрогать прийдется. Я дал свод критических замечаний, которые
прийдется учесть и грамотно запрогать
(см. мои опасения

Ссылка скрыта от гостей

)