Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
Какой код нужно внести в CLR процедуру на SQL Server, чтобы обеспечить ей возможность держать в себе какое то значение, которое будет сохраняться после 1 вызова и использоваться к примеру во 2-ом?

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

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

Решение с локальной временной таблицей не работает, так как напрямую вызвать код ее создания нет возможности, а создавать ее в триггере или хранимке она падает по их завершению.
22 ноя 12, 17:46    [13515039]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
vpozhidaev
один SPID вызывает CLR в триггере, передает ей значение. После этого процедура вызывается от этого же SPID только в другом триггере


создайте нормальную таблицу -постоянную и пишите в нее свои состояния
22 ноя 12, 17:48    [13515058]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
Maxx,

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

В общем необходимо как то между двумя батчами сохранить значение и зашифровать из одного и передать в другой и там расшифровать. При этом можно использовать только команды insert, update, delete на таблицу с триггерами. Никаких команд больше напрямую использовать нельзя. Можно использовать команды из триггеров.
22 ноя 12, 18:07    [13515225]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Glory
Member

Откуда:
Сообщений: 104760
vpozhidaev
Нормальная таблица не подходит, потому как данные из нее видны. Шифровать данные не имеет смысла, так как нет возможности это сделать нормально(симметричный ключ создаваемый в триггере, его негде хранить, приватный ассиметричный ключ точно так же негде).

Вообще-тот все, что вы сохраните на сервере, может быть прочитано при наличии прав.
22 ноя 12, 18:14    [13515257]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
забрать права на чтение из етой таблицы не судьба ? у простых смертных ?
а вы вообще свято увереннны что у обоих батчей будет одинаковый спид ?

чем по вашему отличаються
автор
только команды insert, update, delete

от любых других для работы с таблицей то...хоть из триггера ,хоть из чего угодно...да и откровенно больше ничего такого вы с таблицей и сделать то не сможете..ну drop/alter еще....
22 ноя 12, 18:15    [13515260]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Гость333
Member

Откуда:
Сообщений: 3683
vpozhidaev,

CREATE TABLE dbo.SecretTable (SPID INT DEFAULT @@SPID, SecretData VARCHAR(1000));
GO
CREATE VIEW dbo.MySecretData AS
SELECT SecretData FROM dbo.SecretTable WHERE SPID = @@SPID;
GO

Выдаёте права только на MySecretData.
22 ноя 12, 18:18    [13515284]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
vpozhidaev
После этого процедура вызывается от этого же SPID только в другом триггере, или в этом же самом, и CLR возвращает то значение которое ей передали при первом вызове.
А потом другой пользователь вызывает эту же процедуру в этом же SPID, и получает ваше значение...
За несколько секунд можно успеть сделать много тысяч вызовов, а можно только один.

Какая то странная постановка задачи.

В принципе наверное можно использовать статические объекты в CLR, то точно сказать не могу - не использовал, вдруг они там запрещены.
22 ноя 12, 19:05    [13515529]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
dalex1973
Member

Откуда: Польша
Сообщений: 287
А SET CONTEXT_INFО не xотите использовать?
22 ноя 12, 19:39    [13515689]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
Glory,

Самому смешно, однако надо написать код который закроет данные от сисадмина на секунду. Подключение через другой SPID не будет.

Сейчас есть закрытые через симметричные ключи данные которые админы не видят. Однако симметричные ключи необходимо сначала открыть. Открытие происходит через бизнес приложение на его SPID.

Однако приложение не умеет работать напрямую с сиквелом, а умеет только через модификацию строк таблиц. И потому не может отправить закрытый от профайлера запрос на open_keys. Было принято решение создать на стороне сиквела ассиметричный ключ, публичную его часть вернуть приложению, а приватную оставить себе. При помощи публичной части приложение зашифрует пароль от симметричного ключа и сможет передать его сиквелу. Проблема в том что негде на сиквеле хранить эту приватную часть пароля.

Потому и было решено использовать CLR.
22 ноя 12, 19:49    [13515727]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
dalex1973,

Его могут видеть все. Оно не шифровано. Потому нет возможности.
22 ноя 12, 19:50    [13515728]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
alexeyvg,

Да, ты только слышишь и считаешь что странная, а я ее сделать должен или придумать что то лучше :D

Нет, не будет подключения через другой SPID. Будет только один SPID.
22 ноя 12, 19:51    [13515732]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Crimean
Member

Откуда:
Сообщений: 13148
в SQL DLL я такое делал, не вопрос. в CLR еще не пробовал
внимание! накладные расходы будут приличные + потенциально может быть неконкурентное выполнение
но в целом сделать достаточно несложно
22 ноя 12, 19:56    [13515749]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
vpozhidaev
alexeyvg,

Да, ты только слышишь и считаешь что странная, а я ее сделать должен или придумать что то лучше :D

Нет, не будет подключения через другой SPID. Будет только один SPID.
Да вы скажите про бизнес-задачу то.

Просто абсурд - почему "не будет подключения через другой SPID"? потому что админы честные и у них рука не поднимется подключиться под тем же SPID???
Соответственно не сработает "надо написать код который закроет данные от сисадмина на секунду".

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

Пока вы просто озвучиваете технические решения, а не задачу.
22 ноя 12, 21:17    [13516000]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Crimean
Member

Откуда:
Сообщений: 13148
alexeyvg,

да вроде как уже озвучили - не особо меняя прикладуху задействовать шифрование данных
дырочка в прикладухе есть - ей и пробуют воспользоваться
22 ноя 12, 22:06    [13516188]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
Crimean
alexeyvg,

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

