Zachycování odpovědí a zabezpečení s AngularJS

Aplikace v reálném světě je mnohem složitější než pouhé zadávání požadavků na službu pomocí různých metod, na které se můžeme spolehnout AngularJSExistují věci, jako je zpracování chyb a výjimek, a také velmi důležitá bezpečnostní sekce, kterou musíme vzít v úvahu.
Než odpověď na požadavek dorazí do naší aplikace, musíme udělat něco, čemu se říká odposlech, to znamená, předat odpověď některými metodami a filtry, než bude použitelná. Tímto způsobem můžeme detekovat chyby nebo transformovat data.
Když přijde odpověď na naši aplikaci, je běžné, že před předložením dat uživateli musíme provést nějaké akce, například ověření přihlašovacích údajů, čištění dat, zpracování chyb, to vše proto, aby byla naše aplikace co nejplynulejší, aniž by nejistý.
Interceptory odezvyK tomu máme API metody $ q, která nám umožňuje použít něco s názvem Interceptory odezvyDíky tomu můžeme provádět všechny akce, které zmiňujeme, jednodušším způsobem, než kdybychom museli každou součást vyvíjet ručně.
Podívejme se na příklad na následujícím obrázku kódu implementujícího a Interceptor odezvy:

ZVĚTŠIT

Vidíme, jak získáme odpověď, a okamžitě ji předáme vlastní metodou upozornění, kde bychom mohli extrahovat chyby, a poté metodou protokolu chyb, pomocí které můžeme problém vytisknout v konzole, nakonec pokud k tomu dojde, odpověď odmítneme, takže naše aplikace nedělá nic.
The bezpečnostní Je to něco, co je velmi důležité vzít v úvahu, když pracujeme na webu, jsme vystaveni útokům na naše služby, kde může být odmítnutí služby a nezákonné získání našich dat.
v AngularJS formát JSON Jedná se zejména o bod, který musíme nejvíce chránit, protože je důležitou součástí přípravy naší aplikace, zde musíme mít na paměti, že nejcitlivější údaje nelze poskytnout s požadavkem DOSTAT, protože bychom mohli mít problémy s neoprávněným přístupem.
Jedním ze způsobů, jak se chránit, je vždy používat a POST metoda když pracujeme s citlivými informacemi pro integritu našeho ekosystému.
Další forma ochranyDalší způsob, který můžeme použít, je vrátit a JSON neplatné, díky tomu můžeme vygenerovat logiku, že když obdrží tuto odpověď, opraví ji, takže kdo není zapojen do našeho týmu, nebude vědět, jak to dešifrovat.
Existuje také problém, který se nazývá, když se web vydává za naše, aby získal naše informace CSRF, tj. kování požadavků mezi weby a právě to nám může způsobit největší škody.
Jak se vyhnout CSRFAbychom tomu zabránili, musíme pracovat s mechanismy, jako je použití Žetony to rozpoznává pouze náš web a jeho klient, takže v prvním dotazu je toto záhlaví založeno a následující požadavky, pokud s uvedeným záhlavím nepřijdou, musí být odmítnuty.