Разграничение доступа на записи

[Роман Кошелев]

Тут проскакивала информация о возможности разграничения доступа на записи.
"Разграничение доступа на записи по фильтру - модуль RLP от Circle Capital".

1. Нельзя ли рассказать о том, что это за модуль RLP и какие о нём отзывы?
2. Есть ли ещё каки-нибудь способы разграничить доступ на записи?
3. Есть ли в планах внесение этого в стандартную функциональность?

[mazzy]

В стандартной фкнциональности 3й версии это будет. Будет реализовано при помощи view.

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

Про RLP знаю только рекламную информацию. тоже было бы интересно послушать.

[Eduard]

Про RLP - Нормальный модулек, работает.

Одна беда - можно обойти запрет при большом желании и знании. Программист взломает, грамотный консультант взломает, продвинутый пользователь с большим опытом тоже может.

Не в ядре потому что эта функциональность, сверху приписана.

Так что использовать можно, но не ожидайте чуда безопасности.

[Ted]

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

[Eduard]

Не объясню, но видел, ломают. Видимо обходят сбоку и смотрят на ту же информацию с другого конца. Как я понимаю, работает модуль на уровне ограничения просмотра, через ограничение view (или я не прав), при этом всегда есть возможность посмотреть с другого края. Потом, слышал (только слышал, не видел), что настройки, сделанные с помощью RLP, можно просто сбросить (а-ля set to default), и пожалуйста - смотри опять что хочешь.

[mazzy]

Ага. Понятно. Так и мы могем
Спасибо.

Через view - вряд ли. 2.5 не знает такого.
А насчет сбросить... Что же они не блокируют критерий в запросе...
А даже если блокируют, то пользователь может ввести * в своем критерии. А они не проверяют, видимо.


Вот я и говорю - несложно, но муторно.

[Ted]

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


А на то что любые настройки можно сбросить, скажу, что - да, любые настройки можно сбросить - зашел в базу данных - бац и стер таблицу настроек и нет настроек

[mazzy]

Хм. тогда прошу прощения. Таки скрыли критерий. Молодцы.

Можно вопросы:
1.
А как боретесь с эксалацией запроса.
Например, для пользователя установлен фильтр а*,
а пользователь вручную добавляет критерий *.
Аксапта обрабатывает оба криетерия по ИЛИ. В результате пользователь видит все.

2.
Для того, чтобы включить фильтрацию в форме, отчете надо что-нибудь менять в коде?


Ну... зайти в базу данных это уже не простой пользователь.
А админ. Обычным пользователям не даются права на разработку таблиц.
Если хочешь сказать, что заходят с помощью Аксесса/Экселя через ОДБС, то это скорее недостаточно продумана политика безопасности.
Т.е. скорее всего не все права продуманы, раз люди шляются по таблицам и - бац!

[Eduard]

А если вручную набить код, допустим, клиента, к которому доступ закрыт. Что будет?
Код очевидно, надо знать (подсмотреть), но если знать, то прямо по коду выходишь на закрытую запись и смотришь что нравиться.

[komar]

Как вариант, можно злодею поле так закрыть, что он его в фильтре и не увидит. И ничего туда не введет.

[Manner]

Можно ли узнать данный модуль RLP входит в стандартный дистрибутив и где он находиться?

[maxsmirnov]

входит в 3.0 под названием RLS
ищите в руководстве разработчика.