epsilon$ while read LINE; do echo \>"$LINE"; done < "Marek Borowski"
>>>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje
>>>> "Uwierzytelnianie"!
>>> Slusznie - aczkolwiek "autentykacja" wydaje mi sie na tyle juz powszechnie
>>> uzywana kalka,
>> Nie. Nadal używana jest tylko przez laików. Poprawnym terminem cały czas
>> jest "uwierzytelnianie".
>Sam jestes laikiem. Formy zagielszczone to norma. Polonista sie
>znalazl. Przez takich jak ty mielibysmy miedzymordzie zamiast interfejsu.

Bzdura. Po pierwsze - nie "formy zangielszczone", tylko w drugą stronę -
niektórzy usiłują na siłę polonizować anglicyzmy.
Po drugie - stosowanie słów zapożyczonych z obcych języków ma sens tam,
gdzie polskiego odpowiednika (czasem s/polskiego/dobrego &/) nie ma - na
przykład przytoczony przez ciebie "interfejs".
A "autentykacja" jest albo wyrazem ignorancji, albo udawania
"światowca".

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,38804171
| http://epsilon.eu.org/ |
/------------------------\

do góry

Dnia Wed, 29 Jun 2011 08:09:21 +0200, Mariusz Kruk napisał(a):

> epsilon$ while read LINE; do echo \>"$LINE"; done < "Marek Borowski"
>>>>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje
>>>>> "Uwierzytelnianie"!
>>>> Slusznie - aczkolwiek "autentykacja" wydaje mi sie na tyle juz powszechnie
>>>> uzywana kalka,
>>> Nie. Nadal używana jest tylko przez laików. Poprawnym terminem cały czas
>>> jest "uwierzytelnianie".
>>Sam jestes laikiem. Formy zagielszczone to norma. Polonista sie
>>znalazl. Przez takich jak ty mielibysmy miedzymordzie zamiast interfejsu.
>
> Bzdura. Po pierwsze - nie "formy zangielszczone", tylko w drugą stronę -
> niektórzy usiłują na siłę polonizować anglicyzmy.
> Po drugie - stosowanie słów zapożyczonych z obcych języków ma sens tam,
> gdzie polskiego odpowiednika (czasem s/polskiego/dobrego &/) nie ma - na
> przykład przytoczony przez ciebie "interfejs".
> A "autentykacja" jest albo wyrazem ignorancji, albo udawania
> "światowca".

Zgadzam sie, ale czy interfejs, to nie czasami przylacze?

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Jacek"
>>>>>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje
>>>>>> "Uwierzytelnianie"!
>>>>> Slusznie - aczkolwiek "autentykacja" wydaje mi sie na tyle juz powszechnie
>>>>> uzywana kalka,
>>>> Nie. Nadal używana jest tylko przez laików. Poprawnym terminem cały czas
>>>> jest "uwierzytelnianie".
>>>Sam jestes laikiem. Formy zagielszczone to norma. Polonista sie
>>>znalazl. Przez takich jak ty mielibysmy miedzymordzie zamiast interfejsu.
>> Bzdura. Po pierwsze - nie "formy zangielszczone", tylko w drugą stronę -
>> niektórzy usiłują na siłę polonizować anglicyzmy.
>> Po drugie - stosowanie słów zapożyczonych z obcych języków ma sens tam,
>> gdzie polskiego odpowiednika (czasem s/polskiego/dobrego &/) nie ma - na
>> przykład przytoczony przez ciebie "interfejs".
>> A "autentykacja" jest albo wyrazem ignorancji, albo udawania
>> "światowca".
>Zgadzam sie, ale czy interfejs, to nie czasami przylacze?

Nie do końca. "Interfejs" może definiować dużo więcej niż tylko samo
fizyczne złącze.

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,38804171
| http://epsilon.eu.org/ |
/------------------------\

do góry

