Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Petr 11. 06. 2018, 16:09:00

Název: Problematika zabezpečení REST rozhraní
Přispěvatel: Petr 11. 06. 2018, 16:09:00
Vždycky když musím použít nějakou věc a zdá se mi až moc složitá, přemýšlím, jak udělat to samé co nejvíc Keep it simple.

Use case je takovýto. Mám nějaký backend, jedno v čem napsaný, a chci mu zaheslovat REST. Frontend je zcela zvlášť, v javascriptu. První věc, která mě napadla, úplně primitivní, je udělat tohle:

GET https://localhost:8080/login

Do http-body dám heslo a username. Protože je to https, http-body bude zašifrované a můžu tam tedy to heslo natvrdo poslat.

Response na ten GET bude klíč, securityKey, který budu následně vždy přidávat do http-body jako parametr. Opět, https se postará, že klíč nebude viditelný odposlouchávačům. V backendu tam dám něco na způsob design patternu Filter Chain pro zpracování requestů a vždy se podívám, jestli klíč v http-body je aktuálně validní klíč a když není, vrátím error msg.

No a to je všechno, v základu to je hotové. Můžu pak dodělávat drobnosti, jakože klíč bude mít časově omezenou platnost, která se obnoví při každém dalším requestu s tímto klíčem, ale to už jsou opravdu jen detaily zajišťující komfort uživatele.

Další věc, jako třeba uložení klíče někam do Cookies pro případ, že se znovu otevře Browser, už si bude řešit ten frontend sám, opět, jedná se o detail spadající do kategorie komfort pro uživatele. Securita tak jak jsem ji popsal mi přijde zcela hotová a snad je i bezpečná.

No a tohle je Keep it simple řešení. Přesto, Security v praxi bývají docela molochy a mám teď na mysli Spring Boot Security, která mi zhoršila start aplikace tak o 15% a o dalších 15% mi zvětšila výstupní Jar-with-dependencies.

Takže si říkám, co je tam asi tak všechno u velkých SW potřeba udělat pro to zabezpečení a proč to nejde takhle jednoduše?
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Petr 11. 06. 2018, 16:14:26
Já neříkám, že SPring Security je špatná. Uvedu takový příklad s autem. Člověk si může jít koupit auto kategorie škoda Fabia a to bude mít z moderních věcí ABS a elekrická stahovací okénka. Nebo si může koupit BMW za 3 mega, které bude mít nejrůznější elektroniku: měření tlaku v pneumatikách, různá blikátka a pípátka, klimatizaci, posilovače brzd, elektronické naklápění sedadel a já nevím co všechno ještě.

Chápu, že někteří lidi majít přesně tohle rádi a chtějí to. Nechci tady rozjíždět flame. Já jako člověk takové věci rád nemám, protože se kazí a jsou s nimi problémy, zvyšují celkovou komplikovanost a nepřehlednost, zvyšují exponenciálně cenu.

Tak si říkám, jestli to takto není i v případě Spring Secuiity a dalších takových komplikovaných frameworků. Jestli to není už moc komplikovaná věc ALA elektronické naklápěcí autosedačky. A přemýšlím, jestli to nejde nějak jednodušeji, prostě spokojit se se starým dobrým manuálním naklápěním sedaček.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Petr 11. 06. 2018, 16:19:38
Protože co se mi teď stalo je, že si potřebuju udělat jednoduchou aplikaci, použil jsem Spring Boot a Java platformu a myslím si, že kvůli právě těm věcem ala elektronické autosedačky jsem to musel dělat třeba 2x tak dlouho, než by mi to zabralo s něčím jednodušším.

