Gondolatok a webapikról

Kellett volna egy kis egyszerű nyilvántartó program, már-már olyan, amire az ember fog egy Excel Onlinet/Google Docst. Viszont jó lenne, ha kissé auditálhatóbb lenne, hogy ki mit mókolt. Jelen esetben bőven megtette, ha csak beszúrjuk az új rekordot és dátum alapján vesszük mindig a legutolsót. Esetleg fel lehet tartani egy index táblát, ha kicsit optimalizálni akarunk a sebességre, de ez legyen már a jövő zenéje. Szóval olyan jó két-három órás feladat összerakni az egészet pgsql+WPF alapon.

Egyetlen bökkenő: desktop és futnia kellene több helyről. Auch.

Ilyenkor ugye az enterprise világ elkezd mindenféle réteget, SOAP/REST API-t egymásra halmozni, mindezt azért, mert szeretnénk egy minimálisat mókolni az RDBMS-ben. Pont a PostgreSQL 9.5 Row Level Security-ja kapcsán gondolkodtam el, hogy tulajdonképp mennyire sok mindent implementálunk újra és újra és újra alkalmazás szinten, mikor egy picit okosabb RDBMS ezeket mind nyújtja és mennyivel egyszerűbb lenne, ha szimplán közvetlen az RDBMS-hez csatlakoznánk egy csomó olyan esetben, mikor halmozzuk a boilerplate rétegeket.

Ilyenkor szokott két fő visítás lenni:
- de mégis mi az, hogy kinyitjuk az RDBMS-t a nagyvilágba, hisz támadási pont salala. Nos igen, de kérdés, hogy mi alapján bízunk meg jobban egy random összehányt webapi-ban, mint egy évek óta fejlesztett rendszerben. Illetve, annak szabályozására, hogy ki mit tehet egy DB-ben, ugyanúgy meglehetősen bő lehetőségek vannak.
- Absztrakció növelése, ezáltal elrejthetővé válik pl. egy-egy schema módosítás, stb. Nos igen, de tapasztalataim szerint, ha schema módosítás történik, akkor előbb-utóbb valahol úgy is le kell követni, szóval nem spóroljuk meg a munkát, csak máshova tesszük át. Tárolt eljárások meg ugyanúgy képesek interface-ként működni.

Amivel viszont egyet tudok érteni:
- Unit testing sok esetben nehezebb tud lenni.
- Egy - főleg tárolt eljárásokkal és triggerekkel telehalmozott - DB nehezen áttekinthetővé, debuggolhatóvá tud válni.
- Ha kell a plusz, amit egy köztes réteg nyújt, akkor kell.

Viszont azt gondolom, hogy 2016-ban nem kellene ennyire bonyolultnak lennie annak, hogy egy adatbázisból adatot akarok elérni a Föld bármely pontján.

( persicsb | 2016. 01. 10., v – 06:11 )

Szerintem azért vált az mintává, hogy a hozzáféréseket nem DB-szinten, hanem köztesréteg-szinten implementálják, mert ugyebár az adatbázis API-k connection alapúak, és az autentikációs információ a connection-höz tartozik, és nem az egyes lekérdezésekhez. TCP connectiont felépíteni pedig relatíve drága dolog, valamint a DB server alkalmazás és a kliens (amely itt az alkalmazásszerver) között korlátos a létrehozható TCP kapcsolatok száma, ezért is terjedt el a connection pool előre definiált DB userrel + alkalmazásszintű autentikáció.

Ha lehetőség lenne arra, hogy egyes lekérdezésekkor is el tudjam küldeni az autentikációs információt (akár legyen ez egy token, bármi), és ne csak egy új connection felépítése kelljen ahhoz, hogy felépíts egy új autentikált sessiont, akkor ez erőforrásprobléma nélkül megtehető.

Ez részben igaz, részben nem igaz. Egyrészt ugyanúgy TCP connectiont nyitsz a köztesréteg felé, ami ráadásul potenciálisan tovább nyit a DB felé egyet. Ráadásul valamilyen session ott is könnyen előfordulhat.

Persze, másik oldalról nézve, esetenként többezer élő connection igen fájó tud lenni az RDBMS-nek, még ha idle is, pl. egy multi process architektúránál, ld. PostgreSQL.

De tény, hogy mindenféle connection pool tarkón van lőve így, de nem hiszem, hogy ez egy megoldhatatlan probléma lenne.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A HTTP kliens/böngésző megoldja a TCP connection poolt.
Másrészt mivel a HTTP állapotmentes protokoll, minden kéréshez mellékeled az auth információt (session token), így kérésenként tudod ellenőrizni a HTTP kapcsolaton bejövő információt, míg ugye egy SQL kapcsolat nem állapotmentes protokollt takar, egy TCP kapcsolaton csak egy felhasználó jogosultságai mehetnek. Pontosabban PgSQL alatt például lehet set role hívásokat küldeni minden lekérdezés előtt, és ezt meg is lehet oldani proxyzással, lásd itt: http://stackoverflow.com/questions/2998597/switch-role-after-connecting…
De azért na, ez nem a legszebb módja a dolgoknak.
Sokkal egyszerűbb (és RESTful), ha van 1 autentikációs hívás, ami ad neked egy tokent, amit minden további híváshoz felhasználhatsz, amíg a token érvényes. Így működik rengeteg protokoll (nem csak HTTP és a session), de az adatbázisok nem.

( sj | 2016. 01. 10., v – 12:45 )

és mennyivel egyszerűbb lenne, ha szimplán közvetlen az RDBMS-hez csatlakoznánk

safe sex nem rulez? :-)

Btw. en mindig a fejem fogom, amikor a dev-ek (akik nem uzemeltetik is, amit osszeraktak) kitalaljak a tutit. Van az az ismert gif, amin egy ego haz, eloterben egy gyerek, es a szoveg meg kb. az, hogy a fejlesztoi gepen mukodik, ha az eles kornyezetben meg gond van, akkor az mar az admin problemaja.

Ha a dev mellett op sapkad is van, akkor a tervezesnel fel sem merulne olyan megoldas, hogy barki is kozvetlenul hozzaszolhat az sql szerverhez. A "random osszehanyt webapi" es az sql user leszabalyozasa nem xor, hanem and kapcsolatban vannak. Masfelol, ha eljatszunk a gondolattal, hogy rendes webapi-t csinalsz, akkor az kizarolag elore definialt muveleteket enged vegrahajtani. Mig egy kozvetlen sql hozzaferessel meg azt csinal, amit akar/tud.

2016-ban nem kellene ennyire bonyolultnak lennie annak, hogy egy adatbázisból adatot akarok elérni a Föld bármely pontján.

szerintem sem, de a szukseges minimum nem az, hogy itt az sql szerver neve/cime, meg az sql user acc, aztan ezt a tablat figyeljed jol...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

> rendes webapi-t csinalsz, akkor az kizarolag elore definialt muveleteket enged vegrahajtani. Mig egy kozvetlen sql hozzaferessel meg azt csinal, amit akar/tud.

Nyilván attól is függ, hogy ki milyen RDBMS-en szocializálódott, de ez így nem igaz.

Egy perc alatt csinálok neked MSSQL alatt olyan security groupot, ami csak előre definiált műveleteket enged végrehajtani. Oracle alatt egy kicsit több idő kéne hozzá, mert utoljára évekkel ezelőtt láttam Oracle-t, de ott is meg tudnám csinálni. Raktam már össze ilyen rendszert már, nem egy nagy szám.

Egyáltalán nem olyan nagy butaság a DB-re tolni a business logic (egy részét), mint ahogy azt sokan szeretik állítani. Ráadásul a webapi-val is van ám szopás (nem csak) security szempontból.

"Mig egy kozvetlen sql hozzaferessel meg azt csinal, amit akar/tud."
Pontosabban: azt, amihez az adott usernek a DB-ben joga van. És a row level security pont azt mondja meg, hogy csak azokhoz az adatsorokhoz fér hozzá, amihez joga van.
Hogy értsd:
"meg az sql user acc,"
Nem, nem az sql user acc van, hanem a rendszer felhasználói hozzáférnek az SQL szerverhez is (mint ahogy bármilyen más erőforráshoz).
Mondjuk kerberos auth, Windows AD auth és hasonlóval simán megoldható.
Az, hogy a MySQL-ben ez szopás, az a MySQL problémája. Persz 5.5.7 óta van már external authenticationre is lehetőség ott, ujjé, fejlődik a technika.
https://dev.mysql.com/doc/refman/5.5/en/pluggable-authentication.html

Pontosabban: azt, amihez az adott usernek a DB-ben joga van

nem kell pontositani, mert a "tud" ezt a lehetoseget igyekezett lefedni. Ill. ez azt is feltetelezi, hogy hibatlanul vegzed a jogosultsag beallitasat (ami ismetlem: nem vagy - vagy, hanem az is kell)

nem az sql user acc van, hanem a rendszer felhasználói hozzáférnek az SQL szerverhez is

hogy az sql szerveredben vannak a userek, vagy AD-ben, stb, az pont mindegy az ugy szempontjabol.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"ez azt is feltetelezi, hogy hibatlanul vegzed a jogosultsag beallitasat" Mint ahogy a másik megközelítés feltételezi azt, hogy hibátlan a programkódod, ami nem a DB-ben van. Az, hogy az alkalmazásod mely része hibás, ha privilégiumszint-emelést kihasználó hiba van a rendszerben, az lényegtelen.

Nagy összegben fogadni mertem volna, hogy te leszel az első, aki idetrollkodik, hogy bezzegadevopsok.

Viszont láthatóan nem végezted el se a dev se az op házi feladatod. Ha rendes role-t csinálsz SQL-ben, az hogy férhet hozzá olyan objektumhoz (legyen az tábla, view, tárolt eljárás) és hogy végezhet rajta olyan műveletet, amihez nincs joga? Ezek kifejezetten jól szabályozható (és dokumentált) dolgok voltak eddig is. A sor szintű security csak egy újabb dolog, ami feleslegessé teheti azt, hogy ezt alkalmazás szinten kelljen megcsinálni.

Normális helyen külön role-k vannak az egyes szolgáltatásokhoz is, amik az adatbázishoz csatlakoznak és mondjuk az a szolgáltatás, amelyik lehetőséget nyújt egy árlista, készlet információk letöltésére, az nem fér hozzá mondjuk a számlatömbhöz. Stb. De ugye én csak egy dev vagyok, nem érthetek hozzá, Ó Nagyságos DevOps Úr!

Vagy, ha nálad ha valami csatlakozik az adatbázishoz, akkor az már mindenhez hozzáfér? Elég érdekes hozzáállás lenne...

Mellesleg a kérdés pont erre irányult, hogy tulajdonképp mi a valós security kockázat egy jól beállított adatbázisban. Illetve azt nem értem, hogy miért erőltetjük egy csomó esetben a plusz rétegek sorozatát.

Mondok két példát: van egy scirptünk, ami egy táblába generál adatokat ki óránként a salesnek. Ezt a sales egy automata formázással és képletekkel agyoncicomázott Excel táblába húzzák be, frissítik folyamatosan. Az SQL Server-ben van egy Sales role, egyes egyedül ehhez az egy táblához fér hozzá egy dedikált adatbázisban. A sales role tagjai az AD-s iroda csoport, akiknek tagjai azok, akiknek használnia kell. Semmi máshoz nem férnek hozzá.

Vagy ugyanígy, jött egy igény, hogy egy régi, már csak karbantartás alatt lévő weboldalunkon is jó lenne ilyen-olyan statisztikákat kinyerni, amit az újabbak már tudnak. Lehetett volna rá allokálni egy hétnyi fejlesztői időt, ehelyett inkább kaptak egy ODBC kapcsolatot a MySQL db-hez meg egy saját logint, amivel a megfelelő (csak olvasható) táblákból egy MS Access-ben elkészített view-eken keresztül meg tudták oldani a maguk lekérdezéseiket, kereséseiket. Az egész "frontendet" összekattintgatni tartott kb. 5 óráig, beleértve a MySQL beállítását és a szükséges doksik elolvasását. (Illetve kellett még kb. 2-3 óra a kollégáknál telepítés, "oktatás".)

Elbaszni úgy sem tudnak semmit, miért ne lehetne ugyanilyen egyszerű bármilyen másik adatcsere.

De mindegy, én csak egy fejlesztő vagyok, ilyen titkos mágikus dolgokhoz nem érthetek, emiatt (szerinted) fel sem tehetem a kérdést, hogy ennek meg annak mégis mi értelme van. Az meg főleg fő bűn lehet, hogy ha valami rossz, akkor nem megpróbálom elmaszatolni egy újabb réteggel, mert dogmatikusan azt mondták Az Interneten A DevOpsok, hogy Ez Az Egyetlen Igaz Út, hanem megvizsgálom, hogy hogyan lehetne megjavítani, ha lehet.

De mindegy, továbbra is külön öröm, hogy ennyire képben vagy a munkaköri leírásommal. ;)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem nincs semmi baj az általad felvázolt dolgokkal. Ha a környezet és az igények lehetővé teszik, hogy így tervezd meg az alkalmazásod, akkor miért ne. Nálunk is van több olyan termék, ami 15+ éve így lett megoldva és tökéletesen ellátta a feladatát.
Persze most több szempontból is szívás van vele, mert megváltoztak az igények.

latom, nagyon felzaklattalak :-)

Ha rendes role-t csinálsz SQL-ben, az hogy férhet hozzá olyan objektumhoz (legyen az tábla, view, tárolt eljárás) és hogy végezhet rajta olyan műveletet, amihez nincs joga?

pl. elrontod a role jogait; mas rontja el (kesobb); sec. bug az sql szerverben; sec. bug valamelyik hasznalt so-ban/dll-ben; etc. De az is eleg lehet, ha le tudja dos-olni az sql szervered a kinyitott porton keresztul.

