Příspěvky

76

Vývoj / Re:PHP - mikroslužby - autentizace

« kdy: 01. 08. 2021, 15:16:32 »

Cílem je opustit kompletně php_session().
Chci co nejsnadnější škálování.
Možná Docker/Kubernetes, ale to mi přijde jako zbytečná další abstrakce (a spotřeba HW + další údržba). Automatizací posílám "Git release" na příslušné stroje. Stroje mám škálované pomocí skriptů. Do 10 minut je server vzhůru.
Replikace relací je další zbytečná komplikace.
Je vyloučeno, aby klient při každém dotazu posílal znovu jméno a heslo uložené v nějakém objektu.
Nechci ani cache autentizace a autorizace na koncových bodech api.
Co nejméně volání do DB,AD,Kafky,AMQ, nebo Redisu.
Žádné sdílené disky mezi servery. Výjimku mají pouze CDN segmenty.
Funkci si chystám tak aby byla schopná dotazování AD, protože jeden zdroj pravdy už mám. Jako druhý autentizační poskytovatel bude MYSQL databáze a poslední CURL volání do extérního systému.
Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče. Pokud se klient pokusí data podvrhnout je vyloučeno data podepsat důvěryhodným klíčem (uložen na HSM), který má pouze autentizační server.
Autorita je chráněná. Jen tak si někdo certifikát nepodepíše...

Programuju příležitostně a nevěděl jsem jestli není moje teorie zastaralá.
Děkuji panu Jiráskovi za jeho trpělivost a vysvětlení.

77

Vývoj / Re:PHP - mikroslužby - autentizace

« kdy: 30. 07. 2021, 17:21:07 »

Čistě teoreticky. Útočník podvrhne DNS a přesměruje klienta na svůj server. Tam mu vnutí JS a k tomu tokenu se stejně dostane. Je to tak? To stejné platí o cookies. Klidně by tak mělo jít přečíst PHP_SESSION_ID.
Jedině kdyby klient kontroloval certifikační autoritu, která podepsala certifikát web serveru. Pak by útočník musel napadnout přímo server kde aplikace běží.

Pokud útočník ovládne doménu, nemáte jak se mu bránit – prohlížeč si bude myslet, že komunikuje s legitimním serverem a dovolí mu všechno – číst sessionStorage, bude mu odesílat cookies, dovolí vložit do formuláře uložená hesla.

Dneska už to ale reálně nebude fungovat přesměrováním DNS, protože jakýkoli rozumný web jede přes HTTPS s certifikátem od důvěryhodné certifikační autority. HTTP klienti certifikáty kontrolují, takže útočník, který by přesměroval přes DNS jednoho klienta, má smůlu. Pokud by se ovšem útočníkovi podařilo přesměrovat DNS globálně (nejspíš tak, že získá přístup do správy DNS příslušné domény), nechá si vygenerovat i důvěryhodný certifikát.

Inu přidaná hodnota sessionStorage vs cookie je pouze ta že token není odeslán při každém požadavku na doménu pokud není získán JS.
Správně?

78

Vývoj / Re:PHP - mikroslužby - autentizace

« kdy: 30. 07. 2021, 16:21:02 »

Když se musí token načítat ze sessionStore, musel by útočník spustit JavaScript v rámci příslušné webové aplikace na dané doméně, čemuž se dá mnohem lépe bránit.

Čistě teoreticky. Útočník podvrhne DNS a přesměruje klienta na svůj server. Tam mu vnutí JS a k tomu tokenu se stejně dostane. Je to tak? To stejné platí o cookies. Klidně by tak mělo jít přečíst PHP_SESSION_ID.
Jedině kdyby klient kontroloval certifikační autoritu, která podepsala certifikát web serveru. Pak by útočník musel napadnout přímo server kde aplikace běží. 

79

Vývoj / PHP - mikroslužby - autentizace

« kdy: 30. 07. 2021, 11:41:24 »

Čas opustit monolit.
Chtěl bych aplikaci rozložit do několika mikroslužeb kvůli škálování. Pro autentizaci k mikroslužbám bych rád použil "cookie", která by obsahovala info o autentizaci a autorizaci. Cookie by byla šifrována certifikátem. Přijde mi to jaké dobré řešení. Taky se vyhnu bombardování databáze pro každý dotaz na autorizaci. Pro nucené odhlášení všech uživatelů bych vynutil zneplatnění všech "cookie", které nemají id administrátora a časové razítko starší XY.
Jsem úplně mimo? Existuje elegantnější řešení?

80

Odkladiště / Re:Trávíte korporátní birokracií víc času než prací?

« kdy: 22. 07. 2021, 18:36:21 »

Jistě i školení typu neznásilňovat kolegyni na kopírce, nekrást firemní data, neberte úplatky, černá kámoška z Ugandy je taky kolegyně nebo jak se stát teamovým hráčem a všechny milovat to už všechno proběhlo, ale ta četnost je nízká a snesitelná.