Teď mám jednoduchou apku, která má asi 7 tříd, ale výstupní JAR má 33MB. Na vzdálený server to kopíruju tak 1 minutu. Ano, já vím, že si můžu nastavit různé remote věci, nainstalovat tam Jenkins atd., jenže to jsou další hodiny a hodiny práce. Třeba 2h jsem zabil zjišťováním, proč se nemůžu přihlásit do konzole od databáze. Zjistil jsem ,že to blokuje automaticky předkonfigurovaná Spring Boot Security. Pak jsem zjišťoval, proč to blokuje a jak tomu zamezit. No a rázem z toho byly 2h strávené nad tímto problémem, které jsem už mohl věnovat něčemu jinému.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Ondrej Nemecek 11. 06. 2018, 18:07:34
Skoro to vypadá, že nechcete řešit problematiku zabezpečení REST rozhraní, ale postěžovat si, jak jsou věci složité  :) Ta složitost se prostě postupně nabalí a vnikne z toho knihovna nebo framework. Používejte minimalistické frameworky a máte po problému (ale jen dokud vám bude stačit jejich funkčnost).
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Jose D 11. 06. 2018, 18:16:22
triviální způsob jak vyřešit REST zabezpečení je neřešit ho v aplikaci, ale aplikaci schovat za https nginx proxy, kde provedeš ověření přistupu..
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Ladislav Zitka 11. 06. 2018, 19:01:52
Tak ta slozitost tam je no, z meho pohledu je Spring taky uz tak nejak prerostly a kdyz v nem nejsi porad, tak po nejake dobe musis zase do docs. Ja ohledne REST migruju ke GraphQL, Spring podporuje (to mimo tema).

Ohledne Nginx zde zminovaneho se z nej stava opravdu swiss knife a obsahuje napr. i modul pro OAuth2 https://github.com/bitly/oauth2_proxy

Kazdopadne stale existuje dalsi mnozstvi tzv API Gateways, ktere jsou reseni all in one s webovym rozhranim reportem do databaze (audit), filtrovani nevalidnich pozadavku, apod.:
Oracle API Gateway - enterprise placena
IBM ma take produkt myslim

Open source:
https://gravitee.io/
https://apiumbrella.io/
https://getkong.org/
https://tyk.io/
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Ladislav Zitka 11. 06. 2018, 19:16:03
Samozrejme v enterprise systemech je stale bezne BASIC AUTH (jmeno heslo) pokud jsou systemy na vnitrni sity a nebavime se o bankovnich systemech. Pokud ti staci jmeno heslo, tak mrkni sem treba:
https://www.devglan.com/spring-security/spring-boot-security-rest-basic-authentication
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Youda 11. 06. 2018, 19:33:13
Pristup BASIC auth na HTTPS a header X_AUTHENTICATION_TOKEN je naprosty standard u REST API.

Akorat se obvykle pouziva disjunktne, bud mas BASIC auth u vsech callu (coz je ostatne jenom jeden request header), nebo si implementujes REST sluzbu login, ktera vrati token a ten strkas bud do headeru requestu nebo do JSON payloadu requestu.

Spring security tohle vsechno zvladne s prstem v nose a rychly google mi vyblil hned nejaky stackoverflow odkaz (ani jsem to necet):
https://stackoverflow.com/questions/42354138/spring-security-token-based-authentication?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

Ze ma WARko se zabudovanym SpringWS 30 mega je snad jedno, nepises to pro jednocipy. V realu se z toho pouzije kousek.
Muzes zamozrejme pouzit jiny, lehci framework nebo si to napsat cele, nevidim ale prinos takoveho pocinani.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: _Tomáš_ 11. 06. 2018, 19:39:23
co je špatného na basic auth a proč se nemůže použít u bankovních systémů?

Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Youda 11. 06. 2018, 19:39:48
Ale samozrejme, nasazovat Spring security ma smysl, pokud mam Springovy projekt a SpringSecurity je jenom dalsim modlem Spring ekosystemu.
Pokud mam nejakou srandaapku na holem JAX-RS v Jersey, tak nema smysl tam cpat Spring buldozer a proste si do toho jersey napis authfilter a hotovo.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Youda 11. 06. 2018, 19:42:42
co je špatného na basic auth a proč se nemůže použít u bankovních systémů?

Typl bych si ze duvodem bude, ze basic auth nepodporuje logout.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Kit 11. 06. 2018, 19:51:30
co je špatného na basic auth a proč se nemůže použít u bankovních systémů?