On 29/06/2011 07:09, Mariusz Kruk wrote:
> epsilon$ while read LINE; do echo \>"$LINE"; done< "Marek Borowski"
>
>> Sam jestes laikiem. Formy zagielszczone to norma. Polonista sie
>> znalazl. Przez takich jak ty mielibysmy miedzymordzie zamiast interfejsu.
>
> Bzdura. Po pierwsze - nie "formy zangielszczone", tylko w drugą stronę -
> niektórzy usiłują na siłę polonizować anglicyzmy.
> Po drugie - stosowanie słów zapożyczonych z obcych języków ma sens tam,
> gdzie polskiego odpowiednika (czasem s/polskiego/dobrego&/) nie ma - na
> przykład przytoczony przez ciebie "interfejs".
> A "autentykacja" jest albo wyrazem ignorancji, albo udawania
> "światowca".

Jest wyrazem ignorancji. Ale ignorancją jest też nie wiedzieć, jak się
uwierzytelnianie nazywa np. po łotewsku, co nie znaczy, że każdy, kto
tego nie wie, jest laikiem w dziedzinie. Prawda jest taka, że da się - i
często się tak robi - zajmować zawodowo tematami IT bez używania
polskiej terminologii. Nawet pracując w Polsce i z Polakami, znajomość
polskiej terminologii jest zbędna: wszyscy i tak jakośtam znają
angielski, dokumentacja jest po angielsku, literatura jest po angielsku,
jeśli się użyje angielskiego terminu lub angielskiej kalki, to wszyscy
zrozumieją. Można być spokojnie ekspertem w danym temacie i nie wiedzieć
jaki jest polski termin, a co więcej - nie potrzebować go.

do góry

W dniu 2011-06-29 01:11, Lukasz pisze:
> W takim że gruby może więcej, więc trochę łatwiej dobrać się do danych.
> Cienki nie wie prawie nic, wtedy aplikację serwera trzeba odpowiednio
> zabezpieczyć.

Jak dla mnie, taki klient tez musi wiedzieć jedną najważniejszą rzecz
żeby w ogóle móc pracować - wiedzieć jak się podłączyć do serwera. A
mając taką informację mamy już połowę drogi za sobą :)

> Nie ma stuprocentowych zabezpieczeń - z tym się zgadzam. Chyba wiem o co
> Ci chodzi. Jak będę miał do wykonania aplikacji to wtedy posiedzę nad
> kwestią bezpieczeństwa. Na pewno grupa dyskusyjna dała mi trochę do
> myślenia. Sądzę jednak że to co wymyśliłem jest jednak lepsze niż np.
> trzymanie hasła i loginu w pliku konfiguracyjnym aplikacji i jedynie
> sprawdzanie w kodzie flagi od uprawnień, którą można łatwo zmanipulować.

Jeśli hasło i login jest odpowiednio zaszyfrowane to nie jest źle :)
Wiedz że dla Ciebie coś może wydawać się proste, bo wiesz gdzie to jest.
Osoba z zewnątrz ma gorzej bo musi znaleźć to coś i jeszcze załapać do
czego to służy :)

Ale ogólnie chodziło mi raczej o fakt, że lepiej dobierać architekturę i
rozwiązania do konkretnego problemu. Bo czasami tworzenie aplikacji
trójwarstwowej z mocnymi zabezpieczeniami może okazać się wielokrotnie
droższe od wartości funkcjonalnej danej aplikacji. I to jest bardziej
racjonalne podejście niż robienie wszystkiego w jakiejś
technologii/architekturze bo tak w danym momencie jest zgodne z trendami :/

pozdrawiam,
Przemek O.

do góry

Zbigniew Malec wrote:

> On Tue, 28 Jun 2011 17:00:07 +0200, Michal Kleczek wrote:
>
>>> Bo granulacja kontroli dostępu w DBMS często nie przystaje do granulacji
>>> potrzebnej do implementacji kontroli dostępu.
>>
>> I to jest czesto dobry argument.
>> Z drugiej strony mozna sie zastanawiac, czy moze inny (oferujacy
>> odpowiednie narzedzia/granulacje) DBMS jest lepszym rozwiazaniem?
>> Oraz czy przypadkiem _rzeczywiscie_ nie przystaje.
>
> Nie ma co tego na DBMSa zwalać, bo zwyczajnie nie jesteś w stanie osiągnąć
> wystarczającej elastyczności.

Tzn. czego np?
Dobry DBMS oferuje duza elastycznosc jesli chodzi o zarzadzanie dostepem do
danych - w koncu to system zarzadzania bazami danych.
Taki Oracle daje chocby VPD.
Ale i bez tego daje sie sporo osiagnac - chocby:
http://technet.microsoft.com/en-us/library/cc966395.
aspx

> Moduł zarządzania użytkownikami DBMS jest
> projektowany pod zupełnie inne zastosowania i jako taki nie nadaje się do
> wykorzystania w aplikacji.

A to niby dlaczego?
Wydaje mi sie, ze jest dokladnie odwrotnie - modul zarzadzania uprawnieniami
w DBMS jest projektowany dokladnie po to, zeby wielu uzytkownikow moglo
korzystac z roznych (przeznaczonych dla nich) podzbiorow danych w bazie
danych.

> Użytkownicy aplikacji to są "dane", a nie
> element funkcjonalny bazy.

A to niby dlaczego?

> Podstawowym kryterium wyboru DBMS na pewno nie
> jest to, czy można użyć jego modułu zarządzania użytkownikami w swojej
> aplikacji.
>

Jest jednym z wielu kryteriow, ktore wynikaja z wymagan dot. sytemu.

>>> Jak chcesz zorganizować
>>> prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
>>> tylko klientem dla opiekuna tego klienta?
>>>
>>
>> Chocby widoki?
>
> Można, ale po co? Żeby osiągnąć odpowiednią elastyczność i tak będziesz
> musiał dobudować tyle infrastruktury, że dodatkowa tabelka z użytkownikami
> nie robi żadnej różnicy.
>

Nie bardzo rozumiem o co chodzi z ta dodatkowa tabelka z uzytkownikami.
Natomiast jesli chodzi o "dobudowe infrastruktury", to i tak musisz _gdzies_
te zabezpieczenia zaimplementowac. Moim zdaniem:
1) Bedzie taniej wykorzystac to, co juz jest zaimplementowane w DBMS
2) Bedzie _bezpieczniej_ uzywac zabezpieczen w DBMS, bo wszelkie rozwiazania
"custom made" w aplikacji nie moga byc tak dobrze zweryfikowane pod katem
bezpieczenstwa jak DBMS z polki.

>>>> Wielokrotnie uzywalem narzedzi w rodzaju np. SQL Navigator lub Crystal
>>>> Reports do dostepu do danych w srodowiskach gdzie nie do wszystkich
>>>> danych w bazie danych moglem miec dostep. Mialem swoje konto w DBMS z
>>>> przypisanymi uprawnieniami i tyle.
>>>
>>> Nie rozumiem. Miałeś nie mieć dostępu w aplikacji FooBarBaz do pewnych
>>> danych, ale uzyskiwałeś go bo łączyłeś się z bazą ręcznie zamiast używać
>>> FooBarBaz?
>>>
>>
>> Mialem nie miec dostepu do pewnych danych _niezaleznie_ od tego jakiej
>> aplikacji uzywam do dostepu.
>> Podobnie jak mam nie miec dostepu do danych w katalogu /home/iksinski
>> niezaleznie od aplikacji jakiej uzywam.
>
> W przypadku osób generujących raporty z bazy, albo w inny sposób
> korzystających bezpośrednio z danych zawartych w bazie danych naturalne
> jest korzystanie z użytkowników bazodanowych. W przypadku aplikacji
> korzystającej z tych danych za pośrednictwem serwera aplikacji (albo
> grubego klienta) już takie naturalne to nie jest, bo użytkownik jest od
> tej bazy odseparowany i jego tożsamość, to jest tylko kojelny parametr w
> wykonywanych zapytaniach, a nie element funkcjonalny aplikacji.

