Ten token je nesifrovany
Za prvé to není pravda, má i šifrovanou část. Za druhé jaké údaje byste tam chtěl šifrovat?
skor ci neskor ta aplikacia bude mat potrebu si siahnut k ulozisku uzivatelov, teda ak nechcete tym tokenom prenasat vsetky udaje o uzivatelovy.
Jaké všechny údaje?
Uz len pre to aby dokazala zobrazit pod akym uctom je uzivatel aktualne prihlaseny.
Zobrazí buď login, nebo přímo jméno uživatele. Login bude v tokenu uložen určitě, jméno uživatele tam může být také. Ale když to chcete jenom zobrazovat uživateli, není potřeba to přenášet na server a zpět – stačí to mít uložené v klientské části aplikace.
Tak isto bude musiet siahat pre dalsie udaje.
Které?
Podstata je v tom ze rovnako ako sa moze utocnik dostat k session id alebo k ulozenemu heslu, tak sa moze dostat aj k tokenu.
No a?
Session mozete zmazat, heslo zmenit ale pri sposobe overovania ako popisujete mozete akurat tak cakat az ten token strati platnost.
Opět – čemu to vadí? Token ztratí platnost třeba za 5 minut. Pokud jo chcete umožnit ještě rychlejší odhlášení, můžete mít v mikroslužbách seznam zneplatněných tokenů a když se uživatel odhlásí, všem aplikacím ID toho zneplatněného tokenu rozeslat.
A k comu inemu by ste chcel pouzit synchronizaciu uloziska session medzi servermi php.
Když mám klasickou starou monolitickou aplikaci.
Tak budeme mat beznu konfiguraciu, a konfiguraciu per uzivatel do ktorej si php scrip pred dobehnutim zapise data potrebne v ramci sedenia pre dalsi dotaz. Mmnt, to uz tam implementovane je, vola sa to session. Funguje to uplne inak ako v jave, flasku, alebo v AWS(ada web server)
Vidím, že se v tom neorientujete, pokusím se vám to vysvětlit. Existuje nějaká globální konfigurace aplikace, v ní budou uložené např. adresy serverů (jiných služeb), o kterých jste psal. Vedle toho existuje něco, čemu se říká session – data uložená na serveru, která jsou spojená s přihlášením konkrétního uživatele. Klient posílá s každým požadavkem identifikátor session (obvykle v sookie, ale může být i součástí URL). Server si na zákaldě ientifikátoru dohledá údaje ze session v nějakém úložišti – může to být paměť, disk, SQL databáze, NoSQL databáze… Funguje to úplně stejně v PHP, v Javě, Flasku.
Jop, staci im k tomu JWT token. 
Ano, stačí. Nevím, co je na tom směšného – tohle je mikroservisová architektura.
Ale vazne, to ako pisat php script bez pouzitia session mozete vysvetlovat tvorcom drupalu, wordpressu, nette a mnohym dalsim co kedy nieco v php napisali. Obavam za ze si z vas budu tak trochu utahovat...
To jsou ovšem monolity. Mezi tím byla ovšem vynalezena architektura microservice, která se pro mnohé služby hodí lépe. Její největší výhodou je to, že je horizontálně vlemi dobře škálovatelná. Proto ji právě používají Google, Facebook, Twitter, Netflix a další. vesterna12 se ptal právě na architekturu mikroslužeb, ostatně je to i v názvu tématu. Takže vaše návrhy, jak byste to dělal „po staru“ jako monolit jsou sice hezké, ale neodpovídají na tazatelův dotaz. („Po staru“ není myšleno nijak pejorativně, monolitická architektura má stále své opodstatnění – mikroservisy nejsou žádný zázračný lék, mají svá negativa a mají zpočátku větší režii, než monolit.)
Zobrazit příspěvky
