Права доступа: доступ через скрипт и доступ через CRM

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

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

Получается нужно дать полные права для этого пользователя и реализовать целый функционал, который бы через скрипты ограничивал права доступа.

Нравится

8 комментариев

Можно хранимку вызывать в скрипте где под полноправным/нужным пользователем все считается/запрашивается. А права настраивать в системе как обычно

"Александр Кудряшов" написал:Можно хранимку вызывать в скрипте где под полноправным/нужным пользователем все считается/запрашивается. А права настраивать в системе как обычно

Это нужно ее вызывать перед каждым считыванием/записью/удалением данных из скрипта?

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

"Кошкаров Андрей" написал:Это нужно ее вызывать перед каждым считыванием/записью/удалением данных из скрипта?

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

Конечно же, если пересчёт должен происходить автоматически при каждом выполнении операций над накладными, нужно вызывать эту хранимку. Но думаю, её можно написать универсальным образом.

Есть еще один вариант.
Делаете View в котором у вас построены суммы по Group by или просто по Sum. Далее мапите ее на сервис Table, а далее по классике. Чем это удобно, тем что вы сможете сделать джоин со своей основной таблице и вам не надо ничего вызывать дополнительно. Но тут может быть побочный эффект - это производительность.
Способ не идеален, но у вас всегда будут актуальные суммы.

А есть какой-то пример такой процедуры, которая бы у указанной таблицы устанавливала права для текущего пользователя?

Например, так:

CREATE procedure [dbo].[tsp_SetRightsForTable] (
	@TableName nvarchar(100), @CanRead int, @CanWrite int, @CanDelete int, @CanChange int)
as
 
declare @Text nvarchar(4000)
set @Text = '
declare	@RecordID as uniqueidentifier,
	@AdmUnitID as uniqueidentifier
 
declare c_RecordsForUpdate cursor for
  select [' + @TableName + '].[ID] from [' + @TableName +']
 
open c_RecordsForUpdate
  while 1 = 1    
  begin
    fetch c_RecordsForUpdate
      into @RecordID
    if @@fetch_status = -1 break 
    if @@fetch_status = -2 continue
       set @AdmUnitID = (SELECT [ID]
  FROM [dbo].[tbl_AdminUnit]
  WHERE [SQLObjectName] = SYSTEM_USER)
 
  if @AdmUnitID is NULL break
 
	 if not exists (select [ID] from [' + @TableName + 'Right] where [RecordID] = cast(@RecordID as varchar(38)) and [AdminUnitID] = cast(@AdmUnitID as varchar(38)))
	 insert into [' + @TableName + 'Right]
        	(RecordID, AdminUnitID, CanRead, CanWrite, CanDelete, CanChangeAccess)
        	values (cast(@RecordID as varchar(38)), cast(@AdmUnitID as varchar(38)), ' + cast(@CanRead as varchar(1)) + ', ' +
	cast(@CanWrite as varchar(1)) + ', ' + cast(@CanDelete as varchar(1)) + ', ' + cast(@CanChange as varchar(1)) + ')
    end
close c_RecordsForUpdate
deallocate c_RecordsForUpdate'
 
exec sp_executesql @Text
GO

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

Показать все комментарии