Sa przynajmniej dwa problemy z tym rozumowaniem:
1. To jest tylko przesuniecie rozwiazania problemu z DBMS do aplikacji.
Klopot polega na tym, ze weryfikacja oprogramowania pod katem bezpieczenstwa
jest droga i co za tym idzie aplikacja jest znacznie bardziej narazona na
bledy niz DBMS (najlepszym przykladem sa wszystkie ataki typu SQL injection
- wbudowanie zabezpieczen w DBMS chroni dane przed atakami wykorzystujacymi
bledy w aplikacjach).
2. W przypadku aplikacji typu "gruby klient" - jak zapewnic, ze dostep do
danych bedzie sie odbywal _tylko_ przy pomocy tejze aplikacji?
3. Jak rozwiazac problem wielu aplikacji korzystajacych z jednej bazy
danych. Kazda ma swoj wlasny system zabezpieczen?

>
>> W wiekszosci zastosowan komputerow przedmiotem ochrony sa _dane_ (pomijam
>> przypadki, gdzie chroni sie dostep np. do zewnetrznych urzadzen).
>> Z punktu widzenia bezpieczenstwa danych zezwolenie na to, zeby kazda
>> aplikacja definiowala _swoj wlasny_ model ochrony danych jest ryzykowny.
>
> Rezygnację całkowitą z uprawnień nadawanych przez DB można uznać za
> nierozsądną, ale nie można też popadać w przesadę. Typowy wzorzec ich
> wykorzystania to tworzenie użytkowników pod dane aplikacje i udostępnianie
> tym użytkownikom pewnego podzbioru obiektów w bazie. Pozdbiór ten w
> założeniach ma tworzyć spójne API dostępu do danych z punktu widzenia
> danej aplikacji.
> Ja bym wręcz zaryzykował twierdzenie, że utożsamianie użytkowników
> aplikacji z użytkownikami DB zmniejsza bezpieczeństwo, bo zamiast mieć
> jednego dobrze opisanego użytkownika na poziomie bazy danych (a więc w
> warstwie dostępu do danych), trzeba dbać o poprawne opisanie wszystkich
> jej (aplikacji) użytkowników.

Od tego DBMS maja na przyklad RBAC lub inne mechanizmy ulatwiajace
zarzadzanie uprawnieniami i uzytkownikami (grupy itp). Niczym sie to nie
rozni od zabezpieczania dostepu do danych na dyskach sieciowych (w koncu
system plikow to taki DBMS).

> W opisanym przeze mnie typowym przypadku
> uprawnienia użytkowników aplikacji są odseparowane od uprawnień samej
> aplikacji a co za tym idzie łatwiej jest postawić wyraźną granicę, co
> aplikacji wolno a czego jej nie wolno.
>

Ale jak zapewnic separacje uprawnien uzytkownikow w ramach aplikacji majacej
(z powodu wymagan funkcjonalnych) dostep do zbioru danych bedacego
nadzbiorem danych dostepnych kazdemu uzytkownikowi tejze aplikacji? To tylko
przesuniecie problemu i - poprzez wprowadzenie kolejnego mechanizmu
zabezpieczen - niepotrzebna komplikacja systemu.

--
Michal

do góry

On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
> Stachu 'Dozzie' K. wrote:
>
>> On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
>> [...]
>>>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje i autoryzacje oraz
>>>>> oferuje narzedzia do zarzadzania kontami uzytkownikow oraz
>>>>> uprawnieniami. Niektore posiadaja nawet mozliwosc integracji z
>>>>> zewnetrznymi systemami typu LDAP/Kerberos oferujac single sign-on.
>>>>> Czemu z nich nie skorzystac?
>>>>
>>>> Bo nie służą do kontroli dostępu na poziomie aplikacji używającej
>>>> danych.
>>>
>>> Dlaczego?
>>
>> Bo granulacja kontroli dostępu w DBMS często nie przystaje do granulacji
>> potrzebnej do implementacji kontroli dostępu.
>
> I to jest czesto dobry argument.
> Z drugiej strony mozna sie zastanawiac, czy moze inny (oferujacy odpowiednie
> narzedzia/granulacje) DBMS jest lepszym rozwiazaniem?

Z reguły nie dobiera się silnika bazodanowego ze względu na uprawnienia
jakie oferuje. Zresztą wszystkie silniki oferują podobne uprawnienia.

>> Jak chcesz zorganizować
>> prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
>> tylko klientem dla opiekuna tego klienta?
>>
>
> Chocby widoki?

I co, osobny widok dla każdego klienta? Super. Tylko wiesz że tym by się
tragicznie zarządzało?

>>> Wielokrotnie uzywalem narzedzi w rodzaju np. SQL Navigator lub Crystal
>>> Reports do dostepu do danych w srodowiskach gdzie nie do wszystkich
>>> danych w bazie danych moglem miec dostep. Mialem swoje konto w DBMS z
>>> przypisanymi uprawnieniami i tyle.
>>
>> Nie rozumiem. Miałeś nie mieć dostępu w aplikacji FooBarBaz do pewnych
>> danych, ale uzyskiwałeś go bo łączyłeś się z bazą ręcznie zamiast używać
>> FooBarBaz?
>>
>
> Mialem nie miec dostepu do pewnych danych _niezaleznie_ od tego jakiej
> aplikacji uzywam do dostepu.
> Podobnie jak mam nie miec dostepu do danych w katalogu /home/iksinski
> niezaleznie od aplikacji jakiej uzywam.

Czyli ktoś zjebał aplikację, że mogłeś się do tych danych dokopać.
Mianowicie błąd był w tym, że mogłeś się w ogóle połączeć z bazą danych.

>>> Powiedzialbym wrecz, ze system w ktorym rezygnuje sie z wbudowanych w
>>> DBMS mechanizmow zabezpieczen na rzecz tych wbudowanych w aplikacje jest
>>> z punktu widzenia bezpieczenstwa gorszy.
>>
>> Chyba że jest lepszy, bo uprawnienia lepiej odzwierciedlają do czego
>> ktoś ma dostać prawa.
>>
>
> W wiekszosci zastosowan komputerow przedmiotem ochrony sa _dane_ (pomijam
> przypadki, gdzie chroni sie dostep np. do zewnetrznych urzadzen).
> Z punktu widzenia bezpieczenstwa danych zezwolenie na to, zeby kazda
> aplikacja definiowala _swoj wlasny_ model ochrony danych jest ryzykowny.

Erm. To może zdefiniuj jeden model ochrony dla całego komputera
i przestań się przejmować co która aplikacja robi? Przecież to
niedorzeczny postulat.

>>>> Służą do tego, żeby w sieci, gdzie serwerów bazodanowych jest
>>>> dużo, administratorzy i analitycy mogli połączyć się z bazami pod swoją
>>>> opieką, ale już nie z cudzymi.
>>>>
>>>
>>> Uwaga o single sign-on byla troche "na boku" - aczkolwiek wcale nie
>>> uwazam, zeby single sign-on byl uzyteczny tylko dla administratorow.
>>
>> A ja się odniosłem do centralizacji zarządzania uwierzytelnianiem.
>>
>> Uprawnienia w bazie danych nie służą do kontroli dostępu w aplikacji, bo
>> nie mają odpowiedniej granulacji i zarządzanie nimi jest trudne dla
>> osoby nietechnicznej.
>>
>
> Tego nie rozumiem - albo:
> 1) mamy administratora DBMS, ktory jest osoba techniczna

Chyba że nie mamy, bo to mała firemka z małym systemikiem do
fakturowania.