Ну можно придумать такой вариант:
vpozhidaev
Однако приложение не умеет работать напрямую с сиквелом, а умеет только через модификацию строк таблиц. И потому не может отправить закрытый от профайлера запрос на open_keys. Было принято решение создать на стороне сиквела ассиметричный ключ, публичную его часть вернуть приложению, а приватную оставить себе. При помощи публичной части приложение зашифрует пароль от симметричного ключа и сможет передать его сиквелу. Проблема в том что негде на сиквеле хранить эту приватную часть пароля.

1. ХП создаёт ассиметричный ключ, публичную его часть возвращает приложению, а приватную оставляет в переменной. Далее запускает цикл с задержками на какое то время, в цикле читает таблицу для ответов приложения.
2. При помощи публичной части приложение зашифрует пароль от симметричного ключа и кладёт в таблицу для сообщений.
3. ХП в своём цикле читает это сообщение, прекращает цикл, делает всё что надо.
22 ноя 12, 22:22    [13516228]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
alexeyvg,

Да, если такой алгоритм не подходит из за того, что приложение не умеет вызывать ХП, то можно сделать ещё проще - запустить одну процедуру с бескронечным циклом, которая всё это будет делать, соответственно она будет хранить всю приватную инфу (публичную часть ключа) у себя внутри.
22 ноя 12, 22:27    [13516251]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
alexeyvg
alexeyvg,

Да, если такой алгоритм не подходит из за того, что приложение не умеет вызывать ХП, то можно сделать ещё проще - запустить одну процедуру с бескронечным циклом, которая всё это будет делать, соответственно она будет хранить всю приватную инфу (публичную часть ключа) у себя внутри.
Не, нужно, что бы приложение умело вызывать ХП, иначе оно не сможет передать ключ.
22 ноя 12, 22:29    [13516259]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Crimean
Member

Откуда:
Сообщений: 13148
alexeyvg,

всегда приятно смотреть когда умные люди беседуют
23 ноя 12, 01:04    [13516552]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
Crimean
alexeyvg,

всегда приятно смотреть когда умные люди беседуют
Торопился помочь ТС :-)
23 ноя 12, 09:08    [13516949]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
alexeyvg,

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

Как это реализовать? Из триггера? и чтобы процедура хранила в себе значение приватного ключа?

Касательно CLR написал попробовал, как то не очень эта идея с решением.

Допустим приложение ее заполнило:
EXEC AddPass
@pass = 'Привет',
@spid = @@SPID

Однако любой другой может сделать вот так, зная SPID и будет иметь ключ:
DECLARE @pass NVARCHAR(MAX)
EXEC GetPass
@spid = @@SPID,
@pass = @pass

Так что твой вариант пока самый адекватный если расскажешь как его реализовать?
23 ноя 12, 13:31    [13519003]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
vpozhidaev,

Или CLR с статичным классом будет своя для каждого пользователя? И эта статичная переменная так же будет у каждого свой?
23 ноя 12, 13:39    [13519098]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
Crimean,

Ну да сначала я сделал DLL потом подключил ее как Assembly к сиквелу, и загрузил из нее хранимки.

Ты про это?
23 ноя 12, 13:42    [13519128]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
Crimean
Member

Откуда:
Сообщений: 13148
vpozhidaev,

1. CLR может сама взять SPID. не нужно ей такого параметра на входе. проблема "перевыдачи SPID" решается добавлением в уникальность во внутренней коллекции + logintime. и его можно взять через Context непосредственно изнутри CLR. вуаля. ну и кто сказал, что у пользователей будут явные права на вызов "этого"? вот и все. ну и с последней стороны мы как бы договорились что реальной защиты не будет, будет "присирание" :)

2. SQL DLL. не CLR. а которые extend. я не зря про ODS API упоминал. там легко делается статичная коллекция, главное с ее поддержанием не напетлять - или сразу сделать размерностью с максимальное значение smallint (тип для SPID) или критические секции с риском "залипнуть", но это обходится таймаутами и усложнением обработки ошибок
23 ноя 12, 13:57    [13519246]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
vpozhidaev
alexeyvg,

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

Как это реализовать? Из триггера? и чтобы процедура хранила в себе значение приватного ключа?

Нет, процедура хранит приватную часть ключа у себя в локальной переменной, уж её то точно никто не сможет прочитать снаружи :-)
vpozhidaev
Однако любой другой может сделать вот так, зная SPID и будет иметь ключ:
Ну так дальше нужно понять требуемую логику.

Что со всем этим нужно делать? Понятно, что не нужно писать процедуру, которая возвращает любому ключ :-)

Я так предполагал, исходя из этого:
vpozhidaev
Было принято решение создать на стороне сиквела ассиметричный ключ, публичную его часть вернуть приложению, а приватную оставить себе. При помощи публичной части приложение зашифрует пароль от симметричного ключа и сможет передать его сиквелу.
получив симметричный ключ, эта процедура уже с его помощью будет делать что то полезное.
23 ноя 12, 14:11    [13519358]     Ответить | Цитировать Сообщить модератору
 Re: Хранение значения внутри CLR  [new]
vpozhidaev
Member

Откуда: Москва
Сообщений: 91
alexeyvg,

Ну вот пример:
1 Приложение вставляет данные в таблицу
2 Триггер вызывает хранимку
3 Хранимка создает ассиметричный ключ в аутпут возвращает его публичную часть, а в переменной внутри себя хранит приватную и каким то образом висит в памяти
...
5 PROFIT!!!

Как я понимаю триггер не закроется, пока не закроется эта висящая хранимая процедура, значит приложение не получит ответ с сервера и не сможет ничего сделать.

Выполнение идет же в одном потоке вставка записи->триггер начало-хранимка-триггер конец-возвращение ответа приложению.
Как реализовать то что поток как бы станет параллельным?
23 ноя 12, 14:27    [13519486]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить