login/user sql serwer

Odpowiedz Nowy wątek
2017-06-26 17:47
0

Witam. Mam sql serwera w którym mam bazę i w niej użytkownika "superadmin".
Mam także poziom wyżej zdefiniowany login o tej samej nazwie.

Jak klikam na właściwości usera to w zakładce general (sql studio) mam pole login name : także superadmin.
Dlaczego jak blokuję ("deny") w zakładce "securables" usera superadmin operacje typu select i zatwierdzam to ciągle mogę je wykonywać ?
Ma to coś wspólnego z domyślnym schematem którym jest "dbo"... ?

Dodatkowo w polu "grantor" zakładki securables podzakładki explicit właściwości usera mam dwa selecty (jeden z niewypełnionym grantor , drugi z grantorem jako dbo) - czemu jak zaznaczam "deny" na obydwu z nich to tylko jeden z nich zostaje permanentnie zapamiętany, flaga założona na tego pierwszego selecta nic nie daje i nie zostaje tam zapamiętana pomimo iż oczywiście daje zapisz...?

Pozostało 580 znaków

2017-06-28 07:37
1

Czesc,
po tym jak wylogowałeś się z bazy i zalogowaleę ponownie jako twoj superadmin, wciąż możesz wykonywać selecty? A jak dodałeś obiekty(tabele, cała baza), które mają mieć szczegółowe prawa? Bo może dodałeś po tabeli, wtedy tylko taki zasięg bedą miały twoje ustawienia. W screenie masz na przykładzie tabel. Baza ma dwie, ale w widoku widzisz jedną, bo na drugiej nie możesz wykonywac operacji typu select.
A co do "dwóch selectów", to oczywiście że zostaje zapisany, tylko po ponownym otwarciu okna niekoniecznie widzisz haczyk tam gdzie go oczekujesz. Sprawdż co się dzieje z ustawieniem grantor;)
Połącz się w studio dwa razy do bazy, raz z prawdziwym adminem drugi raz z twoim testowym użytkownikiem. Wówczas będziesz mógł "on the fly" testować zmiany praw dostępu wykonane przez admina. Wystarczy zrobić refresh widoku bazy. Tabele na których użytkownik testowy (twój superadmin) nie ma praw testowych po prostu się nie pojawią.


The only valid measurement of code quality: WTFs/min...

Pozostało 580 znaków

2017-06-28 07:42

hmmm, właśnie zauważyłem twój wcześniejszy post. Jesli to ma być aplikacja, która się łączy z bazą, to powinieneś skorzystać z rad forumowiczów. Somekind ma rację - w takim przypadku program powinien być użytkownikien i w aplikacji zdefiniuj mechanizmy/prawa dostepu.


The only valid measurement of code quality: WTFs/min...

Pozostało 580 znaków

2017-06-28 10:11
0

Udało mi się to ogarnąć, prawa dostępu zdefiniowałem jako role i przypisałem po jednej roli do każdego Usera. Userów jest tyle ile jest loginów, co odpowiada jeden do jednego i wszystko działa jak należy. Dzięki za podpowiedzi, co do tego gdzie definiować mechanizm uprawnień to rozwiązałem to właśnie nie od strony aplikacji tylko serwera, aplikacja na początku pyta użytkownika o login i hasło i dopiero na podstawie wprowadzonych danych bierze i tworzy connection stringa i próbuje się na niego zalogować. na razie nie jestem przekonany że porada mówiąca o tym że uprawnienia mają być definiowane w aplikacji jest słuszna, mało tego uważam że moje rozwiązanie jest lepsze dlatego że gdyby przyjąć że ktoś kto dostaje ode mnie aplikację i login umożliwiający mu praktycznie wszystko (pełne uprawnienia od strony serwera) może (oczywiście jeśli by tylko potrafił i chciał ;) ) zniszczyć mi bazę chociażby poprzez zalogowanie się na tego usera z poziomu sql studia. A tak, dostaje tylko login który umożliwia mu wykonanie wybiórczych operacji, mało tego aplikacja do bazy jeśli coś wkłada (insert) to zapisuje (w innej kolumnie tabel) kto to robi poprzez identyfikator (int) powiązany z loginem i nie dość że nad bazą mam pełną kontrolę to jeszcze wiem kto co na niej wykonał (np. monter zmontował produkt i wrzucił go insertem do tabeli Products).
Może to wszystko trochę nieskładnie brzmi i pewnie czasem ciężko się domyślić co autor miał na myśli, ale ważne jest to że sobie poradziłem i doszedłem do pewnych wniosków. Chciałbym serdecznie podziękować za pomocną dłoń ;)
PS. W tamtym poście który oglądałeś później, napisałem też trochę na ten temat. Pozdrawiam!

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0