> 2) tworzymy narzedzia, ktore ulatwiaja osobom nietechnicznym zarzadzanie
> uprawnieniami.

Tylko że stworzenie takich narzędzi dla na przykład baz SQL-owych jest
trudne.

> W obydwu przypadkach nie widac powodu, zeby rezygnowac z tego, co oferuje
> DBMS.

W obydwu przypadkach nie widać możliwości, żeby używać tego, co oferuje
DBMS w zakresie autoryzacji, w samej aplikacji.

--
Secunia non olet.
Stanislaw Klekot

do góry

Stachu 'Dozzie' K. wrote:

> On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
>>
>> I to jest czesto dobry argument.
>> Z drugiej strony mozna sie zastanawiac, czy moze inny (oferujacy
>> odpowiednie narzedzia/granulacje) DBMS jest lepszym rozwiazaniem?
>
> Z reguły nie dobiera się silnika bazodanowego ze względu na uprawnienia
> jakie oferuje.

Dlaczego?

> Zresztą wszystkie silniki oferują podobne uprawnienia.
>

Nie - taki np. Oracle Advanced Security option oferuje znacznie wiecej niz
dajmy na to Postgresql. A Postgresql oferuje wiecej niz MySQL.
Oczywiscie - za Oracle trzeba zaplacic. Pytanie tylko, czy zrobienie tego w
aplikacji nie bedzie drozsze niz koszt licencji dobrego DBMS.

>>> Jak chcesz zorganizować
>>> prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
>>> tylko klientem dla opiekuna tego klienta?
>>>
>>
>> Chocby widoki?
>
> I co, osobny widok dla każdego klienta? Super. Tylko wiesz że tym by się
> tragicznie zarządzało?
>

Przez "klienta" rozumiesz aplikacje czy uzytkownika?
Zreszta niezaleznie od tego nie ma potrzeby tworzyc oddzielnych widokow dla
kazdego klienta. Przeczytaj np:
http://technet.microsoft.com/en-us/library/cc966395.
aspx

>>>> Wielokrotnie uzywalem narzedzi w rodzaju np. SQL Navigator lub Crystal
>>>> Reports do dostepu do danych w srodowiskach gdzie nie do wszystkich
>>>> danych w bazie danych moglem miec dostep. Mialem swoje konto w DBMS z
>>>> przypisanymi uprawnieniami i tyle.
>>>
>>> Nie rozumiem. Miałeś nie mieć dostępu w aplikacji FooBarBaz do pewnych
>>> danych, ale uzyskiwałeś go bo łączyłeś się z bazą ręcznie zamiast używać
>>> FooBarBaz?
>>>
>>
>> Mialem nie miec dostepu do pewnych danych _niezaleznie_ od tego jakiej
>> aplikacji uzywam do dostepu.
>> Podobnie jak mam nie miec dostepu do danych w katalogu /home/iksinski
>> niezaleznie od aplikacji jakiej uzywam.
>
> Czyli ktoś zjebał aplikację, że mogłeś się do tych danych dokopać.
> Mianowicie błąd był w tym, że mogłeś się w ogóle połączeć z bazą danych.
>

Wrecz przeciwnie - bylo wszystkim znacznie latwiej, bo uprawnieniami dostepu
do danych zarzadzalo sie w jednym miejscu i nikogo nie obchodzilo w jaki
sposob (przy uzyciu jakiego oprogramowania) do tych danych sie dostawalem.
Mogla to byc nawet "zjebana aplikacja".

>>
>> W wiekszosci zastosowan komputerow przedmiotem ochrony sa _dane_ (pomijam
>> przypadki, gdzie chroni sie dostep np. do zewnetrznych urzadzen).
>> Z punktu widzenia bezpieczenstwa danych zezwolenie na to, zeby kazda
>> aplikacja definiowala _swoj wlasny_ model ochrony danych jest ryzykowny.
>
> Erm. To może zdefiniuj jeden model ochrony dla całego komputera
> i przestań się przejmować co która aplikacja robi? Przecież to
> niedorzeczny postulat.
>

