Laden...

AngularJS : Auslesen eines HTTP Headers aus RouteProvider

Erstellt von Ahrimaan vor 8 Jahren Letzter Beitrag vor 8 Jahren 1.716 Views
A
Ahrimaan Themenstarter:in
350 Beiträge seit 2010
vor 8 Jahren
AngularJS : Auslesen eines HTTP Headers aus RouteProvider

Hallo zusammen,

ich habe gerade eine kleine Herausforderung:

Ich mache über OWIN Oauth. Dazu gibt es die External Login Methode.
In dieser übergibt man den Provider zB Google und eine Callback URL.
Diese URL wird von der AngularWebApp generiert.

Im RouteProvider

 $routeProvider.when("/authComplete", {//Code here}

springt er nach erfolgreicher Authentifizierung rein.
ABER: Der Access Token wird von der WebAPi aus Securitygründen (Bitte nicht darüber diskutieren, ist eine Firmenvorgabe) in den Header geschrieben.

Wie komme ich nun im Routeprovider an den Access Token aus dem Header ran ?
Irgendwie finde ich nur Beispiele mit dem $httpProvider, dieser wird dafür aber nicht genutzt.
Ein $httpInterceptor wird nicht angepsorchne, da dieser bei Route Change nicht reagiert.

Hat jmd eine Idee ?

Grüße

16.806 Beiträge seit 2008
vor 8 Jahren

Dass das natürlich vollkommen gegen den Standard ist und ihr damit ohnehin mit negativen Effekten rechnen müsst; das denke ich ist Dir nicht neu.
Bei Security Themen vom Standard abzuweichen... Viel Spaß oder herzlichen Glückwunsch schon mal an dieser Stelle dazu. =)

Vermutlich kommst Du an dieser Stelle gar nicht an den Header, sondern wirst Dir den HTTP Interceptor schreiben müssen, üblicherweise als Service.
Den hängst Du dann via $httpProvider.interceptors.push('ServiceName'); ein (in der app.config(function(...) { hier } );. Vermutlich weiß Du das aber bis hier hin schon.

Bedeutet aber gleichzeitig, dass Du starke Abhängigkeiten haben wirst, da der Interceptor die Validierung übernehmen muss.
Ebenso muss der Interception eine ungültige Authentifizierung dem $rootscope via broadcast mitteilen, sodass die Anwendung überhaupt merkt, dass hier was krumm ist.

Ohne httpInterceptor wüsste ich nicht, wie Du an der Stelle an den Header kommen würdest.
Aber warum sollte der nicht angesprochen werden?
Ich hab das schon einige male mit States verwendet und würde mich jetzt schon wundern, wenn das nicht mehr gehen sollte.

A
Ahrimaan Themenstarter:in
350 Beiträge seit 2010
vor 8 Jahren

Danke für die Glückwünsche 😛
Du weißt ja ich bin in einem Konzern und kann manchen Irsinn hier einfach nicht umgehen 😕

Das Problem ist, bei einem 302 mit der Location wird der Interceptor nicht aufgerufen, bei anderen Requests schon ...
Deswegen dachte ich, er reagiert nicht darauf.
Wenn du sagst es wäre wohl der einzig gangbare Weg muss ich wohl schauen warum genau der Interceptor in diesem Falle nicht reagiert.

Der Interceptor ist Beispielhaft erstmal so implementiert

.factory('AuthInterceptor', [function () {
    return {
        'request': function (config) {
            //console.info(config);
            return config;
        },
        'response': function (response) {
            //console.info(response);
            return response;
        }
    };
}]);
$httpProvider.interceptors.push('AuthInterceptor');

Ich teste wie gesagt mal durch

Grüße

16.806 Beiträge seit 2008
vor 8 Jahren

Ich hab auch in einem Konzern gearbeitet bis Oktober - und sehr vieles kann sich ändern, wenn man gegenüber den Entscheidern von Standards redet, das Prinzip erklärt und es ein größeres Risiko ist, davon abzuweichen.
Jedenfalls ist meine Erfahrung, dass in einem Konzern manchmal Entscheidungen von Personen getroffen werden (sollen), die mit der Materie leider nicht ganz so vertraut sind. Und diese Leute brauchen eben etwas mehr Beratung zur Entscheidungsfindung, als wenn Du jetzt direkt drin steckst.

Ein Service ist hier besser als eine Factory, denn es gibt keinen Grund, dass der Interceptor die ganze Zeit neu erstellt wird.

HTTP 302 (Redirect) ist eine Sonderrolle, da Angular allgemein diesen Fehler nicht erhält, sondern bereits der Browser abfängt. Es kommt gar nicht im DOM an. Du kannst es nicht auswerten.
Daran wirst Du - egal was Du in Deiner App machst - nichts ändern können. Es ist einfach nicht Teil des XmlHttpRequests.

Das einzig technische, was Dir bei 302 bleibt ist, einen anderen Statuscode zu senden.

A
Ahrimaan Themenstarter:in
350 Beiträge seit 2010
vor 8 Jahren

Das mit dem Konzern probiere ich bereits, bisher erfolglos.

Zum Thema 302 : Danke für diesen Hinweis, dann werde ich wohl oder übel dieses umbauen. Das habe ich bisher nicht gewusst. 😃

Grüße

A
Ahrimaan Themenstarter:in
350 Beiträge seit 2010
vor 8 Jahren

Hi Abt, hi die anderen die das Thema interessiert.

Ich habe mittlerweile durch Machine Key Sharing usw. die Apis mit einander verheiratet, auch das 302 "problem" konnte ich lösen und durchsetzen, dass der Token per URL kommt und ausgelesen wird.
Zum Glück ist es nur ein Proof of Concept 😉

Da mir diese ganze Lösung nicht gefällt, da wir für die Security selber zuständig sind in der API sind wir dabei die Preiview von Windows Server 2016 dazu zu nutzen einen ADFS aufzusetzen, welcher die Authentisierung gegen unsere DB und gegen social Logins anbietet, sich damit auch um Refreshtokens etc. kümmert.

Bisher sieht das ganze recht fruchtbar aus.

Grüße