epsilon$ while read LINE; do echo \>"$LINE"; done < "Michal Kleczek"
>>>>>Przeciez strategia i narzedzia backupu to w ogole inna bajka - tak czy
>>>>>inaczej musisz robic kopie _wszystkich_ istotnych danych w bazie danych
>>>>>(a takze innych danych np. konfiguracja systemu operacyjnego itp.).
>>>> No i teraz pomyśl jak wygląda sytuacja w momencie kiedy wszystkie dane
>>>> masz w bazie, a jak, kiedy dodatkowo masz część danych na zewnątrz. Na
>>>> dodatek jeszcze przyjmij, że możesz na tym samym silniku mieć inne bazy.
>>>Nadal nie rozumiem problemu. Jest naprawde obojetne z punktu widzenia
>>>robienia kopii zapasowej w ktorej bazie danych sa trzymane konta
>>>uzytkownikow.
>> Z technicznego punktu widzenia - oczywiście. Z praktyczno-organizacyjnego?
>> Jest duża różnica.
>Jaka?

Choćby taka, że wczytanie ze zrzutu jednej bazy jest prostsze i mniej
błędogenne niż zastanawianie się czy użytkownicy bazodanowi na serwerze,
na który odzyskuję nie mają przypadkiem takich samych loginów.


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

do góry

On 29-06-2011 09:11, Andrzej Jarzabek wrote:
> 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.
>
Dokladnie. Tak samo jak polskie wersje oprogramowania, dla mnie sa
kompletnie zbedne a wrecz utrudniaja czesto zycie. Regeneracja
monitora, wznowienie komputera to zaledwie kilka przykladow komunikatow
ktore robia sie zrozumiame po przetraslatowaniu na angielski. Jak
uslyszalem o probach tlumaczenia slow kluczowych w jezykach
programowania to rece mi opadly. Naprawde dziwia mnie goscie w
srodowisku IT ktorzy tak walcza o czystosc jezyka i jego zachowanie.
Moze znalezli sie w min z innych przyczyn niz zainteresowania i powinni
sie zajmowac np. pisaniem wierszy ?


Pozdr

Marek

do góry

Mariusz Kruk wrote:

> epsilon$ while read LINE; do echo \>"$LINE"; done < "Michal Kleczek"
>>>>>>Przeciez strategia i narzedzia backupu to w ogole inna bajka - tak czy
>>>>>>inaczej musisz robic kopie _wszystkich_ istotnych danych w bazie
>>>>>>danych (a takze innych danych np. konfiguracja systemu operacyjnego
>>>>>>itp.).
>>>>> No i teraz pomyśl jak wygląda sytuacja w momencie kiedy wszystkie dane
>>>>> masz w bazie, a jak, kiedy dodatkowo masz część danych na zewnątrz. Na
>>>>> dodatek jeszcze przyjmij, że możesz na tym samym silniku mieć inne
>>>>> bazy.
>>>>Nadal nie rozumiem problemu. Jest naprawde obojetne z punktu widzenia
>>>>robienia kopii zapasowej w ktorej bazie danych sa trzymane konta
>>>>uzytkownikow.
>>> Z technicznego punktu widzenia - oczywiście. Z
>>> praktyczno-organizacyjnego? Jest duża różnica.
>>Jaka?
>
> Choćby taka, że wczytanie ze zrzutu jednej bazy jest prostsze i mniej
> błędogenne niż zastanawianie się czy użytkownicy bazodanowi na serwerze,
> na który odzyskuję nie mają przypadkiem takich samych loginów.
>

To nie jest scenariusz backup/restore tylko przeniesienie danych z jednego
na drugi (juz istniejacy) serwer z rozwiazaniem ew. konfliktow - rzecz
problematyczna tak czy inaczej, niezaleznie od tego, czy mowimy o kontach
uzytkownikow, czy o innych danych.

--
Michal

do góry

