Як дізнатися логін, під яким клієнт увійшов в MS SQL?
Я хочу реалізувати такий механізм: клієнт (програма Delphi або хтось ще) не має доступу до деяких таблиць SQL SERVER. Але він викликає збережену процедуру, яка, з огляду на його логін (а він у нього збігається з обліковим записом Windows), видає йому ті записи з таблиць, які призначені саме йому. Але якщо використовувати всередині збереженої процедури:
SELECT @uname = user;
Те, якщо користувач не власник цієї функції, @uname = "dbo". Мабуть, це виникає через те, що збережена процедура запускається не під моїм користувачем, а під dbo.
Підкажіть, будь ласка, як в збереженій процедурі отримати саме ім'я користувача, який її викликав? Або обхідний варіант: наприклад, запустити процедуру звідкись, передавши їй ім'я користувача в якості аргументу (але тільки не з Delphi :), тому що повинна забезпечуватися захист, щоб користувач міг отримати тільки свої рядки з таблиць).
> GRANT?
Тут я не розібрався. Права поміняти можна, але складність якраз полягала в тому, що я не знав, який користувач запустив процедуру.
Подивися за довідкою, а то там є їх кілька
> Подивися за довідкою, а то там є їх кілька
SUSER_SNAME () - ця функція повертає логін по security identification number (SID).
SUSER_NAME () - а ця функція повертає логін по login identification number
Але про SUSER_NAME написано:
"SUSER_NAME returns a login name only for a login that has an entry in the syslogins system table."
так що напевно краще її не використовувати, тому що в довідці написано, що syslogins застаріла і поки що замінена на view, і краще її не використовувати в нових розробках.
А в довідці по SUSER_SNAME () я заплутався в контекстах :)
When called without an argument, SUSER_SNAME returns the name of the current security context. When called without an argument within a batch that has switched context by using EXECUTE AS, SUSER_SNAME returns the name of the impersonated context. When called from an impersonated context, ORIGINAL_LOGIN returns the name of the original context.
Тому я вирішив використовувати ORIGINAL_LOGIN ().
Підкажіть, будь ласка, це правильно. Я не наткнуся з нею на подвождние камені?
Напевно, буду тоді використовувати ORIGINAL_LOGIN.
> SUSER_SNAME () - ця функція повертає логін по security
> Identification number (SID).
> SUSER_NAME () - а ця функція повертає логін по login identification
> number
Спробуй не вказувати SID, строго як у мене написано, без самодіяльності.
Можеш написати так
зауваження
Ця функція може бути корисною для аудиту ідентифікатора вихідного контексту підключення. Так як інші функції, такі як SESSION_USER і CURRENT_USER, повертають поточний виконуючий контекст, ORIGINAL_LOGIN повертає ідентифікатор імені входу, першим підключився до примірника SQL Server в даному сеансі.
приклади
Наступний приклад перемикає виконуючий контекст поточного сеансу від того, хто викликав дані інструкції, на login1. Функції SUSER_SNAME і ORIGINAL_LOGIN використовуються для повернення користувача поточного сеансу (користувача, на якого переключається контекст) і вихідної облікового запису імені входу.
Якщо у тебе перемикається контекст, то краще CURRENT_USER
> Спробуй не вказувати SID, строго як у мене написано, без
> Самодіяльності.
Якщо не вказувати, то у мене одне й те саме повертають: логін поточного користувача.
Використовуй SUSER_SNAME це переносимо і є аліасом по суті.
Ти ее це і просив, якщо не враховувати перемикання контексту.
> Використовуй SUSER_SNAME це переносимо і є аліасом
> По суті.
Дякуємо. Тоді буду використовувати його.
PS: тим більше, що для того, щоб змінити SUSER_SNAME, користувачеві, напевно, все одно потрібно знати пароль до нового логіну. А якщо він його знає, то і ORIGINAL_LOGIN не врятує.
Використання EXECUTE AS CALLER як ізольованою інструкції
EXECUTE AS CALLER можна виконувати в модулі як ізольованою інструкції для перемикання контексту виконання на користувача, що викликає модуль.
Розглянемо наступну збережену процедуру під назвою SqlUser2.
ORIGINAL_LOGIN не врятує у нього інше призначення показати логін з яким
користувач почав сесію, для контексту в цьому випадку потрібно використовувати
CURRENT_USER
У MSSQL великий набір функцій і їх варіантів.