Svaravlyssning och säkerhet med AngularJS

En verklig applikation är mycket mer komplex än att bara göra förfrågningar till en tjänst med hjälp av de olika metoderna som vi kan räkna med AngularJSDet finns saker som fel- och undantagshantering, liksom ett mycket viktigt säkerhetsavsnitt som vi måste ta hänsyn till.
Innan ett svar på en begäran når vår ansökan måste vi göra något som kallas avlyssning, det vill säga passera svaret genom några metoder och filter innan det kan vara användbart, på så sätt kan vi upptäcka fel eller transformera data.
När ett svar kommer till vår applikation är det vanligt att vi måste göra några åtgärder innan vi presenterar data för användaren, till exempel validering av referenser, datarensning, felhantering, allt för att göra vår applikation så flytande som möjligt utan att vara osäker.
Response InterceptorsFör detta har vi ett API för $ q -metoden som gör att vi kan använda något som heter Response Interceptors, med detta kan vi utföra alla åtgärder som vi nämner på ett enklare sätt än om vi var tvungna att utveckla varje komponent för hand.
Låt oss se ett exempel i följande bild av en kod som implementerar a Svar Interceptor:

FÖRSTORA

Vi ser hur vi får svaret och omedelbart skickar vi det genom en anpassad aviseringsmetod där vi kan extrahera felen och sedan en felloggmetod med vilken vi kan skriva ut problemet i konsolen, slutligen om det händer avvisar vi svaret så att vår ansökan gör ingenting.
De säkerhet Det är något som är mycket viktigt att ta hänsyn till, när vi arbetar på webben utsätts vi för att våra tjänster attackeras, där det kan vara att neka tjänsten, samt att få våra uppgif.webpter olagligt.
I AngularJS formatet JSON Det är särskilt den punkt som vi måste skydda mest, eftersom det är en viktig del i förberedelsen av vår ansökan, här måste vi komma ihåg att de mest känsliga uppgif.webpterna inte kan ges med en begäran SKAFFA SIG, eftersom vi kan ha problem med obehörig åtkomst.
Ett av sätten att skydda oss själva är att alltid använda a POST -metod när vi arbetar med känslig information för integriteten i vårt ekosystem.
En annan form av skyddDet andra sättet vi kan använda är att returnera a JSON inte giltigt, med detta kan vi generera en logik att när det får detta svar, det korrigerar det, på detta sätt kommer den som inte är inblandad i vårt team inte att veta hur man dechiffrerar detta.
Det finns också ett problem när en webbplats efterliknar vår för att få vår information, detta kallas CSRF, det vill säga att förfalska förfrågningar mellan webbplatser och det är det som kan orsaka mest skada.
Hur man undviker CSRFFör att undvika detta måste vi arbeta med mekanismer som användning av Tokens som bara vår webbplats och dess klient känner igen, så i den första frågan etableras denna rubrik och följande förfrågningar om de inte kommer med rubriken måste avvisas.