Příspěvky

76

Vývoj / Re:Problematika zabezpečení REST rozhraní

« kdy: 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? :-)

77

Vývoj / Re:Problematika zabezpečení REST rozhraní

« kdy: 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.

78

Vývoj / Re:Problematika zabezpečení REST rozhraní

« kdy: 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.

79

Vývoj / Re:Problematika zabezpečení REST rozhraní

« kdy: 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

80

Vývoj / Re:Problematika zabezpečení REST rozhraní

« kdy: 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/

81

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 09. 06. 2018, 13:44:26 »

1) Který jazyk je jednodušší zvládnout, aby člověk mohl být zaměstnán jakožto junior a rychleji?

JavaScript

2) Pokud bych chtěl dělat enterprise aplikace - je vhodnější java (EE) nebo .net?

JavaScript

3) S kterým jazykem lze jednodušeji se dostat do IT světa?

JavaScript

Opravdu nerad bych tu začínal flame, ale JavaScript není úplně nejjednodušší opravdu zvládnout. Ale jinak je to pěkný jazyk.

Ad 1) bych možná zvážil Python, ač ho dvakrát nemusím.

82

Desktop / Re:Jaké distro s XFCE

« kdy: 23. 05. 2018, 12:43:11 »

Gentoo of course

83

Sítě / Re:Pomalá síť a nic na firewallech

« kdy: 26. 02. 2018, 12:47:49 »

Ve smlouvě byste měli mít i jak co, jakým způsobem, ověříte, plus nějaké SLA.

Jestli tam mají dark fiber, tak to je nedohlížené vlákno, bez kontroly. Pak by měly být na obou stranách nějaké převodníky. Obvykle se tohle řešilo testem linky v délce 1+ hodiny, pokud bylo bez chyb tak ok.

Mimochodem kdybyste pro ně byli lukrativní partner tak vám nabídnou nějakou zálohu a pořeší to jako poskytovatel infrastruktury sami. I tohle je možnost - po technologii X nám to šlape jak víno a po infrastruktuře od vás se to se*e ... dělejte s tím něco.

Diky za hint, tak SLA je proste spatne o tom zadna, to uz vime, mame ted objednany audit, ktery by mel overit soucasny setting a zejmena doporucit, jak to resit za soucasneho stavu a i doporucit a navrhnout, co to bude znamenat, kdyz budeme chtit prejit k jinemu vendorovi, protoze tohle je spis tresnicka na dortu :-)) je to pozen

84

Sítě / Re:Pomalá síť a nic na firewallech

« kdy: 26. 02. 2018, 12:45:06 »

Samozrejme existuje realne podezreni, ze je problem nekde na MPLS levelu, ale tam to resi vendor...

85

Sítě / Re:Pomalá síť a nic na firewallech

« kdy: 26. 02. 2018, 12:07:08 »

Kdyby to byla "korporátní síť" přes síť poskytovatele, tak vezmu jeden "packet capture" na straně serveru (aplikace) a druhý na straně klienta. Co vyleze na jedné straně se musí dostat na druhou stranu. Ideálně bez znatelného zpoždění.

Sit nemame rozhodne pod kontrolou ani v nejakem read only modu na urovni switchu a firewallu, proste nam nechtej dat ani observable mode. Asi vedi proc, nebo rikaj, ze to neni mozne :-)))) tomu se vzdycky vysmeju na meetingu, kdyz to slysim. Ale servery jsou pod nasi kontrolou, nektere jen user, jine root. Zkusime udelat tento scenar. To dava smysl

86

Sítě / Re:Pomalá síť a nic na firewallech

« kdy: 26. 02. 2018, 11:53:37 »

Zdravim, v Brusellu provozujeme operacni centrum
Ja osobne zde navrhuju microservice architektury

A to v té Bruseli nemáte nějaké síťaře, kteří by to vyřešili? To je hroznej úpadek, když Belgikánci musí škemrat o pomoc zadarmo zde na divokém východě....