On 2011-06-29, Marek Borowski <m...@b...com> wrote:
>>> 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.
>>
> Dokladnie. Tak samo jak polskie wersje oprogramowania, dla mnie sa
> kompletnie zbedne a wrecz utrudniaja czesto zycie. Regeneracja
> monitora, wznowienie komputera to zaledwie kilka przykladow komunikatow
> ktore robia sie zrozumiame po przetraslatowaniu na angielski. Jak
> uslyszalem o probach tlumaczenia slow kluczowych w jezykach
> programowania to rece mi opadly. Naprawde dziwia mnie goscie w
> srodowisku IT ktorzy tak walcza o czystosc jezyka i jego zachowanie.
> Moze znalezli sie w min z innych przyczyn niz zainteresowania i powinni
> sie zajmowac np. pisaniem wierszy ?

Z drugiej strony jak masz zinwestygować rikłest kastomera, żeby przed
rilisem performęs timu był duży i na mityngu dało się to pokazać, to
mnie się odechciewa słuchać takiej polszczyzny.

--
Secunia non olet.
Stanislaw Klekot

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Michal Kleczek"
>>>>>>>Przeciez strategia i narzedzia backupu to w ogole inna bajka - tak czy
>>>>>>>inaczej musisz robic kopie _wszystkich_ istotnych danych w bazie
>>>>>>>danych (a takze innych danych np. konfiguracja systemu operacyjnego
>>>>>>>itp.).
>>>>>> No i teraz pomyśl jak wygląda sytuacja w momencie kiedy wszystkie dane
>>>>>> masz w bazie, a jak, kiedy dodatkowo masz część danych na zewnątrz. Na
>>>>>> dodatek jeszcze przyjmij, że możesz na tym samym silniku mieć inne
>>>>>> bazy.
>>>>>Nadal nie rozumiem problemu. Jest naprawde obojetne z punktu widzenia
>>>>>robienia kopii zapasowej w ktorej bazie danych sa trzymane konta
>>>>>uzytkownikow.
>>>> Z technicznego punktu widzenia - oczywiście. Z
>>>> praktyczno-organizacyjnego? Jest duża różnica.
>>>Jaka?
>> Choćby taka, że wczytanie ze zrzutu jednej bazy jest prostsze i mniej
>> błędogenne niż zastanawianie się czy użytkownicy bazodanowi na serwerze,
>> na który odzyskuję nie mają przypadkiem takich samych loginów.
>To nie jest scenariusz backup/restore tylko przeniesienie danych z jednego
>na drugi (juz istniejacy) serwer z rozwiazaniem ew. konfliktow - rzecz
>problematyczna tak czy inaczej, niezaleznie od tego, czy mowimy o kontach
>uzytkownikow, czy o innych danych.

Ale wiesz, że niekoniecznie masz tak, że masz pierdyliard serwerów i
jeden w tę, jeden w tamtą nie robi ci różnicy? Czasem jest owszem, tak,
że jak ci pada jeden serwer, musisz gdzieś aplikację na pewien czas
"przytulić".
Poza tym, restore w jedno miejsce jest zawsze prostsze niż restore w
fafnaście różnych.

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

do góry

W dniu 2011-06-29 12:19, Marek Borowski pisze:
> On 29-06-2011 09:11, Andrzej Jarzabek wrote:
>> 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.
>>
> Dokladnie. Tak samo jak polskie wersje oprogramowania, dla mnie sa
> kompletnie zbedne a wrecz utrudniaja czesto zycie. Regeneracja monitora,
> wznowienie komputera to zaledwie kilka przykladow komunikatow ktore
> robia sie zrozumiame po przetraslatowaniu na angielski.

To wynika zwykle z niechlujstwa tłumacza, a nie z braku polskich
terminów. Tak jak użycie słowa ,,przetraslatowaniu" w powyższym zdaniu -
niby mamy ładne odpowiedniki: przełożeniu lub przetłumaczeniu, ale po co
myśleć - tak jest szybciej i taniej :)

> Jak uslyszalem o
> probach tlumaczenia slow kluczowych w jezykach programowania to rece mi
> opadly.

Wszystko zależy od _docelowego użytkownika_ danego oprogramowania (wielu
programistów wydaje się nie zauważać dla kogo pisze oprogramowanie :) -
jeśli użytkownik docelowy posługuje się biegle językiem polskim,
a niekoniecznie zna angielski, to rozsądne wydaje się tłumaczenie
oprogramowania na polski (czy inny język użytkownika). Moim zdaniem
tłumaczenie języków wbudowanych w aplikacje (np. w arkuszach
kalkulacyjnych), czy edukacyjnych (jak np. przetłumaczone na polski
LOGO) ma sens.