Typl bych si ze duvodem bude, ze basic auth nepodporuje logout.

Logout se v basic auth dá udělat, ale když místo odhlášení jen zavřeš okno, tak zůstaneš přihlášen.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Ladislav Zitka 11. 06. 2018, 21:20:54
co je špatného na basic auth a proč se nemůže použít u bankovních systémů?

Tak credential je pouze enkodovane v Base64 a posila se po lince. Samozrejme TLS to prekryje, ale dalsi problemy jsou napr.:
- Heslo se posila stale dokola pro kazdy request v hlavicce
- Chybi dalsi rozsirene protekce jako Nonce, TTL, request timestamp, apod.pro zamezeni reply utoku

Ale jako, pokud se jedna o interni systemy, tak to nemusi byt problem, pokud se o dalsi bezpecnost staraji firewally, nebo dalsi prvky. Samozrejme stale to plati pouze pro TLS secured pripojeni.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: . 12. 06. 2018, 00:45:51
Důrazně doporučuji nic nevymýšlet, věřte, že s nějvětší pravděpodobností to jen pos...te. Pro zabezpečení API se nejčastěji používá Basic authentication nebo JWT. Obojí je standardizované, jednoduché a nerozumím tomu, proč by implementace měla zabírat 33MB. Na obojí najdete plný pytel knihoven a bude vám to fungovat napříč jazyky a implementacemi (frameworky). Jestli si kvůli autentizaci taháte nějakou obří knihovnu, doporučuji se zamyslet, zda ji opravdu potřebujete.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržika 12. 06. 2018, 08:22:45
Důrazně doporučuji REST api nezabezpečovat. Ušetříte si tím hromadu starostí, které to zabezpečení přinese.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Ladislav Zitka 12. 06. 2018, 08:36:13
Důrazně doporučuji REST api nezabezpečovat. Ušetříte si tím hromadu starostí, které to zabezpečení přinese.

Ok no, tak jdu stavet burzovni system s verejnym API pro management fondu a nebudu to zabezpecovat, diky za super radu.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Ladislav Zitka 12. 06. 2018, 08:38:46
Důrazně doporučuji nic nevymýšlet, věřte, že s nějvětší pravděpodobností to jen pos...te. Pro zabezpečení API se nejčastěji používá Basic authentication nebo JWT. Obojí je standardizované, jednoduché a nerozumím tomu, proč by implementace měla zabírat 33MB. Na obojí najdete plný pytel knihoven a bude vám to fungovat napříč jazyky a implementacemi (frameworky). Jestli si kvůli autentizaci taháte nějakou obří knihovnu, doporučuji se zamyslet, zda ji opravdu potřebujete.

Pro zabezpeceni API se pouziva nejcasteji Basic auth nebo JWT -> to je vystup z nejakeho globalniho pruzkumu, nebo jen subjektivni nazor, co kde pouzivate sam na projektech? :-)
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržika 12. 06. 2018, 08:49:15
Ok no, tak jdu stavet burzovni system s verejnym API pro management fondu a nebudu to zabezpecovat, diky za super radu.

Všechny api by měli být veřejné, citlivé části jako private s omezením na firewallu na ip. Zabezpečení "heslem, oauth2, jwt,.." na api je přežitek. Stejně tak jako všechny zdrojové kódy by měli být povinně opensource.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržika 12. 06. 2018, 09:02:49
private api s omezením na firewallu na ip

Aby mě nikdo nenařkl že zabezpečení na ip je nebezpečné, či že ip se často mění (tak určitě), tak stačí namísto IP využít TXT DNS record a vůči němu se api ověří. Vzhledem k https+dnssec je to lepší než jakékoliv jiné zabezpečení.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: perceptron 12. 06. 2018, 09:07:46
Citace
Security v praxi bývají docela molochy a mám teď na mysli Spring Boot Security, která mi zhoršila start aplikace tak o 15% a o dalších 15% mi zvětšila výstupní Jar-with-dependencies.
spring security vam da oauth ak chcete a out of box vyriesi cors, csrf, prip. jwt a dalsie veci ktore na vasej urovni naimplementujete po deadline a zle

