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

Подразумевается, что 1С переведена на WIN-авторизацию.
Подробнее тут http://www.1cpp.ru/forum/YaBB.pl?num=1250146271/0

Как я это вижу:
1. Переименовываем защищаемую таблицу (SC133 ---> _SC133). Cоздаем VIEW (SC133) и закрываем доступ к самой таблице.
2. Поправляем BKEnd таким образом, что при верификации, проверяется не только существование самой таблицы, но и аналогичной VIEW, а при проверке индексов подсовывается основная таблица (не хочется полностью отключать верификацию или делать что-то сложное по рецепту с Софтпоинта).
3. При необходимости реструкторизации базы переименовываем все таблицы и убиваем VIEW.  После окончания запускаем обработку со скриптами, которые создают VIEW и переименовывают таблицы.
4. VIEW создаем по рецепту от Z1    ''WITH SCHEMABINDING". (поэтому их и приходится удалять при реструкторизации) - вчера обнаружил, что в этом случае сервер пропускает хинты INDEX, а значит отпадает необходимость дополнительно патчить BKEnd на предмет исправления шаблонов запросов. (по крайней мере на 2008 SQL-е, на 2000-м нужно проверить).

Всё это работает на тестовой базе c ограничение доступа к справочнику Контрагенты и 2 видам документов.
В вследующем посте хочу обсудить тексты самих VIEW....

zk96 писал(а) 22. Июля 2011 :: 09:52:


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

Я завел табличку 'rules' со столбцами ('_user', '_group') и в этой табличке прописал соответствие каким пользователям, какие группы контрагентов доступны.

Вьюшка для справочника выглядит так:

SELECT    *
FROM	   dbo._SC133
WHERE     (PARENTID IN
		  (SELECT     _group
		    FROM	    dbo.rules
		    WHERE (_user = SUSER_SNAME()))) OR  (ISFOLDER = 1) 

Вьюшка для таблички Шапки "Счета"

SELECT     *
FROM	   dbo._DH12517
WHERE     (SP12753 IN  (SELECT     ID
		    FROM	    dbo.sc133)) 

SP12753 - реквизит Справочника Контрагенты


Для Табличной части "Счета"

SELECT     *
FROM	   dbo._DT12517
WHERE     (IDDOC IN  (SELECT     IDDOC
		    FROM	    dbo.DH12517)) 

И для таблицы "Журналы"

SELECT     *
FROM	   dbo.__1SJOURN
WHERE     (IDDOCDEF <> 12517) AND (IDDOCDEF <> 321) OR
			    (IDDOCDEF = 12517) AND (IDDOC IN
				  (SELECT     IDDOC
				    FROM	    dbo.DH12517)) OR
			    (IDDOCDEF = 321) AND (IDDOC IN
				  (SELECT     IDDOC
				    FROM	    dbo.DH12517 AS DH12517_1)) 

Обычные журналы после этого начинают реально тормозить.
Журналы на ТП, в принципе работают сносно.

chessman писал(а) 22. Июля 2011 :: 12:45:

А ты попробуй избавиться от "select *" , напиши нужные поля. И поробуй убрать "or" , в условиях используй EXISTS, по идее будет быстрее.

chessman писал(а) 22. Июля 2011 :: 06:13:

VIEW WITH SCHEMABINDING - вещь очень мощная, но зачем ты используешь SCHEMABINDING, т.к. в голом виде толку от нее нет (только гемор себе создаешь, написанный в скобках), а при использовании индексов  - она не работает в 1С?
Точно уже не помню всех мест, где 1С устанавливает флаги, но если ты создашь VIEW WITH SCHEMABINDING с индексом на регистр, то провести документ уже не сможешь.

chessman писал(а) 22. Июля 2011 :: 12:45:

Тормоза из-за многократного вызова подзапроса с отбором по неиндексированному полю. Для того, чтобы спрятать документы от штатных выборок, достаточно отфильтровать _1sjourn, а прямые запросы и так в твоих руках. Так что отбор лучше делать по общему реквизиту с отбором - они все в _1sjourn и проиндексированы.

А чтобы не иметь проблем с реструктуризацией - оставь _1sjourn на месте, сделай view с левым именем

select *
from _1sjourn with (nolock)
where ...

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

AndreyM писал(а) 24. Июля 2011 :: 15:23:



Если не использовать VIEW WITH SCHEMABINDING, то конструкция подобная Спр.НайтиПоКоду() будет выдавать ошибку с дальнейшим вылетом базы или нужно патчить bkEnd, убирать хинты 'INDEX'

AndreyM писал(а) 24. Июля 2011 :: 15:23:


Имеется ввиду индекс у самой VIEW?