Interceptie en beveiliging van reacties met AngularJS

Een toepassing in de echte wereld is veel complexer dan alleen een verzoek indienen bij een dienst met behulp van de verschillende methoden waarop we kunnen rekenen in AngularJSEr zijn zaken als het afhandelen van fouten en uitzonderingen, evenals een zeer belangrijk beveiligingsgedeelte waar we rekening mee moeten houden.
Voordat een reactie op een verzoek onze applicatie bereikt, moeten we iets doen dat onderschepping wordt genoemd, dat wil zeggen, het antwoord door een aantal methoden en filters laten gaan voordat het bruikbaar kan zijn, op deze manier kunnen we fouten detecteren of de gegevens transformeren.
Wanneer een reactie op onze applicatie komt, is het gebruikelijk dat we enkele acties moeten uitvoeren voordat de gegevens aan de gebruiker worden gepresenteerd, bijvoorbeeld validatie van inloggegevens, gegevensopschoning, foutafhandeling, allemaal om onze applicatie zo vloeiend mogelijk te maken zonder dat onzeker.
Reactie-interceptorsHiervoor hebben we een API van de $ q-methode waarmee we iets kunnen gebruiken met de naam Reactie-interceptors, hiermee kunnen we alle acties die we noemen op een eenvoudigere manier uitvoeren dan wanneer we elk onderdeel met de hand zouden moeten ontwikkelen.
Laten we een voorbeeld bekijken in de volgende afbeelding van een code die a . implementeert Reactie Interceptor:

VERGROTEN

We zien hoe we het antwoord verkrijgen en we geven het onmiddellijk door een aangepaste meldingsmethode waar we de fouten kunnen extraheren en vervolgens een foutenlogboekmethode waarmee we het probleem in de console kunnen afdrukken, als dat gebeurt, weigeren we het antwoord zodat onze applicatie doet niets.
De veiligheid Het is iets dat heel belangrijk is om rekening mee te houden, wanneer we op internet werken, worden we blootgesteld aan aanvallen op onze services, waar het kan zijn om de service te weigeren en om onze gegevens illegaal te verkrijgen.
In AngularJS het formaat JSON Het is met name het punt dat we het meest moeten beschermen, aangezien het een essentieel onderdeel is van de voorbereiding van onze aanvraag, hier moeten we in gedachten houden dat de meest gevoelige gegevens niet kunnen worden gegeven met een verzoek KRIJGEN, omdat we problemen kunnen krijgen met ongeautoriseerde toegang.
Een van de manieren om onszelf te beschermen is om altijd een POST-methode: wanneer we werken met gevoelige informatie voor de integriteit van ons ecosysteem.
Een andere vorm van beschermingDe andere manier die we kunnen gebruiken is om terug te keren a JSON niet geldig, hiermee kunnen we een logica genereren dat wanneer het dit antwoord ontvangt, het het corrigeert, op deze manier zal iedereen die niet bij ons team betrokken is, niet weten hoe dit te ontcijferen.
Er is ook een probleem dat wanneer een site de onze imiteert om onze informatie te verkrijgen, dit wordt genoemd CSRF, dat wil zeggen, het vervalsen van verzoeken tussen sites en het is wat ons de meeste schade kan toebrengen.
Hoe CSRF te vermijdenOm dit te voorkomen moeten we werken met mechanismen zoals het gebruik van Munten die alleen onze site en zijn client herkennen, dus in de eerste query wordt deze header vastgesteld en de volgende verzoeken als ze niet met die header komen, moeten worden afgewezen.