Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 6203
Сабж. Я в курсе про sp_who, sys.sysprocesses, и функции типа system_user - в моем случае специфика такова, что приложение, в котором нужно логировать работу пользователя с базой, внутри себя открывает коннект с SQL-аутентификацией; соединение доверенным не является (поэтому поле nt_user в sysprocesses пустое). Способ коннекта программы к серверу изменить нельзя. Вынести логирование в само приложение - очень трудоемкая задача ввиду того, что приложение весьма обширное, и выискивать все точки его взаимодействия с базой - задача на долгое время (которого, как обычно, нет). Пока что из идей имеется только одна: после открытия коннекта создавать локальную временную таблицу с одной записью - логином пользователя, и из триггеров читать эту таблицу (вся работа с базой производится в контексте одного коннекта на один экземпляр приложения, и этот коннект открыт на всем протяжении времени работы приложения). Почему-то такое решение мне не особенно нравится. Может, можно придумать что-то лучше?
22 сен 11, 11:04    [11317341]     Ответить | Цитировать Сообщить модератору
 Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
iljy
Member

Откуда:
Сообщений: 8711
Сон Веры Павловны,

CONTEXT_INFO
22 сен 11, 11:15    [11317440]     Ответить | Цитировать Сообщить модератору
 Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
Ken@t
Member

Откуда: 大地
Сообщений: 3265
iljy
Сон Веры Павловны,

CONTEXT_INFO


если кто-то не использует его для своих целей. Вообще порочная практика кмк.
22 сен 11, 11:52    [11317841]     Ответить | Цитировать Сообщить модератору
 Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
iljy
Member

Откуда:
Сообщений: 8711
Ken@t
iljy
Сон Веры Павловны,

CONTEXT_INFO


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

Кто бы это мог быть? А порочная практика - это устраивать соединение по встроенному в приложение логину, а потом мучительно выискивать, кто же на самом деле это соединение установил.
22 сен 11, 11:58    [11317905]     Ответить | Цитировать Сообщить модератору
 Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Если у вас двух уровневка (каждый коннект на отдельной машине/процессе)(!), то есть ещё варианты, можно использовать:
  • мапирование по IP (номеру процесса)
  • параметр коннекта "Application Name".
  • 22 сен 11, 12:03    [11317961]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    Сон Веры Павловны
    Member

    Откуда:
    Сообщений: 6203
    Ken@t
    если кто-то не использует его для своих целей.

    Вроде бы не использует - ни специально, не посредством MARS. Спасибо, попробую.
    iljy
    А порочная практика - это устраивать соединение по встроенному в приложение логину

    Абсолютно согласен, но положение вещей именно таково, и изменить его я не могу.
    22 сен 11, 12:11    [11318061]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    Сон Веры Павловны
    Member

    Откуда:
    Сообщений: 6203
    Mnior
    Если у вас двух уровневка (каждый коннект на отдельной машине/процессе)(!), то есть ещё варианты, можно использовать:
  • мапирование по IP (номеру процесса)
  • параметр коннекта "Application Name".

  • Да, так и есть, двухзвенка. Я думаю, действительно, лучше всего будет задавать Application Name. Спасибо.
    22 сен 11, 12:22    [11318170]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Ken@t
    если кто-то не использует его для своих целей. Вообще порочная практика кмк.
    Вот, а теперь вместо CONTEXT_INFO вставте что угодно "таблица X", "каталог Y" ... и смысл станет ясень - никакая это не порочная практика.
    Хотя я не спорю, наоборот, что если есть уже специализированные механизмы (идентификация, в данном случае) то лучше их и использовать. Только вот у каждого механизма свои требования, и они не нулевые.
    Идентификаця и смена пользователя в коннекте стоят не дёшево как может комуто показаться. Иногда и вместо сиквела лучше юзать NoSql.
    22 сен 11, 12:26    [11318205]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    Ken@t
    Member

    Откуда: 大地
    Сообщений: 3265
    Mnior
    Вот, а теперь вместо CONTEXT_INFO вставте что угодно "таблица X", "каталог Y" ... и смысл станет ясень - никакая это не порочная практика.

    хм, CONTEXT_INFO недетерминированное по значению область. Между вызовами ХП значение может измениться , то есть гарантировать константное её значение в пределах коннекта весьма опрометчиво, тем более вводить её в архитектурное решение.
    А вставить "таблица X", "каталог Y" - меняется смысл сего действа появляется структурированные данные, не надо передёргивать.
    Хотя каюсь в одном из решений в хп и триггерах использовалcя CONTEXT_INFO для блокирования выполнения триггеров на некоторых таблицах, но точка входа API (sp) была одна на изменение данных.
    22 сен 11, 13:01    [11318538]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    SamMan
    Member

    Откуда: Moscow
    Сообщений: 759
    Ken@t
    CONTEXT_INFO недетерминированное по значению область.


    Что вы имеете в виду? SET CONTEXT_INFO устанавливает некую инфу для данной сессии. Никакой неоднозначности здесь нет.

    Ken@t
    Между вызовами ХП значение может измениться


    Вы говорите о значении CONTEXT_INFO и при условии что вызовы ХП происходят в рамках одной сессии? Тогда значение может измениться только если ХП сама же его и изменит, что логично. А "неожиданно" изменится значение не может, с чего бы ему меняться?

    Ken@t
    то есть гарантировать константное её значение в пределах коннекта весьма опрометчиво


    Ну как сказать... При аккуратном кодинге - вполне себе константа, но, опять же для данного подключения.
    22 сен 11, 13:25    [11318743]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    iljy
    Member

    Откуда:
    Сообщений: 8711
    Ken@t
    хм, CONTEXT_INFO недетерминированное по значению область. Между вызовами ХП значение может измениться , то есть гарантировать константное её значение в пределах коннекта весьма опрометчиво, тем более вводить её в архитектурное решение.
    А вставить "таблица X", "каталог Y" - меняется смысл сего действа появляется структурированные данные, не надо передёргивать.

    Во-первых - какое преимущество вам здесь дает структурированность? У вас простейшее бинарное значение, хотя в принципе в binary(128) можно много чего напихать. В общем случае, я надеюсь по крайней мере, все-таки доступ к контексту идет быстрее, чем к таблице, соответственно у вас структурированность против производительности.
    Ну и в -главных - а гарантировать неизменность "таблица X", "каталог Y" вы можете?
    22 сен 11, 13:34    [11318840]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    Ken@t
    Member

    Откуда: 大地
    Сообщений: 3265
    автор
    Никакой неоднозначности здесь нет.


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


    автор
    А "неожиданно" изменится значение не может, с чего бы ему меняться?


    Несогласовванность разработчиков, кстати и триггер может изменить CONTEXT_INFO

    Ken@t
    то есть гарантировать константное её значение в пределах коннекта весьма опрометчиво


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

    Не заморачивайтесь.
    22 сен 11, 13:38    [11318891]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    invm
    Member

    Откуда: Москва
    Сообщений: 9845
    Полность согласен с Ken@t -- CONTEXT_INFO слишком ненадежное решение даже если код пишет один разработчик, не говоря уже о команде. Особенно, если CONTEXT_INFO используется для хранения нескольких сущностей.

    Сон Веры Павловны, есть решение в лоб, но оно многим не нравится -- запретить серверу слушать TCP/IP, оставив только NamedPipes, либо любым другим способом обеспечить соединение клиента с сервером по NamedPipes. Тогда, даже при SQL-аутентификации, в sysprocesses и в sys.dm_exec_sessions будут корректные данные о Windows-пользователе.
    22 сен 11, 14:06    [11319170]     Ответить | Цитировать Сообщить модератору
     Re: Логирование в триггере: получение доменного логина пользователя при SQL-аутентификации.  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6724
    Ken@t
    в varbinary можно насовать что угодно
    Несогласовванность разработчиков
    Бла-бла-бла.
    Можно засунуть что угодно куда угодно. Тем более что чем чаще объект разнообразнее исползуется тем чаще можно напортачить.
    Если будет SET CONTEXT_INFO в одном месте в проге и одна/две view/функия (с Context_Info()) для получения инфы о текущем пользователе, то всё просто до безумия. А найти команду SET CONTEXT_INFO (и Context_Info()) в объектах - как два пальца.

    Код контролить надо, иначе пофиг где ошибся в уровне изоляции при начислени %% или паразитирующему использованию context_info.

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

    Мне кажется, Ken@t, это всё от того что вы видели как используют Context_Info не по назначению.
    Вот если бы вы увидели как грязно и тупо меняют контекст пользователя в прогах, и как system_user курит в сторонке, вы бы не стали здесь кричать "не по назначению", а скорее "нет ничего надёжного против кривых рук/бардачных голов/пофигизма".

    Context_Info как раз сделан под подобные случаи TC, а не сквозную передачу параметров (в триггера) - поубэваубы.
    22 сен 11, 15:44    [11320034]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить