Не то http://infostart.ru/projects/2836/ ?

Кажется разобрался.

Для тех, кто читал приведенный выше линк: в предлагаемой схеме меня не устаивало то, что всем пользователям давались права sysadmin. Это сводило на нет всю идею win-авторизации.

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

Расскажу подробно, как я делал. Может кто оптимизирует.

Часть I.

1. Правим BKEnd.dll, как описано в линке выше.
Изначально


Правим на



2. Как было написано в источнике 1С очень хитро работает с табличкой _1SCONNECT.
В профайлере видно, что она ее удаляет, потом заново создает с каким-то UUID. И все это происходит в момент входа первого пользователя. Я не знаю точно, но как мне кажется 1С-ка связывает этот UUID c  каталогом, где лежит MD-шник. Если я не прав, пусть меня поправят. Для входа следующих пользователей она сверяет этот UUID с тем, который лежит в _1SCONNECT.
Но тут возникает проблема - 1С-ка смотрит табличку, соответствующую текущему пользователю

Часть III.
Пишем функцию - туда мы копируем тот запрос, вместо которого мы  вставили наши вызовы.  

Функция:

CREATE FUNCTION huy()
RETURNS int
AS
BEGIN

	DECLARE @res int

	Select @res = COUNT(*) from master..sysprocesses where dbid=DB_ID('_Proba1') and program_name='1CV7'

	RETURN @res
END
 

Пишем хранимую процедуру:

CREATE PROCEDURE [dbo].[huy1]
AS
BEGIN
	SET NOCOUNT ON;

	if dbo.huy() = 1 -- Для первого юзера очищаем все таблицы _1sconnect и выходим
		Begin
			exec SP_MSforeachtable @command1 = 'Delete from ? ', @whereand = ' and o.name = ''_1sconnect'' '
			Return
		End

	declare @res char(36)
	declare @curuser varchar(200)

	Set @curuser = CURRENT_USER

	-- для последующих юзеров - собираем во временную таблицу все UUID cо всех таблиц _1sconnect
	-- по идее это UUID должен быть не пустым только в какой-то одной - соответствующей первому пожключению

	Create table #_1SProba (CONNECTUUID char(36) not null)
	execute SP_MSforeachtable @command1='insert #_1SProba Select * from ?', @whereand=' and o.name = ''_1sconnect'''
	select top 1 @res = CONNECTUUID from #_1sproba

	If exists (select * from sysobjects where id = object_id(@curuser + '._1SCONNECT') and sysstat & 0xf = 3)
		-- наверное это можно не делать, ну на всякий пожарный почистим
		exec ('Delete from ' + @curuser + '._1SCONNECT')
	else
		Create table _1SCONNECT (CONNECTUUID char(36) not null)

	-- вставляем найденный UUID в "родной" _1sconnect
	exec ('insert ' + @curuser + '._1SCONNECT VALUES(''' + @res + ''')')
END
GO
 

Огромное спасибо!
А нельзя ли в личку патченую bkend.dll?
leshik@stav1c.ru

Согласен

А имя хранимки по какому принципу выбирал?

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

А зачем? Я правда не понимаю.

И каким образом повысится уровень защиты? Пользователь также может считать все данные. Что изменилось?

JohnyDeath писал(а) 18. Августа 2009 :: 12:25:

Ну это просто автор не стал дальше углуб##ться в права пользователей в SQL, а на самом деле дальше открываются очень большие горизонты.
Вот мне например это нужно для шифрования БД средствами самого SQL.

leshik писал(а) 18. Августа 2009 :: 12:37:

Можно про шифрацию подробней.
Что имеется в ввиду ?

Z1 писал(а) 18. Августа 2009 :: 13:04:



По-моему не получится, т.к. пользователю выдается роль db_owner.

chessman писал(а) 18. Августа 2009 :: 13:18:

надо пробовать
Даже если не получиться Все равно пароль ыф не виден
+ Легче обнаруживать кто грузит тяжелыми запросами базу.

Чаще всего надо закрывать доступ к конкретным запис_м одной таблицы (например, дл_ манагера - только его реализацию и заказы). А этого все равно никак не добьёшьс_. Или йа не прав?

Да это-то понятно. Есть много способов как псевдоограничить пользователя.
Я к тому что, есть какой-нить манагер, который раздабыл обработку или просто знает как несколькими запросиками перегнать все данные из нужных ему табличек. И никакое ТП или журнал с отбором здесь не спасут.

Z1 писал(а) 19. Августа 2009 :: 07:21:


Ну это не совсем так - заведи несколько sql-х логинов, для каждой базы свой. У меня 20 баз, и честна, в лом для каждой делать свой логин.

Z1 писал(а) 19. Августа 2009 :: 07:21:

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

JohnyDeath писал(а) 19. Августа 2009 :: 07:50:

В регистрах ОстаткиТоваров цен нет по крайней мере у меня.
Смотри закрываем менеджерам  доступ к документам Прих, Расход Накладные,
Закрываем менеджерам  доступ к Регистру остатки Товаров.
Отчет Реестр накладных для менеджеров в нужном объеме переписываем через xp ( хранимая процедура ).
Все менеджеры не получат никак доступ к sql таблицам Накладным и при этом смогут работать в рамках их полномочий.

chessman писал(а) 19. Августа 2009 :: 09:34:

Да не менеджеры умные а умные те кому нужны эти данные
или они найдут умных кто им поможет эти данные получить.
Вечная проблема сыщик и воры

chessman писал(а) 19. Августа 2009 :: 09:56:

sql сервер вообще не знает табличка 1с-ная или нет  
для него главное есть или нет права  доступа

JohnyDeath писал(а) 19. Августа 2009 :: 07:08:


Все, нашел решение, как это можно сделать...(вспомнил, что давным давно читал о view вот тут - softpoint.ru, это не реклама)
Предположим, что данные будут отражаться в ТП.
Закрываем доступ на всю таблицу(ы) для пользователя. Делаем view, с  условиями отбора для этого пользователя. Открываем доступ на это view, в ТП обращаемся не к таблице(ам), а к view.

chessman писал(а) 20. Августа 2009 :: 12:23:

а что при этом будет с индексами ?

Z1 писал(а) 20. Августа 2009 :: 12:40:


Ну у view тоже можно индексы строить.
А вообще, авторитетно не отвечу, нужно изучать.

chessman писал(а) 20. Августа 2009 :: 12:54:

так это время сервера.
этим мне и не нравиться view это хорошо когда база не нагружена
иначе лучше и не начинать (ИХМО).
Мое решение не зависит через 2 таблицы не имеет этого недостатка.

Тоже занимаюсь вопросами WIN-авторизации. Цель, которую ставили: ограничение доступа пользователей, в том числе и программистов к заданной информации. Сделали win-авторизацию, набросали шаблоны скриптов для view. Есть нестыковка..пока одна  разграничение доступа можно использовать как на уровне строк так на уровне колонок. Со строками получилось, а с колонками есть нюанс. Предположим, я хочу скрыть от пользователя значение зарплаты в карточке сотрудника. Затык происходит при записи такой карточки, поскольку не указать эту колонку во view нельзя - вылетит 1С, вывести вместо колонки, предположим ноль можно, но при записи снова вылетит 1С.  Насколько я понимаю, при записи движок перебирает через метаданные все реквизиты записываемого объекта и подставляет их в шаблон скрипта, хранимого в bkend.... Может кто-то работал в этом направлении..чтобы передавать не весь набор колонок, а только то, что нужно? А то решение-то жизнеспособное, но только для просмотра

Андрей, спасибо за информацию. Я работаю с T-SQL достаточно давно. Проблема находится на ДРУГОМ уровне. Я хочу, чтобы даже программисты 1С не имели возможности при помощи тех же прямых запросов получать информацию, которую им не положено видеть. Т.е., даже написав что-то подобное:

Сет = СоздатьОбъект("ODBCRecordSet");
текст = "
|select * from sc838
|";
ТабИтоги = Сет.ВыполнитьИнструкцию(Текст);
 

они получили информацию только из тех колонок, которые им доступны. Это я реализовал с помощью view.
Задача стоит так: при записи таких таблиц с ограниченным доступом мне нужно, чтобы ОБНОВЛЯЛИСЬ ТОЛЬКО ТЕ колонки,которые им доступны. Написать прямой апдейт не проблема. Проблема, чтобы 1С корректно отрабатывала такой запрос. Конечно, можно все заменить на вызовы методов своих классов, но проект в таком случае станет резиновым по срокам - большая конфигурация

ArtInSky писал(а) 24. Сентября 2009 :: 16:12:


Ждем!

ArtInSky писал(а) 24. Сентября 2009 :: 15:57:

понятно.
но все равно в файле dds должна быть полная информация обо всех колонках всех таблиц базы 1с .
Так что скрыть от всех программистов проблематично.
Вторая проблема  скрыть чтобы эти программисты не получили
достут к базе master и к sp_help и аналогичным.

Тригер по идее должен получиться.Я ни разу не делал тригер на view.

да, и касательно win-авторизации..забираем все права на защищаемые таблицы и даем права на исполнение всех х.п.

chessman писал(а) 29. Сентября 2009 :: 08:53:


Наверное, невнимательно прочитал, сорри.
Ты view использовал для ограничения доступа?

chessman писал(а) 29. Сентября 2009 :: 09:02:


Нда, снова один
Борюсь с инсертом на view. Как только что выйдет - маякну.

chessman писал(а) 29. Сентября 2009 :: 09:56:


У меня не работает ограничение видомости колонок. Я регулирую видимость в предикате SELECT view. Все уперлось в ROW_ID. Это поле не должно фигурировать во view из-за свойства identity (при вставке поле не должно стоять в списке колонок). Но, в таком случае не проходит, например, инструкция "Спр.НайтиПоКоду()" (в профайлере она выглядит как:
select * from SC838(NOLOCK)            where CODE='artinsky        ' order by CODE
). В менеджмент студио запрос выполняется на ура.
Самое смешное, что данная ошибка уходит, если проиндексировать view(т.е., создать такие же индексы, как и у защищаемой таблицы), а индексы view базируются все на том же ROW_ID. Какой-то замкнутый круг. Используешь ROW_ID во вью - селект не проходит, не используешь - найти по коду не проходит.

ArtInSky писал(а) 29. Сентября 2009 :: 11:43:


А как ты индексы создаешь у view? В студии есть такой пункт, но сколько я не пробовал нифига не получается.

Z1 писал(а) 29. Сентября 2009 :: 13:10:

Ну да, так с этим проблем и нет

chessman писал(а) 29. Сентября 2009 :: 13:22:

Ставь 2005

chessman писал(а) 29. Сентября 2009 :: 13:22:

Переходи на 2005.
В нем много улучшений и sp3 2005 c 1c77 нет проблем.
хотя сами сидим на sql200. с 2005 все отладил на одном филиале

JohnyDeath писал(а) 29. Сентября 2009 :: 13:31:


Раньше вроде ограничение на размер базы было?

chessman писал(а) 29. Сентября 2009 :: 13:33:

Да, вроде и щас есть в 4 Гб http://technet.microsoft.com/ru-ru/library/ms165672(SQL.90).aspx
(там же увидел, что ОЗУ ограничено в 1 Гб  )

Только я где-то краем глаза читал, что можно заливать базу, например в 3,5 Гб, а потом неограниченно наращиваться. Или я не так прочитал? Кто-нибудь из знающих опровергните или подтвердите.

У меня пока только один вариант есть, как решить проблему с Справочник::НайтиПоКоду -  использовать класс наследник от Справочника, где переопределить этот метод.

Z1 писал(а) 30. Сентября 2009 :: 07:24:

Спасибо.  Я тоже об этом подумал. Пока не хочется заморачиваться с классами. Поднял топик здесь:
http://sql.ru/forum/actualthread.aspx?tid=699664

Зря ты на счет классов, это же фундаментальная вещь, а в данном случае вообще все просто будет.

chessman писал(а) 30. Сентября 2009 :: 07:53:


Ни в коей мере не умаляю красоту решения. Просто рою до последнего.

Вот увидел пересекающуюся тему на SQL.ru - может автор тем один и тот же?
http://sql.ru/forum/actualthread.aspx?tid=700362

leshik писал(а) 05. Октября 2009 :: 03:42:


это я

ArtInSky писал(а) 27. Октября 2009 :: 08:38:



Хорошая новость. Буду пробовать-смотреть. Баланс вот только бы сдать  .

Поставил SQLExpress 2005, пропатчил 25 релиз, как описано http://www.script-coding.info/SQL2005.html, за исключением этого:

---

Возможно, для коллективной работы в базе данных (одновременной работы нескольких пользователей) могут потребоваться дополнительные изменения в BkEnd.dll, которые можно произвести с помощью Unofficial Service Pack v2.13.24 для 24 релиза 1С (он работает и на 25 релизе), установив флажок "Разрешать другим пользователям входить в базу (SQL)" на вкладке "Защита". Эти изменения можно произвести и вручную (для 25-го релиза 1С):
000DA023: 85 40
000DA024: C0 90

Примечание: после вышеупомянутых изменений 1С будет производить верификацию структуры таблиц и процедур всегда, а не только при входе первого пользователя в базу (при коллективной работе), что немного замедлит запуск 1С.

---

(можно и это сделать, но тогда верификация будет у каждой сессии, а нам оно надо?)

Чтобы предложенная конструкия работала, у
пользователей с ролями public, необходимо включить опцию "View Server State" (иначе не удается получить кол-во активных сессий)

ArtInSky писал(а) 24. Сентября 2009 :: 15:57:


Мне тут подумалось, что от программистов 1С это все равно не реально скрыть - достаточно написать запрос, который будет выполняться всеми пользователями и свои результаты куда-нить складировать. В один прекрасный момент он отработает и у чела со всеми правами.
Что-то подобное можно сделать и на 8-ке. Допустим у программиста есть доступ к бух.базе, но нет доступа к базе ЗУП'а. Если предположить, что доступ к Бух и ЗУП-базам имеет глав.бух, то из бух-базы можно постучаться в ЗУП под глав.бухом.

chessman писал(а) 27. Октября 2009 :: 16:37:

Да, едет. Только у меня не Express.

chessman писал(а) 29. Октября 2009 :: 09:00:


Например, через роль базы данных.