Dřív ta práce byla zajímavá. Řešili jsem zajímavou problematiku různých technologií. Teď spíš grafy co kde jak správně vyplnit a reportovat. Mám pár kolegů, který mám rád a kteří umí. To je asi ten poslední důvod proč tam ještě jsem. Hypo nemám... Je to u Vás lepší?

81

Odkladiště / Trávíte korporátní byrokracií víc času než prací?

« kdy: 22. 07. 2021, 16:12:40 »

Porady...
Asi tak poslední rok trávím snad víc času poradami než samotnou prací.
Včas se většinou nezačíná. Úvody jsou zbytečně dlouhé a o ničem. Mluvit k věci dovede málokdo což poradu natahuje snad nejvíc. Na konci většinou není žádný jasný závěr. Lidi netuší co mají vlastně dělat a na co se čeká, ale všichni odchází spokojeni a popřejí si pěkný zbytek dne...
Pochopitelně tenhle scénář není pokaždé stejný, ale dost často se opakuje. Managery to pochopitelně netrápí...

Závislosti na ostatních teamech...
Co team to jiný nástroj na vytváření požadavků.
Některé nástroje fungují jenom když máte levý palec u nohy v puse a holíte si u toho záda.
SLA prakticky není. Musíte prosit a doufat. Eskalace se nenosí. Můj šéf mi radí "slušně se připomenout".

Emaily zachrání všechno....
Každá sračka co něco "důležitého" reportuje posílá email. Každý krok v tiketu, každý příspěvek na firemní sociální síti...
Mám už pravidlo, které to hází rovnou do koše. Na tikety se chodím dívat v pravidelných intervalech. Pokud někdo
něco chce urgentního tak zavolá. Monitoring neignoruju...
Email místo tiketu je taky za trest. Sdílený mail box. Do dnešního dne nejsou kolegové schopni používat značky a tak dva na lidi na jednom serveru řeší tu stejnou věc...

Hesla, piny, tokeny....
Bitlocker a po přihlášení k počítači musíte zadat několikrát pin "making sure it's juuuu"....
Přes Citrix na vzdálenou plochu a tam konečně SSH na server. A pak "Citrix receiver" přestal pracovat.


Aktualizace...
V ten nejméně vhodný čas. Invazivní oznámení, které Vám minimalizuje všechna okna. Pokud odložíte instalaci, okna se obnoví, ale v úplně jiných rozměrech a na úplně jiných místech. Kterej dement tohle navrhuje?

SEKURITA....
To teď strašně letí. Audit bezpečnosti. Dotazník delší než toaletní papír ve kterým všichni tvrdí "KOMPLAJENT". Není výjimkou, že se Vás jedna otázka ptá na dvě odlišné věci, ale odpověď je pouze ano/ne. Autor dotazníku často není schopný vysvětlit na co se vlastně chtěl zeptat...

Požadavky na dovolenou....
To už teď zadáváme do 3 systémů.

Ten nekonečný Excel....
Další fenomenální tabulka s nějakým plánem co má písmo 7čkou a hraje 10 barvami. To důležité je na poslední stránce a červeně. Přece!

Docházka...
Sice máme, ale výkaz musíme dělat stejně. Data se nepropisují.

Ty klaudy...
Řešit minuty běhu 4xCPU, 8G je vážně opruz.

Firemní noťas...
Celkem dělo, ale pustím si tam tak maximálně "Excel". Na vývoj tak leda box v Amazonu a přístup přes Citrix.

Je to už celkem otrava. Přišel jsem si hrát s technologií, ale tohle mi už leze krkem. Říkám si že je to jinde i horší, ale je tomu vážně tak?

82

Odkladiště / Re:Měniče napětí 12V / 230V

« kdy: 19. 07. 2021, 11:13:47 »

v datasheetu viz Poznamka 5 v kolecku: maximum package current 75 A (*12V) = 900W

Ale tim, ze to neni sepnuto porad, ale je tam "sinusovka", tak je proud nekdy vetsi a nekdy mensi.
Pro trvale 1500W zatizeni je potreba holt paralelniho zapojeni, 125A na 12V nechces tahat nozickou jednoho obvodu.

I kdyby ten fet byl idealni a mel tech 8mR, tak to mas 125A x 0.008 R = 1V ubytek, 125W tepelnych ztrat. Tj. potrebujes to chladit viceme stylem jako CPU.

Pro tri paralelne, to mas  125/3 = 41.66A x 0.008 R = 0.333 V ubytek, 13.8W ztrat (*3) = 41.66 W ztrat celkem. Snad vidis ten rozdil.