> Naprawde dziwia mnie goscie w srodowisku IT ktorzy tak walcza o
> czystosc jezyka i jego zachowanie. Moze znalezli sie w min z innych
> przyczyn niz zainteresowania i powinni sie zajmowac np. pisaniem wierszy ?

Bo mamy naprawdę ładny język i szkoda go tak oszpecać?

do góry

W dniu 2011-06-29 13:24, Piotr Chamera pisze:

> Wszystko zależy od _docelowego użytkownika_ danego oprogramowania (wielu
> programistów wydaje się nie zauważać dla kogo pisze oprogramowanie :) -
> jeśli użytkownik docelowy posługuje się biegle językiem polskim,
> a niekoniecznie zna angielski, to rozsądne wydaje się tłumaczenie
> oprogramowania na polski (czy inny język użytkownika). Moim zdaniem

Oprogramowania - tak!

> tłumaczenie języków wbudowanych w aplikacje (np. w arkuszach
> kalkulacyjnych), czy edukacyjnych (jak np. przetłumaczone na polski
> LOGO) ma sens.

Języków programowania - nie! Dlaczego? Za przykład można podać VB z
pakietu MS Office. Typowy użytkownik nie będzie się tego dotykał bo z
ledwością potrafi otworzyć plik i na nim pracować, więc on jako cel nie
jest zainteresowany spolszczeniem. Użytkownik bardziej zaawansowany,
który będzie chciał się zabrać za programowanie w VB będzie miał problem
ze spolszczoną wersją (i najczęściej ma) bo większość materiałów
dostępnych w internecie dotyczy jego wersji angielskiej. Więc nie dosyć,
że będzie musiał używać polskiej wersji VB, to będzie musiał zamieniać
przykłady wersji angielskiej na polską, co dla osoby średnio znającej
język może być kłopotliwe. Ostatnią grupą są użytkownicy najbardziej
zaawansowani (np. programiści). Dla tej grupy spolszczenie jest
komplikacją utrudniającą swobodną pracę z tym pakietem. I ogólnie
wychodzi, że spolszczona wersja VB jest nie do końca trafionym pomysłem.

>
>> Naprawde dziwia mnie goscie w srodowisku IT ktorzy tak walcza o
>> czystosc jezyka i jego zachowanie. Moze znalezli sie w min z innych
>> przyczyn niz zainteresowania i powinni sie zajmowac np. pisaniem
>> wierszy ?
>
> Bo mamy naprawdę ładny język i szkoda go tak oszpecać?

Taka dyskusja była już nie raz. Najciekawsza na początku lat 80, gdzie
zaproponowane słynne tłumaczenie dla myszki - 'manipulator
stołokulotoczny' :) Teraz wszystko jest powieleniem tych samych
argumentów, a branża IT jak używała angielskich (lub spolszczonych
wersji) terminów tak robi to i będzie robić niezależnie od opinii
purystów językowych (choć jak widać zapożyczeń z łaciny nikt nie
kwestionuje, ba nawet uważa się to za oznakę wyższej inteligencji :/ ).

pozdrawiam,
Przemek O.

do góry

On Wed, 29 Jun 2011 14:33:56 +0200, Przemek O. wrote:

> Języków programowania - nie! Dlaczego? Za przykład można podać VB z
> pakietu MS Office. Typowy użytkownik nie będzie się tego dotykał bo z
> ledwością potrafi otworzyć plik i na nim pracować, więc on jako cel nie
> jest zainteresowany spolszczeniem. Użytkownik bardziej zaawansowany,
> który będzie chciał się zabrać za programowanie w VB będzie miał problem
> ze spolszczoną wersją (i najczęściej ma) bo większość materiałów
> dostępnych w internecie dotyczy jego wersji angielskiej. Więc nie dosyć,
> że będzie musiał używać polskiej wersji VB, to będzie musiał zamieniać
> przykłady wersji angielskiej na polską, co dla osoby średnio znającej
> język może być kłopotliwe. Ostatnią grupą są użytkownicy najbardziej
> zaawansowani (np. programiści). Dla tej grupy spolszczenie jest
> komplikacją utrudniającą swobodną pracę z tym pakietem. I ogólnie
> wychodzi, że spolszczona wersja VB jest nie do końca trafionym pomysłem.

