Svaravlytting og sikkerhet med AngularJS

En applikasjon i den virkelige verden er mye mer kompleks enn bare å sende forespørsler til en tjeneste ved hjelp av de forskjellige metodene vi kan stole på AngularJSDet er ting som feil og unntakshåndtering, i tillegg til en veldig viktig sikkerhetsdel som vi må ta hensyn til.
Før et svar på en forespørsel når søknaden vår, må vi gjøre noe som kalles avlytting, det vil si at svaret skal passeres gjennom noen metoder og filtre før det kan være brukbart, på denne måten kan vi oppdage feil eller transformere dataene.
Når et svar kommer til applikasjonen vår, er det vanlig at vi må gjøre noen handlinger før vi presenterer dataene for brukeren, for eksempel validering av legitimasjon, datarensing, feilbehandling, alt for å gjøre applikasjonen vår så flytende som mulig uten å være utrygg.
Response InterceptorsFor dette har vi et API for $ q -metoden som lar oss bruke noe som heter Response InterceptorsMed dette kan vi utføre alle handlingene vi nevner på en enklere måte enn om vi måtte utvikle hver komponent for hånd.
La oss se et eksempel i det følgende bildet av en kode som implementerer a Response Interceptor:

FORSTØRRE

Vi ser hvordan vi får svaret, og vi sender det umiddelbart gjennom en tilpasset varslingsmetode der vi kan trekke ut feilene og deretter en feilloggmetode som vi kan skrive ut problemet i konsollen, til slutt hvis det skjer, avviser vi svaret slik at vår søknad gjør ingenting.
De sikkerhet Det er noe som er veldig viktig å ta i betraktning, når vi jobber på nettet, blir vi utsatt for at våre tjenester blir angrepet, hvor det kan være å nekte tjenesten, samt å skaffe dataene våre ulovlig.
I AngularJS formatet JSON Det er spesielt poenget vi må beskytte mest, siden det er en viktig del av forberedelsen av søknaden vår, her må vi huske på at de mest sensitive dataene ikke kan gis med en forespørsel FÅ, siden vi kan ha problemer med uautorisert tilgang.
En av måtene å beskytte oss selv er å alltid bruke a POST -metode når vi jobber med sensitiv informasjon for integriteten til vårt økosystem.
En annen form for beskyttelseDen andre måten vi kan bruke er å returnere a JSON ikke gyldig, med dette kan vi generere en logikk at når det mottar dette svaret, korrigerer det det, på denne måten vil den som ikke er involvert i teamet vårt ikke vite hvordan han skal dechiffrere dette.
Det er også et problem når et nettsted etterligner seg vårt for å få informasjonen vår, dette kalles CSRF, det vil si forfalskning av forespørsler mellom nettsteder, og det er det som kan forårsake oss mest skade.
Hvordan unngå CSRFFor å unngå dette må vi jobbe med mekanismer som bruk av Tokens som bare nettstedet vårt og dets klient gjenkjenner, så i den første spørringen etableres denne overskriften og følgende forespørsler hvis de ikke følger med overskriften, må avvises.