Btw v 2200VA APC UPS jsou taky tri fety paralelne... ale kdyz jsem ji opravoval (jeden byl v zkratu a znicilo to battery pack, ktery je na 48V), tak jsem rovnou osadil vsech 6 ktere bylo mozne na desku dat (stejna deska pro 3000VA model) tak predpokladam ze to bude rado za tuhle upravu.

Jinak delat 1500W z 12V je pekna pitomost.. tech 125A je dost narocne na vsechny spoje/konektory.

Díky! Tohle mi moc pomohlo!

83

Sítě / Re:Komunikace mezi dvěma deskami Arduino

« kdy: 19. 07. 2021, 01:04:20 »

OpenWrt je v tomhle úplně skvělý. V minulosti jsem používal právě sériový port na desce pro čtečku karet. V závěru z toho byl docházkový systém. Jediné co chybělo byla podpora openssl, ale je to už tak 5 let zpátky...
Můžete poslat jaký HW používáte? Proč jste nepoužil Arduino s Wifi, ESP32 nebo rovnou Raspberry?

84

Odkladiště / Měniče napětí 12V / 230V

« kdy: 19. 07. 2021, 00:21:03 »

V následujícím schématu
https://i.ytimg.com/vi/Q520RbW9aOs/maxresdefault.jpg
je paralelní zapojení 3 MOSFETŮ pro kladnou a zápornou půlvlnu.
Pode dokumentace k mosfetu  https://www.alldatasheet.com/datasheet-pdf/pdf/68131/IRF/IRF3205.html by měl stačit na každou půlvlnu jeden. Proč tam jsou tři?
Ne že bych se to chystal stavět, ale rád bych tomu trošku víc rozuměl.
K transformátoru...
Je opravdu možné, aby následující transformátor https://www.alibaba.com/product-detail/High-Frequency-Electronic-Transformer-EE55-40khz_1600118019378.html?spm=a2700.7724857.normal_offer.d_image.7bc96375YXbseKdodával 1kW při správném buzení?

85

Sítě / Re:Komunikace mezi dvěma deskami Arduino

« kdy: 18. 07. 2021, 16:26:34 »

Na ethernet se dostane pouze ústředna, které se bude dotazovat na autentizaci a autorizaci načtených karet.
Celé řešení bude používat vlastní záložní zdroj.
V případě, že server není dostupný info o autentizaci a autorizace bude dostupné na kartě.
Linku připojovat před barák zatím nemůžu, protože nevím jak dostatečně ochránit komunikaci proti odposlechu komunikace. Moc jsem to ještě neměl čas zkoumat. Pochopitelně ochrana proti zkratu atd. s tím počítám...
Zatím jde o klasické 125 Khz klíčenky.

86

Sítě / Re:Komunikace mezi dvěma deskami Arduino

« kdy: 18. 07. 2021, 14:47:39 »

Ústředna se bude doptávat čteček v cyklech jestli mají data k odeslání (id karty). Kolize tak snad nebudou vznikat. Každá čtečka dostane vlastní statické id. Z toho asi plyne logičtěji Modbus nebo teda RS485

87

Sítě / Komunikace mezi dvěma deskami Arduino

« kdy: 18. 07. 2021, 11:58:17 »

Pro komunikaci mezi ústřednou a čtečkou přemýšlím nad použitím ModBus nebo CAN. Do budoucna bych chtěl čtečky přidávat. Vzdálenost mezi ústřednou a čtečkou nepřesahuje 40M. Pokud je tu někdo kdo řešil podobný problém jaký protokol se Vám osvědčil?

88

Odkladiště / Re:Hybridní invertory solárních elektráren

« kdy: 17. 07. 2021, 11:19:57 »

Dotaz opravdu z prostředka + ta věta je nějaká divná, ale pokud správně chápu na co se ptáš...:

Nikde se nic nepřepíná - to je blbost. Prostě invertor jen monitoruje tok proudů a pokud zjistí že ze sítě se odebírá X, tak o to X začne dodávat energii z baterek. Naopak když se zátěž vypne a on uvidí že nějaký proud mu teče DO sítě, tak hned na výkonu ubere.

Tak pokud se nepřepíná mezi sítí a baterií tak by invertor musel zvládat přifázování a také zabránit tomu, aby energie netekla zpět do distribuční sítě.

89

Odkladiště / Hybridní invertory solárních elektráren

« kdy: 16. 07. 2021, 13:07:58 »

Pokud baterie nejsou dostatečně nabité, invertor čerpá energii z distribuční sítě.
Může mi někdo erudovanější vysvětlit jakým principem toto přepínání mezi baterií a distribuční sítí funguje bez výpadku napětí na spotřebiči?

90

Hardware / Re:Nabíjení olověného akumulátoru v UPS

« kdy: 16. 07. 2021, 12:27:18 »

Zdroj bude raději 15V.
Napětí pro baterii bude 13,5.
Nabíjecí proud bych chtěl nastavit na 500mA.

Předřadný odpor tak bude 3Ohm 0,75W.