Vagy, ha nálad ha valami csatlakozik az adatbázishoz, akkor az már mindenhez hozzáfér? Elég érdekes hozzáállás lenne...

persze, root-kent, ures jelszoval... sigh. De mostmar te is latod, hogy nem feltetlen van erre szukseg, hogy gond lehessen

tulajdonképp mi a valós security kockázat egy jól beállított adatbázisban.

az egy dolog, hogy te jol beallitod. A postfix keszitoje - sajat bevallasa alapjan - kb. 1000 soronkent vet egy bug-ot. Nem feltetlen security bug, valamilyen bug. Vilagos, hogy egy sql szerver eseteben eleg sok potencialis bugrol beszelunk. Majd gelei jol megmondja, hogy az m$ sql szerverben max. 1 hiba lehet 10k loc-onkent, de akkor is.

Biztonsagi szempontbol az sem mindegy, hogy a ceges halon ulo kollegak kapnak kozvetlen hozzaferest, vagy a neten keresztul barhonnan be lehet lepni.

(szerinted) fel sem tehetem a kérdést, hogy ennek meg annak mégis mi értelme van. Az meg főleg fő bűn lehet, hogy ha valami rossz, akkor nem megpróbálom elmaszatolni egy újabb réteggel, mert dogmatikusan azt mondták Az Interneten A DevOpsok, hogy Ez Az Egyetlen Igaz Út, hanem megvizsgálom, hogy hogyan lehetne megjavítani, ha lehet.

egy kicsit tultolod a dolgot :-) de jol elvitazgatsz magaddal, mert en ilyet biztos nem mondtam

De mindegy, továbbra is külön öröm, hogy ennyire képben vagy a munkaköri leírásommal. ;)

felreertesz. Mindossze behoztam par szempontot, amire ugy tunik, nem gondoltal, es elmondtam, hogy szerintem miert nem jo otlet...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"latom, nagyon felzaklattalak :-)"

Fenéket, csak uncsi az elitista devops nyáladzásod. Főleg, miután nem egyszer elmondtam, hogy belelóg azért az ops részbe is a munkám.

"pl. elrontod a role jogait; mas rontja el (kesobb); sec. bug az sql szerverben; sec. bug valamelyik hasznalt so-ban/dll-ben; etc. De az is eleg lehet, ha le tudja dos-olni az sql szervered a kinyitott porton keresztul."

Mi arra a garancia, hogy nem követi el ugyanezt a webapon?

"A postfix keszitoje - sajat bevallasa alapjan - kb. 1000 soronkent vet egy bug-ot."

Tehát, ha valamit nem 1000 sorból, hanem 10000 sorból oldunk meg, akkor az csak jó lehet!

"felreertesz. Mindossze behoztam par szempontot, amire ugy tunik, nem gondoltal, es elmondtam, hogy szerintem miert nem jo otlet..."

Nekem inkább úgy tűnik, hogy idehoztál néhány dogmát, és észre sem vetted, hogy pont azt kérdeztem meg, hogy igazából ahelyett, hogy ezeket elmaszatoljuk, miért nem oldjuk meg.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Főleg, miután nem egyszer elmondtam, hogy belelóg azért az ops részbe is a munkám.

ne vedd zokon, hogy nem kovetem ennyire a munkassagodat

Mi arra a garancia, hogy nem követi el ugyanezt a webapon?

semmi.

Tehát, ha valamit nem 1000 sorból, hanem 10000 sorból oldunk meg, akkor az csak jó lehet!

akkor meg egyszer: en azt irtam, hogy minel nagyobb egy szoftver (pl. az ms sql szerver), annal tobb a potencialis hiba benne. *Ezert* nem jo otlet kozvetlenul raengedni az internetet.

ahelyett, hogy ezeket elmaszatoljuk, miért nem oldjuk meg.

ok, mutasd a megoldasod

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( daroczig | 2016. 01. 10., v – 22:30 )

Az elso ket bekezdeshez: a Google Spreadsheet szerintem eleg jol auditalhato (reszletes revision history), fut tobb desktopon es tobb helyem is, van hozza rendes API.

( Gyuszk v | 2016. 01. 13., sze – 00:27 )

Jó dolog az egyszerűsítés, a postgresql meg remek RDBMS, úgyhogy nem trollkodok hanem +1. Azért egy spring-bootot beröffentenék fölé, 1 soros main classból full ficsőrd RESTful api :)

--
arch,debian,openelec,android

( manfreed (nem ellenőrzött) | 2016. 01. 13., sze – 08:16 )

Milyen érdekes amúgy, hogy pl email szolgáltatóknál fel se merül, hogy saját web api mögé elrejtsék az smtp/pop/imap szervereket. Csúnya is lenne, ha mindegyik szolgálató saját webes apiját kellene a klienseknek implementálni.