Cum să aflați datele de conectare în care clientul a introdus MS SQL?
Vreau să pun în aplicare un astfel de mecanism: clientul (programul Delphi sau altcineva) nu are acces la unele tabele SQL SERVER. Dar aceasta numește o procedură stocată, care, date fiind login-ul ei (și este același cu contul Windows), îi oferă înregistrările din tabelele care sunt destinate pentru aceasta. Dar dacă utilizați în interiorul unei proceduri stocate:
SELECT @uname = utilizator;
Dacă utilizatorul nu deține această funcție, @uname = "dbo". Aparent, aceasta se datorează faptului că procedura stocată nu este lansată sub utilizatorul meu, ci sub dbo.
Spuneți-mi, vă rog, cum în procedura stocată să obțineți exact numele utilizatorului care l-a numit? Sau o soluție: de exemplu, porniți procedura de undeva, trecând numele de utilizator ca argument (dar nu de la Delphi :), deoarece protecția trebuie asigurată astfel încât utilizatorul să poată obține numai rândurile proprii din tabele).
> GRANT?
Nu am înțeles. Puteți schimba permisiunile, însă dificultatea a fost că nu știam care dintre utilizatori a pornit procedura.
Uită-te la ajutor, și apoi mai sunt câteva
> Uită-te la ajutor, și apoi mai sunt câteva
SUSER_SNAME () - această funcție returnează datele de conectare pentru numărul de identificare a securității (SID).
SUSER_NAME () - și această funcție returnează datele de conectare după numărul de identificare al accesului
Dar despre SUSER_NAME se spune:
"SUSER_NAME returnează un nume de conectare numai pentru un login care are o intrare în tabelul de sistem syslogins."
deci este mai bine sa nu o folositi, pentru ca în ajutor este scris că sysloginul este depășit și până acum a fost înlocuit cu viziune și este mai bine să nu o folosiți în noile evoluții.
Și în ajutor pe SUSER_SNAME () am confundat în context :)
Când este apelat fără un argument, SUSER_SNAME returnează numele contextului de securitate curent. Când este apelat fără un argument într-un lot care a schimbat contextul utilizând EXECUTE AS, SUSER_SNAME returnează numele contextului de identitate. Atunci când este apelat dintr-un context de identitate, ORIGINAL_LOGIN returnează numele contextului original.
Așa că am decis să folosesc ORIGINAL_LOGIN ().
Spune-mi, te rog, este corect. Nu o să mă duc la ea pe blocurile de poticnire?
Probabil că voi folosi ORIGINAL_LOGIN.
> SUSER_SNAME () - această funcție returnează autentificarea pentru securitate
> numărul de identificare (SID).
> SUSER_NAME () - și această funcție returnează datele de conectare prin identificarea de conectare
> număr
Încercați să nu specificați SID-ul, strict așa cum l-am scris, fără autoactivitate.
Puteți scrie astfel
observații
Această funcție poate fi utilă pentru verificarea identificatorului contextului original de conectare. Din moment ce alte funcții, cum ar fi SESSION_USER și CURRENT_USER, returnează contextul de executare actual, ORIGINAL_LOGIN returnează ID de conectare, conectați mai întâi la instanța de SQL Server în această sesiune.
exemple
Următorul exemplu comută contextul de execuție al sesiunii curente de la cel care a apelat aceste instrucțiuni la login1. Funcțiile SUSER_SNAME și ORIGINAL_LOGIN sunt utilizate pentru a returna utilizatorul sesiunii curente (utilizatorul la care se comută contextul) și contul inițial al numelui de conectare.
Dacă schimbați contextul, este mai bine CURRENT_USER
> Încercați să nu specificați SID, strict așa cum am scris, fără
> performanță amator.
Dacă nu specific, atunci am același randament: login-ul utilizatorului curent.
Utilizați SUSER_SNAME este portabil și este un alias în esență.
Nu ați cerut acest lucru, dacă nu luați în considerare schimbarea contextului.
> Utilizați SUSER_SNAME este portabil și este un alias
> de fapt.
Mulțumesc. Atunci o voi folosi.
PS: cu atât mai mult, pentru ca, pentru a schimba SUSER_SNAME, probabil că utilizatorul trebuie să cunoască parola pentru noul login. Și dacă o știe, atunci ORIGINAL_LOGIN nu va salva.
Folosind EXECUTE AS CALLER ca o instrucțiune izolată
EXECUTE AS CALLER poate fi executat în modul ca o instrucțiune izolată pentru comutarea contextului de execuție către utilizatorul care apelează modulul.
Luați în considerare următoarea procedură stocată numită SqlUser2.
ORIGINAL_LOGIN nu-l va salva alt scop pentru a afișa datele de conectare cu care
utilizatorul a început sesiunea, pentru contextul în care trebuie să îl utilizați
CURRENT_USER
În MSSQL, un set mare de funcții și opțiunile acestora.