Ja to przede wszystkim nie jestem w stanie zrozumieć tłumaczenia
komunikatów trafiających do logów. Jak mam znaleźć wytłumaczenie jakiegoś
zdarzenia, to najpierw muszę zgadnąć, jak to po angielsku z powrotem będzie
i dopiero takiego tekstu szukać.

--
Pozdrawiam
Zbyszek Malec

do góry

On Wed, 29 Jun 2011 09:49:32 +0200, Michal Kleczek wrote:

> 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

W DBMS masz granulację na poziomie obiektu, a nie rekordu, grupy rekordów,
czy nawet wybranych kolumn z danej grupy wierszy. I tak trzeba logikę
dostępu do danych gdzieś zaszywać z boku i same uprawnienia DBMS i tak nie
wystarczą.

>> 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.

Jedny z wielu, zgadzam się że może być brany pod uwagę. Myślę jednak, że są
dużo istotniejsze czynniki w wyborze i ten jeden akurat nie jest tak bardzo
istotny.

>>>> 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.

No właśnie i tak gdzies to trzeba zabezpieczenie zrealizować. Dodatkowy
koszt utworzenia tejże tabelki z użytkownikami będzie własnie pomijalny.
Argument kosztu do mnie tutaj nie przemawia, i tak to co jest już w bazie
do zarządzania trzeba dopiero wykorzystać w aplikacji, a więc dorobić całą
logikę dostępu do danych. No i jeszcze dostajemy rozwiązanie, które jest
mocno przywiązane do jednej konkretnej bazy danych. Owszem, zmiana DBMSa to
nie jest mała rzecz, ale jednak się zdarza. A gdzie wsparcie w postaci
technologii typu Hibernate i pokrewnych?

>> 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 bazie aplikacyjnej to właściwie można się nawet bez constraintów obejść -
aplikacja może wszystkiego przypilnować. W przypadku bazy integracyjnej,
gdzie twoja aplikacja jest tylko gościem, nie jest już tak różowo. Tutaj
nie ma mowy o przesuwaniu tej odpowiedzialności na aplikację i umywania
rąk. Baza danych dostarcza aplikacji pewnego API w postaci kolekcji
obiektów dostępnych w ramach uprawnień użytkownika aplikacyjnego. I teraz
wiadomo, że aplikacja namiesza najwyżej tyle, ile jest na to pozwala
publiczne API. Korzystanie z wbudowanych mechanizmów nic nam tu nowego nie
daje, bo i tak tę logikę dostępu trzeba zrealizować, czy to w postaci kodu
programu, czy też wyszukanego setupu z pomocą narzędzi za setki tysięcy
dolarów (no, trochę przesadzam). A w samej aplikacji trzeba oczywiście i
tak jeszcze odrębnie zakodować reguły dostępu, bo przecież nie będziesz
udostepniał użytkownikowi końcowemu interfejsu do zrobienia wszystkiego i
tylko polegał na tym, że się baza z odpowiednim wyjątkiem wywali. Nie wiem
też jak wyglądają te super rozwinięte narzędzia do obsługi DBMS (nie miałem
styczności), ale czy np. przewidują tworzenie roli i grup użytkowników (to
widzę że tak) i czy takim grupom/rolom można przypisać uprawnienia do
odpowiednio drobno granulowanych danych? Czy można do nich dodawać rózne
metadane? A czy takie narzędzia pozwalają na tworzenie relacji między
użytkownikami i udostępnienie danych w kontekście danej relacji (co
ostatnio w projekcie w którym biorę udział dość mocno jest praktykowane)
Czy do wszystkiego tego da się dostać z poziomu aplikacji? To jest dość
chyba podstawowa funkcjonalność której używa się w aplikacjach. A co z
aplikacjami rozproszonymi, gdzie jednego użytkownika używa się do
autoryzacji wielu niezwiązanych czynności w potencjalnie różnych bazach
danych i nie ma ścisłego powiązania między daną bazą a użytkownikiem
końcowym aplikacji?

