# Weiterleitung mit gesetzten Header-Fields



## dennisbauer (2. Feb 2019)

Hallo,

ich habe versucht, die Problematik mithilfe von Google verstehen bzw. einschränken zu können, meine Kenntnisse in dem Bereich der Kommunikation mit Javascript sind jedoch sehr beschränkt.

Grundlegend habe ich Spring als Rest-Service im Einsatz, der mir meine Ressourcen bereitstellt (.js, .html, .css) und auch eine kleine Business-Logic Schicht mit drin. Nun möchte ich jedoch so vorgehen, dass bestimmte Ressourcen erst auf Serverseite geladen werden, sobald eine Authentifizierung stattgefunden hat. Die Authentifizierung auf Spring-Seite zu realisieren ist nicht das Problem, jedoch möchte ich gerne ein Loginverfahren entwickeln, mit dem ich nach erfolgreichem Login die Seite neu laden möchte und dabei ein Header-Feld setze.

Gibt es da in Javascript die Möglichkeit, dass ich dort zum Neuladen bestimmte Header setzen kann? Ich denke da z.B. an den Authorization-Block.

Ich weiß, dass es verschiedenste Frameworks dafür gibt, Angular, React, möchte jedoch gerne Low-Level entwickeln und die Vorgänge verstehen, bevor ich da irgendein Framework reinziehe.

Vielen Dank schonmal im Voraus für eure Antworten


----------



## httpdigest (2. Feb 2019)

Header kannst du nur für asynchrone AJAX/XmlHttpRequest Requests setzen. Die Frameworks, die du nennst, nutzen unter der Haube alle die vom Browser bereitgestellte Schnittstelle, um im Hintergrund (nachdem die Seite geladen wurde) asynchrone Requests (XHR für XmlHttpRequest) an den Server zu senden.
Wenn du das Ganze synchron beim Page Reload benötigst, solltest du (vom Server ausgehend) Cookies setzen, wenn der Benutzer eingeloggt ist. Solche Cookies werden pro Domäne auch immer vom Browser automatisch zum Server mitgesendet, wenn etwa ein Full Page Reload geschieht, um die Seite neu zu laden (z.B. wenn du per <a>-Tag oder per Formular-POST einen neuen Pfad anspringst oder eine neue URL eingibst und Enter drückst oder Ctrl+R oder eine der anderen synchronen Reload-Möglichkeiten).
EDIT:
Eine andere Möglichkeit, den Authorization Header zu senden, ist via Standard 401 Unauthorized Statuscode beim Laden der Seite und WWW-Authenticate Header im Server-Response. Daraufhin wendet der User Agent / Browser ein Standardverfahren an, um den Benutzer nach Username und Passwort zu fragen und sendet dann automatisch per Authorization Header diese Informationen base64-codiert an den Server. Siehe: https://en.wikipedia.org/wiki/Basic_access_authentication


----------



## dennisbauer (2. Feb 2019)

Via unauthorized das Basic auth triggern zu können, wäre keine schlechte Idee. Ich habe damit aktuell auch viel zu tun, leider möchte ich meine eigene Authentifizierung da reinhauen und über den authorization handler validieren.
Da ich unter dem gleichen Endpunkt arbeite und das über die Startseite geregelt wird, ist diese Variante aber leider nicht praktikabel.

Ich werde wohl oder übel über die Cookies gehen oder dynamisch neue javascript und Templates nachladen müssen wenn das synchron über den Browser nicht realisierbar ist.


----------