15% narast startu je drobnost. 15% narast JAR - z 30 mega na 45? nosite jar na disketach?
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: . 12. 06. 2018, 13:40:53
Ok no, tak jdu stavet burzovni system s verejnym API pro management fondu a nebudu to zabezpecovat, diky za super radu.

Všechny api by měli být veřejné, citlivé části jako private s omezením na firewallu na ip. Zabezpečení "heslem, oauth2, jwt,.." na api je přežitek. Stejně tak jako všechny zdrojové kódy by měli být povinně opensource.
A tu fixní IP adresu pro uživatele zabezpečíte jak, pan{e,í} fundamentalist*o.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržika 12. 06. 2018, 14:23:23
A tu fixní IP adresu pro uživatele zabezpečíte jak, pan{e,í} fundamentalist*o.

A kdo zde mluví o uživatelích? V průvodní otázce se mluví přesně o aplikaci v js a backendu v rest, který chce zaheslovat.
Citace
Mám nějaký backend, jedno v čem napsaný, a chci mu zaheslovat REST. Frontend je zcela zvlášť, v javascriptu.
Takže frontend běží na nějakém serveru. server nemá pevnou ip? Pokud by šlo o api pro uživatele tak by tam přeci byl oauth, či jwt. Ale api je lepší míti public odpadne tím hromada starostí.

Mj fyi Eržika jak by vám moje jméno mělo napovídat je ženského původu. Ale chápu že si myslíte že cikánky nemohou programovat, že jen smrdíme na dávkách. Na dyskrymynace jsem ale zvyklá takže ok :)
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: . 12. 06. 2018, 16:58:10
A tu fixní IP adresu pro uživatele zabezpečíte jak, pan{e,í} fundamentalist*o.

A kdo zde mluví o uživatelích? V průvodní otázce se mluví přesně o aplikaci v js a backendu v rest, který chce zaheslovat.
Citace
Mám nějaký backend, jedno v čem napsaný, a chci mu zaheslovat REST. Frontend je zcela zvlášť, v javascriptu.
Takže frontend běží na nějakém serveru. server nemá pevnou ip? Pokud by šlo o api pro uživatele tak by tam přeci byl oauth, či jwt. Ale api je lepší míti public odpadne tím hromada starostí.
Možná jsem negramotný, ale mohla byste mi ukázat v příspěvku slovní spojení server a frontend, ze kterého jste vyvodila, že frontend běží na serveru? Javascriptová frontend aplikace běží zpravidla na klientském počítači v prohlížeči.

Mj fyi Eržika jak by vám moje jméno mělo napovídat je ženského původu. Ale chápu že si myslíte že cikánky nemohou programovat, že jen smrdíme na dávkách. Na dyskrymynace jsem ale zvyklá takže ok :)
Žádné dyskrymynace jsem se na vás nedopustil, možná, že jste si nevšimla, ale příspěvek jsem směřoval tak, abych oslovil všechna možná pohlaví. Je mi jedno, zda jste žena, muž nebo transvestita. Fajn, přejete si, abych Vás oslovoval jako ženu, to je super, ale z názvu nicku (navíc anonymního) nelze na internetu vyvozovat opravdu nic.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: gadzo 12. 06. 2018, 17:05:34
zabezpecte pomocou token based authentication, mozete si ukutit sam, ale radsej pouzite nejaky framework/kniznicu , usetrite si nervy.
ak erzika je naozaj erzika , tak klobuk dolu , niekdo smrdi na davkach, niekto v kode [ code smell ]
ale urcite je lepsie smrdiet v kode :-D
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: _Tomáš_ 12. 06. 2018, 21:29:42
Typl bych si ze duvodem bude, ze basic auth nepodporuje logout.