Ataki SQL injection też nie mają prawa bytu, jeżeli aplikacja korzysta
wyłącznie z dobrze zdefiniowanego interfejsu bazy danych. Jeżeli aplikacji
nie pozwalamy robić przelewów, to mamy gwarancję, że żaden jej użytkownik
przelewu nie wykona. I to już jest bardzo dobre zabezpieczenie.
I nie bardzo sobie wyobrażam, żeby np. dało się za pomocą takich narzędzi
opisać sytuację, w której to pełnomocnik klienta może wykonywać przelewy w
imieniu klienta, ale tylko z konta danego typu.

Wbudowanie zabezpieczeń w DBMS - jak najbardziej tak! Koniecznie wręcz w
przypadku większych baz, gdzie dana aplikacja jest tylko gościem. Tylko ja
co innego rozumiem pod pojęciem wbudowania zabezpieczeń w bazę, niż
korzystanie z użytkowników samego DBMSa. Tworzenie użytkownika
aplikacyjnego i wytawienie dobrze zdefiniowanego API w ramach tego
użytkownika daje nam klarowną granicę zaufania i jasny podział
odpowiedzialności. A tak część logiki jest w bazie, część tej samej logiki
w aplikacji, a cześć w konfiguracji samej bazy.

Ad 2. Jeżeli każda aplikacja ma dobrze określony sposób dostępu do danych
to problem nie występuje. Masz określone grono użytkowników, które coś z
danymi mogą w ogóle zrobić. Konkretnie użytkownik techniczny aplikacji oraz
administratorzy.

Ad 3. To jest bardzo ogólne pytanie. To wszystko zależy o jakich
aplikacjach mówimy i jaki jest cel istnienia danej hierarchi użytkowników.
Uprawnienia użytkowników mogą być też różne w różnym kontekście, a co za
tym idzie różne w różnych aplikacjach.

> 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).

Czyli nie ten poziom granulacji.

>> 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.

Nie bardzo rozumiem, co chciałeś przez to powiedzieć.
A poziomów zabezpieczeń powinno być conajmniej tyle ile granic zaufania w
całej aplikacji.

Zresztą cała ta nasza dyskusja jest niestety zawieszona w powietrzu. Co
innego jest w przypadku bazy aplikacyjnej, a co innego w przypadku bazy
integracyjnej. Co innego w przypadku aplikacji korporacyjnej a co innego w
przypadku aplikacji dla masowego użytkownika. Z tego wątku tu już chyba nic
nie będzie :]

--
Pozdrawiam
Zbyszek Malec

do góry

On 29-06-2011 12:28, Stachu 'Dozzie' K. wrote:
> On 2011-06-29, Marek Borowski<m...@b...com> wrote:
>>>> 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.
>>>
>> Dokladnie. Tak samo jak polskie wersje oprogramowania, dla mnie sa
>> kompletnie zbedne a wrecz utrudniaja czesto zycie. Regeneracja
>> monitora, wznowienie komputera to zaledwie kilka przykladow komunikatow
>> ktore robia sie zrozumiame po przetraslatowaniu na angielski. Jak
>> uslyszalem o probach tlumaczenia slow kluczowych w jezykach
>> programowania to rece mi opadly. Naprawde dziwia mnie goscie w
>> srodowisku IT ktorzy tak walcza o czystosc jezyka i jego zachowanie.
>> Moze znalezli sie w min z innych przyczyn niz zainteresowania i powinni
>> sie zajmowac np. pisaniem wierszy ?
>
> Z drugiej strony jak masz zinwestygować rikłest kastomera, żeby przed
> rilisem performęs timu był duży i na mityngu dało się to pokazać, to
> mnie się odechciewa słuchać takiej polszczyzny.
>
Natomiast jesli chodzi o mnie to czuje sie jak ryba w wodzie przy w/w
slownictwie.


Pozdr

Marek

do góry