Codziennie lacze sie po ssh z komputerem uzywanym jednoczesnie przez wielu
uzytkownikow i nie mam dostepu do danych do ktorych dostepu miec nie
powinienem. Co wiecej - proby nieautoryzowanego dostepu so monitorowane. Co
wiecej - do niektorych danych dostep jest audytowany nawet jak mam do nich
uprawnienia. I to wszystko niezaleznie od tego jakich aplikacji zechce mi
sie uzywac.
Co w tym niedorzecznego???

>>> Uprawnienia w bazie danych nie służą do kontroli dostępu w aplikacji, bo
>>> nie mają odpowiedniej granulacji i zarządzanie nimi jest trudne dla
>>> osoby nietechnicznej.
>>>
>>
>> Tego nie rozumiem - albo:
>> 1) mamy administratora DBMS, ktory jest osoba techniczna
>
> Chyba że nie mamy, bo to mała firemka z małym systemikiem do
> fakturowania.
>
>> 2) tworzymy narzedzia, ktore ulatwiaja osobom nietechnicznym zarzadzanie
>> uprawnieniami.
>
> Tylko że stworzenie takich narzędzi dla na przykład baz SQL-owych jest
> trudne.
>

Co trudnego w zrobieniu GUI ktore wykonuje np. "GRANT admins TO joe;" lub
"REVOKE admins FROM joe;" lub "CREATE USER davide WITH PASSWORD
'jw8s0F4';"???

>> W obydwu przypadkach nie widac powodu, zeby rezygnowac z tego, co oferuje
>> DBMS.
>
> W obydwu przypadkach nie widać możliwości, żeby używać tego, co oferuje
> DBMS w zakresie autoryzacji, w samej aplikacji.
>

Patrz wyzej - wydaje mi sie, ze widac...

--
Michal

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Jarzabek"
>>> Sam jestes laikiem. Formy zagielszczone to norma. Polonista sie
>>> znalazl. Przez takich jak ty mielibysmy miedzymordzie zamiast interfejsu.
>> Bzdura. Po pierwsze - nie "formy zangielszczone", tylko w drugą stronę -
>> niektórzy usiłują na siłę polonizować anglicyzmy.
>> Po drugie - stosowanie słów zapożyczonych z obcych języków ma sens tam,
>> gdzie polskiego odpowiednika (czasem s/polskiego/dobrego&/) nie ma - na
>> przykład przytoczony przez ciebie "interfejs".
>> A "autentykacja" jest albo wyrazem ignorancji, albo udawania
>> "światowca".
>Jest wyrazem ignorancji. Ale ignorancją jest też nie wiedzieć, jak się
>uwierzytelnianie nazywa np. po łotewsku,

Owszem. Jeśli będę udawał specjalistę mówiącego dobrze po łotewsku,
faktycznie powinienem wiedzieć jak jest uwierzytelnianie po łotewsku.

>tego nie wie, jest laikiem w dziedzinie. Prawda jest taka, że da się - i
>często się tak robi - zajmować zawodowo tematami IT bez używania
>polskiej terminologii. Nawet pracując w Polsce i z Polakami, znajomość
>polskiej terminologii jest zbędna:

A idąc do szkoły świeciło słońce.
Tak właśnie wygląda olewanie własnego języka ojczystego.

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,38804171
| http://epsilon.eu.org/ |
/------------------------\

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Michal Kleczek"
>> Użytkownicy aplikacji to są "dane", a nie
>> element funkcjonalny bazy.
>A to niby dlaczego?

Na przykład dlatego, że dużo łatwiej zapewnić bezpieczeńśtwo na wypadek
awarii jeśli masz do zabezpieczenia tylko dane z bazy.


--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,38804171
| http://epsilon.eu.org/ |
/------------------------\

do góry