Tak credential je pouze enkodovane v Base64 a posila se po lince. Samozrejme TLS to prekryje, ale dalsi problemy jsou napr.:
- Heslo se posila stale dokola pro kazdy request v hlavicce
- Chybi dalsi rozsirene protekce jako Nonce, TTL, request timestamp, apod.pro zamezeni reply utoku

Ale jako, pokud se jedna o interni systemy, tak to nemusi byt problem, pokud se o dalsi bezpecnost staraji firewally, nebo dalsi prvky. Samozrejme stale to plati pouze pro TLS secured pripojeni.

Diskuze je o REST rozhraní, nemusí se očekávat, že se přihlašovací údaje budou zadávat v prohlížeči. Odhlášení chybí by design, není ale běžné, že by se aplikace na pozadí sama odhlašovala, to je běžnější pro interakci s uživatelem.

Zmíněné problémy je možné vyřešit zabalením do oauth, spnego, které timestampy, Nonce, TTL mají. Mimochodem, velká část korporátních SSO používá spnego s interním AD a poté REST s basic auth zase takový problém není :).
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržika 13. 06. 2018, 07:48:27
zabezpecte pomocou token based authentication, mozete si ukutit sam, ale radsej pouzite nejaky framework/kniznicu , usetrite si nervy.
ak erzika je naozaj erzika , tak klobuk dolu , niekdo smrdi na davkach, niekto v kode [ code smell ]
ale urcite je lepsie smrdiet v kode :-D

A já furt myslím že lepší je nezabezpečovat nic. Cikáni vám stejně ukradnou všecko i když to zabezpečíte. Zbytečná práce s tím. Však to píšu od začátku. Pro nás je nejlepší nemít zabezpečené nic. Máme pak jednoduší práci.

Ehm proč bych měla používat jiné jména než je moje skutečné? Vy to tak někdo děláte?  A proč?
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržika 13. 06. 2018, 09:34:18
Možná jsem negramotný, ale mohla byste mi ukázat v příspěvku slovní spojení server a frontend, ze kterého jste vyvodila, že frontend běží na serveru? Javascriptová frontend aplikace běží zpravidla na klientském počítači v prohlížeči.

Máte pravdu. Jsem jen blbá ženská a tak mám pomalejší vedení. Frontend sice běží na nějakém serveru, ale to není důležité, požadavky posílá klient ze své ip. Jsem prostě blbá, ženskž by neměli programovat oni mi to říkají furt kluci tady v kanclu.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: . 13. 06. 2018, 10:11:29
Možná jsem negramotný, ale mohla byste mi ukázat v příspěvku slovní spojení server a frontend, ze kterého jste vyvodila, že frontend běží na serveru? Javascriptová frontend aplikace běží zpravidla na klientském počítači v prohlížeči.

Máte pravdu. Jsem jen blbá ženská a tak mám pomalejší vedení. Frontend sice běží na nějakém serveru, ale to není důležité, požadavky posílá klient ze své ip. Jsem prostě blbá, ženskž by neměli programovat oni mi to říkají furt kluci tady v kanclu.
Jestli jste blbá ženská, to opravdu nevím, protože se neznáme, stejně jako vy nevíte, jestli jsem blbej mužskej. Ale vztahovačná jste poměrně dost.

Naznačil jsem, že by mne zajímalo, jak jste to myslela s tím serverem. Protože pod pojmem javascriptová aplikace posílající REST dotazy si já představím React nebo Angular JS aplikaci, která se sice na začátku stáhne z webového serveru, ale veškerá komunikace probíhá z klienta. Klasická webová stránka téměř nikdy neposílá REST požadavky.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržika 13. 06. 2018, 11:25:00
Protože pod pojmem javascriptová aplikace posílající REST dotazy si já představím React nebo Angular JS aplikaci, která se sice na začátku stáhne z webového serveru, ale veškerá komunikace probíhá z klienta.
Ano samozřejmě máte pravdu také jsem se v minulém příspěvku opravila.

