Autoryzacja i zarządzanie użytkownikami

Czytałem dokumentację, widziałem przykłady, ale wciąż nie potrafię sobie wyobrazić jak osiągnąć pewną rzecz, mianowicie:

• tworzę aplikację, która na starcie posiada ekran logowania
• login i hasło do aplkacji jest jednocześnie logiem i hasłem do bazy danych
• taki użytkownik po zalogowaniu się posiada możliwość zmiany hasła
• posiada równięż możliwość dodania nowych użytkowników o przywilejach nie większych niż sam posiada

Czyli taki lokalny szeryf, władca namespace'a, bo tylko w danej przestrzeni nazw będzie mógł robić coś więcej niż select ;)

Da rade coś takiego wyczarować?

login i hasło do aplkacji jest jednocześnie logiem i hasłem do bazy danych

Ale... dlaczego? Który z diabełków Ci coś takiego podpowiedział?

Po głębszym zastanowieniu, to rzeczywiście może nie jest to najlepszy pomysł.

Ehh, człowiek to czasem ślepy jest

Database superusers can change any of these settings for any role. Roles having CREATEROLE privilege can change any of these settings, but only for > non-superuser roles. Ordinary roles can only change their own password.

Tylko, że gdzieś czytałem(o tu), że jak się przy tworzeniu roli poda parametr CREATEROLE to taka rola automatycznie zyskuje prawa superusera. Co prawda to się odnosi do wersji 8.3. Dalej tak jest?

Zapomnij o CREATE ROLE po jednorazowym użyciu. Tworzysz JEDNEGO usera i tworzysz swoją tabelkę z userami oraz prawami. KONIEC

A można coś więcej? Bo przyznam się bez bicia, że nie wiem na jakiej zasadzie miałoby to działać.

ale co nie wiesz na jakiej zasadzie ma to działać? Przecież to Ty piszesz aplikację więc będzie działało dokładnie tak jak sobie wymyślisz i zaimplementujesz. Łączenie usera do bazy i do programu to zły pomysł, jeszcze gorszy to próba nadawania uprawnień w programie przez ograniczanie praw do odczytu/zapisu w bazie. Generalnie prawa do aplikacji powinny być na poziomie aplikacji a nie bazy.

A w czym piszesz aplikację? Wiele języków ma gotowe biblioteki do zarządzania użytkownikami i ich rolami, może spróbuj jakiejś użyć.

abrakadaber napisał(a):

ale co nie wiesz na jakiej zasadzie ma to działać?

Zapytałem się o to jak móc tworzyć użytkowników, którzy sami również będą mogli dodawać użytkowników itp. itd. W odpowiedzi @Marcin.Miga napisał, żeby stworzyć tylko jedną role a resztę ogarniać za pomocą jakiejś 'własnej tabelki'. Chciałem po prostu się dowiedzieć jak to ma działać i skąd niechęć do CREATE ROLE.

somekind napisał(a):

A w czym piszesz aplikację? Wiele języków ma gotowe biblioteki do zarządzania użytkownikami i ich rolami, może spróbuj jakiejś użyć.

C++ w wersji Qt ;)

Ale temat już zgłębiłem, przetestowałem i wydaje mi się, że wsio panimaju :)

To nie chodzi o to, że jest niechęć do rol SQL-owych. Po prostu dużo łatwiej się zarządza "własnymi" rolami. Załóżmy, że masz moduł raportowy. Jedni mają widzieć analitykę, inni syntetykę, a jeszcze inni wcale. Jak to załatwisz rolami SQLowymi? Będziesz tabelki z takimi danymi robił? Bez sensu.
No i poza tym ukłon w stronę Administratorów. Przy dużej rotacji pracowników mogą nie ogarnąć, kto jeszcze powinien mieć dostęp i jaki, a kto nie.