Bohuzel mame celou infrastrukturu jako sluzbu vcetne personalu a sam jsem je uz nekolikrat usvedcil z prime lzi. Priravujeme i reseni je kompletne opustit a prejit jinam, ale vzheledem k tomu, ze poskytujeme sluzby tykajici se bezpecnostnich analyz v ramci pumpovani elektriny po evrope, tak to neni uplne jednoducha zalezitost, i z pohledu legislativy, norem, ktere jsou ruzne pres ruzne staty, apod....

87

Sítě / Re:Pomalá síť a nic na firewallech

« kdy: 26. 02. 2018, 11:51:23 »

Jj, uz to musi resit i architekt :-)))

Vec se ma tak, ze behame na tzv black fibers (fyzicke nesdilene linky) vs white fibers (sdilene linky). Nasim infrastructure vendorem je firma Atos, ktera nam samozrejme dodala i "sitove experty", kteri behem nekolika dni na nic neprisli :-((( s tim, ze nevidi nic podezreleho. Tato firma si ale nektere sitove linky pronajima od dalsiho providera, tj. litame z Belgie po dalsich zemich, nez se dostaneme do Francie....

Tech aplikaci, ktere jsou afektovane je vicero, vsechny. Jelikoz v tom sam nejsem zainteresovany naplno, ale uz me to sere, protoze ta blokada trva uz nekolik tydnu a uzivatele mi breci u stolu v oficu, tak jsem si rekl, ze to zkusime nejak objevit z nasi klientske strany, ackoli chapu, ze moznosti jsou v tomto pripade omezene.

Opravdu tato diskuze neni o tom, jestli architekt resi sitove problemy od vendora, proste kdyz je kriticky problem, tak delam cokoli :-)) Takze diky pouze za podnety technickeho razu, ktere mohou pomoci k objeveni priciny ze strany klienta (nas)

Ja budu zpet v officu az ve stredu, tak to proberem, protoze zrovna ted jsem dostal dalsi pozdavake na pomoc s resenim :-))) jako ja se tomu taky smeju, ale evidentne si s tim nevedi nejak rady... me osobne napadlo, ze je tam nejaka smycka, nebo neco u nas v lokalni siti, protoze aplikace jsou pomale na servery (remote), ale linky nemaji zadny velky provoz...

88

Sítě / Re:Pomalá síť a nic na firewallech

« kdy: 23. 02. 2018, 11:34:57 »

Diky za podnety, pristi tyden odzkousim zde navrhovane postupy a postnu vysledky.

89

Sítě / Re:Pomala sit a nic na firewallech

« kdy: 23. 02. 2018, 10:19:13 »

Nice.

90

Sítě / Pomalá síť a nic na firewallech

« kdy: 23. 02. 2018, 09:59:35 »

Zdravim, v Brusellu provozujeme operacni centrum, pripojujeme se odtamtud do dvou datovych center ve Francii.

Aplikace tahaji data hrozne pomalu, vypada to, jako by nekdo saturoval sit, ale na firewallech neni v logu videt nic zvlastniho, sit se jevi jako volna, resp. to jsou ukazky naseho infrastructure vendora, ktery uz nekolik mesicu neni schopen odhalit a napravit pricinu.

Napadlo me, jestli to nemuzou zpusobit nejake cykly v siti, spatne nastavene routy, apod.

Existuji nejake nastroje, ktere by dokazali odhalit nabo pomoci odhalit pricinu z klientske stanice? Jinak je sit nase a muzeme si tam delat co chceme samozrejme, takze instalace i nejakych tools typu nmap nebo kali linux neni problem. Jde o to, ze tahani z francie je pomale, ale oni tvrdi, ze sit je prazdna. To mi trochu nahrava do scenare, ze je problem nekde v nasi budove, ale vendor nam take vylozene nekdy lze, takze je tu problem s duverou informaci, ktere nam prezentuje... Jedna se o firmu Atos.

Diky za jakekoli podnety, napady, jak na odhaleni takoveho problemu. Pristup na firewally osobne nemame, zadali jsme read only, ale bylo to zamitnuto ze strany vendora.

Ja osobne zde navrhuju microservice architektury, ale tohle nas uz tizi delsi dobu, tak me napadlo zeptat se zdejsi TOP class komunity, jestli nekdo vidi nejakou cestu, jak se zhostit teto trisky v noze.

Diky.

Lada