Klasická webová stránka téměř nikdy neposílá REST požadavky.
Tady si dovolím nesouhlasit. REST komunikace probíhá ve standartních aplikacích také a to jak na straně frontendu (dotáhneme si pomocí js nějaká data z ext. rest rozhraní) a nemusí být nutně jen v uber top technologiích jako react/angular. Ale tam samozřejmě ten požadavek probíhá také ze strany klienta jak jsme si již vyjasnili.
Nicméně máme ještě kategorii rest požadavků ze strany serveru. Tj vyplním nějaký formulář, odešlu jej postem (či ajaxem či jakkoliv) na backend té app a ten se sám spojí s jiným rest api (či soapem, atp), odešle mu data, něco si uloží třeba i k sobě do db a vrátí nějaký výsledek na frontend zpátky. Tam ta komunikace ale probíhá server-server tedy i z ip serveru a naprosto nezáleží, že ten frontend je napsaný v reactu, jelikož má vlastní backend. Což je dosti častý případ. Mylně jsem si původně myslela tento případ, proto ta zbytečná diskuze.

Předpokládám ale, že zadavatel otázky myslel váš případ, tedy frontend v angularu bez jakéhokoliv backendu, s tím že komunikuje přes rest.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Eržik 07. 07. 2018, 16:05:43
private api s omezením na firewallu na ip

Aby mě nikdo nenařkl že zabezpečení na ip je nebezpečné, či že ip se často mění (tak určitě), tak stačí namísto IP využít TXT DNS record a vůči němu se api ověří. Vzhledem k https+dnssec je to lepší než jakékoliv jiné zabezpečení.

 Eržiko, mate asi rada bdsm, protoze ve vetsim prostredi skoncite s whitelistem dlouhym jak frontou na davky. Na testovani v kancliku dobry, reseni pres proxy je rozhodne elegantnejsi pro uzivatele "klient ma pristup na jejich webitko na testovacim serveru pres usr/pwd". Https+dnssec mi pripada sympaticky na rest apicka, jinak trochu zalezi co je treba, ale nejakej stunel muze taky poslouzit dobre. Mam asi uchylku, ale obecne nejak tak rad strkam apky do tunelu kdyz to jde.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Vlado 17. 07. 2018, 12:10:58
Vymýšľaš nanovo koleso. A ešte k tomu ho chceš vylepšiť tak, že ho urobíš hranaté... Klasické zabezpečenie je cez api key a je najjednoduchšie. Zložitejšie zabezpečenie je zase založené na tom, že po prihlásení obdržíš prístupový token a ten posielaš s každým api volaním a api si následne overuje platnosť toho tokenu. Nešpekuluj,  miesto zjednodušenia to svojim riešením iba komplikuješ.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Petr 17. 07. 2018, 12:20:23
Vymýšľaš nanovo koleso. A ešte k tomu ho chceš vylepšiť tak, že ho urobíš hranaté... Klasické zabezpečenie je cez api key a je najjednoduchšie. Zložitejšie zabezpečenie je zase založené na tom, že po prihlásení obdržíš prístupový token a ten posielaš s každým api volaním a api si následne overuje platnosť toho tokenu. Nešpekuluj,  miesto zjednodušenia to svojim riešením iba komplikuješ.

Nepochopil jsi, o čem jsem mluvil. Je normální, že se nad nějakou věcí zamyšlíš, řekněš si, jak bys to udělal ty sám, a potom to porovnáš s tím, jak se to dělá. Já měl problém s tím, že Spring Rest je takový leviathan, a zamýšlel jsem se nad tím, jak by to šlo udělat jednoduše na pár řádků kódu. Nikde jsem nenapsal, že to takhle chci dělat. Takže pro příště, až uvidíš, že se nad něčíém nějaký programátor takhle zamýšlí, tak mu neříkej, že objevuje kolo, nebo si o tobě bude myslet, že jsi dement, eventuálně ti to rovnou řekne.
Název: Re:Problematika zabezpečení REST rozhraní
Přispěvatel: Vlado 17. 07. 2018, 12:43:32
Inými slovami - nechápeš Spring Rest a tak to chceš vyriešiť nejakým vlastným, naivnejším spôsobom. Jo, to má logiku a ja som dement :)