11
Dumme Frage zum Prinzip von Webapps die Frontend und Backend getrennt haben
Hallo,
leider eine dumme Frage zum Prinzip von Webapps die Frontend und Backend getrennt haben.
Ich habe dazu aber auch nach ein paar Stunden YT Videos keine wirkliche Aussage gefunden.
Entweder verstehe ich etwas falsch oder ...
Ich komme eigentlich aus der Softwareentwickling für Windows.
Web ist also alles anders. Ich habe schon einiges programmiert als Fullstack und alles von Hand.
Ausgangsbasis
Admin-Anwendung mit Anmeldung.
Backend ist eine reine REST-API.
Frontend soll HTML, CSS und JS sein.
Jetzt mal egal ob mit oder ohne Framework.
Das Frontend liefert die HTML-Seite mit CSS und JS aus.
Das JS holt dann die Daten und füllt die Elemente, die per HTML geliefert wurden, mit Daten.
Heist für mich, dass der FE-Server gar keine Daten hat.
Worher weiß der nun aber ob der User angemeldet ist oder nicht?
Ob er die Seite darstellen darf oder die Anmeldeseite?
Stefan
leider eine dumme Frage zum Prinzip von Webapps die Frontend und Backend getrennt haben.
Ich habe dazu aber auch nach ein paar Stunden YT Videos keine wirkliche Aussage gefunden.
Entweder verstehe ich etwas falsch oder ...
Ich komme eigentlich aus der Softwareentwickling für Windows.
Web ist also alles anders. Ich habe schon einiges programmiert als Fullstack und alles von Hand.
Ausgangsbasis
Admin-Anwendung mit Anmeldung.
Backend ist eine reine REST-API.
Frontend soll HTML, CSS und JS sein.
Jetzt mal egal ob mit oder ohne Framework.
Das Frontend liefert die HTML-Seite mit CSS und JS aus.
Das JS holt dann die Daten und füllt die Elemente, die per HTML geliefert wurden, mit Daten.
Heist für mich, dass der FE-Server gar keine Daten hat.
Worher weiß der nun aber ob der User angemeldet ist oder nicht?
Ob er die Seite darstellen darf oder die Anmeldeseite?
Stefan
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3863101464
Url: https://administrator.de/contentid/3863101464
Printed on: April 19, 2024 at 04:04 o'clock
11 Comments
Latest comment
Hallo,
nun das lässt sich recht einfach erklären an folgendem Flows:
Login Frontend -> Request ans Backend -> Überprfüung vom Backend -> Übertragung eines AuthTokens ans Frontend -> Frontend legt AuthToken in einem Cookie ab.
Frontend frägt nach Berechtigungen -> Backend übermittelt Berechtigungen -> Frontend enabled / disabled Elemente
nun das lässt sich recht einfach erklären an folgendem Flows:
Login Frontend -> Request ans Backend -> Überprfüung vom Backend -> Übertragung eines AuthTokens ans Frontend -> Frontend legt AuthToken in einem Cookie ab.
Frontend frägt nach Berechtigungen -> Backend übermittelt Berechtigungen -> Frontend enabled / disabled Elemente
1
Hallo,
das Prinzip ist mir schon klar.
Aber die praktische Seite nicht.
Man ruft im Browser app.project.de auf.
Der Web-Server bekommt eine Anfragen für app.project.de/.
Der Web-Server weiß aber noch gar nicht wer das ist.
Soll er die Login-Seite ausliefern oder das Dashboard?
eigentlich müsste er eine leere Seite ausliefern.
Das JS prüft per API ob der Benutzer angemeldet ist und man dann eine Weiterleitung auf /login oder /dashboard
Das ganze ist deutlich einfacher wenn man FE und BE nicht trennt.
Mein Problem ist weniger mich in ein System einzudenken, als mich für eine der 1000 verschiedenen Varianten von Frameworks und Sprachen zu entscheiden...
Ich will doch nur ein kleines Admin-Dahsboard
Benutzerverwaltung mit 2FA
Ein paar Listen zum darstellen und bearbeiten und fertig.
Stefan
das Prinzip ist mir schon klar.
Aber die praktische Seite nicht.
Man ruft im Browser app.project.de auf.
Der Web-Server bekommt eine Anfragen für app.project.de/.
Der Web-Server weiß aber noch gar nicht wer das ist.
Soll er die Login-Seite ausliefern oder das Dashboard?
eigentlich müsste er eine leere Seite ausliefern.
Das JS prüft per API ob der Benutzer angemeldet ist und man dann eine Weiterleitung auf /login oder /dashboard
Das ganze ist deutlich einfacher wenn man FE und BE nicht trennt.
Mein Problem ist weniger mich in ein System einzudenken, als mich für eine der 1000 verschiedenen Varianten von Frameworks und Sprachen zu entscheiden...
Ich will doch nur ein kleines Admin-Dahsboard
Benutzerverwaltung mit 2FA
Ein paar Listen zum darstellen und bearbeiten und fertig.
Stefan
Hallo,
nun wenn es für dich nur ein kleines "Listenbearbeitungstool" sein sollte, dann macht es nicht wirklich sinn
das ganze in FE & BE zu trennen in meinen Augen.
Ein wesentlicher Vorteil bei der Trennung von FE & BE ist halt, dass unterschiedliche Teams daran arbeiten könnten ( was in deinem Fall als Fullstack ja auch entfällt ), weiters wäre aber noch die Möglichkeit dadurch gegeben andere Systeme ans BE anzuflanschen.
Was evtl. für dich Interessant sein könnte https://adminjs.co/ damit ist eigentlich schon sehr viel zusammengeschlossen, was speziell im Bereich DB, UserManagement passt.
Hier noch der Link zur Demo Github:
https://github.com/SoftwareBrothers/adminjs-example-app
grüße
nun wenn es für dich nur ein kleines "Listenbearbeitungstool" sein sollte, dann macht es nicht wirklich sinn
das ganze in FE & BE zu trennen in meinen Augen.
Ein wesentlicher Vorteil bei der Trennung von FE & BE ist halt, dass unterschiedliche Teams daran arbeiten könnten ( was in deinem Fall als Fullstack ja auch entfällt ), weiters wäre aber noch die Möglichkeit dadurch gegeben andere Systeme ans BE anzuflanschen.
Was evtl. für dich Interessant sein könnte https://adminjs.co/ damit ist eigentlich schon sehr viel zusammengeschlossen, was speziell im Bereich DB, UserManagement passt.
Hier noch der Link zur Demo Github:
https://github.com/SoftwareBrothers/adminjs-example-app
grüße
Hallo,
es soll schon BE und FE sein.
Dass FE macht demnächst Jemand Anderes und ich dann nur das BE.
Ich will aber das Prinzip verstanden haben und das verbiegt mir aktuell noch das Hirn.
es soll schon BE und FE sein.
Dass FE macht demnächst Jemand Anderes und ich dann nur das BE.
Ich will aber das Prinzip verstanden haben und das verbiegt mir aktuell noch das Hirn.
Hallo,
dann sag mal wo du deinen Knopf im der Denke hast? eigenltich ist das ja sehr simple gestrickt.
Man baut sich ein Backend das auf Basis einer REST-Api alles liefert.
CRUD ( Create Read Update Delete ) Actions
PERMISSIONS
Ein Bsp zu den CRUD:
Das ganze bildest du dann im BE ab und hinterlegst zu den jeweiligen endpoints noch eine Permission,
die du dann gegen den aktuellen token ( ergo user ) prüfst.
dann sag mal wo du deinen Knopf im der Denke hast? eigenltich ist das ja sehr simple gestrickt.
Man baut sich ein Backend das auf Basis einer REST-Api alles liefert.
CRUD ( Create Read Update Delete ) Actions
PERMISSIONS
Ein Bsp zu den CRUD:
URL Method Params Response
restapi/auto/list GET filter Liefere alle Autos gefiltert mit filter
restapi/auto/id PUT infos Erzeuge Auto mit infos
restapi/auto/id GET id Infos zum Auto mit der id
restapi/auto/id PATCH Id, infos Update info zu Auto mit id
restapi/auto/id DELETE id Lösche Auto mit idDas ganze bildest du dann im BE ab und hinterlegst zu den jeweiligen endpoints noch eine Permission,
die du dann gegen den aktuellen token ( ergo user ) prüfst.
Der Web-Server weiß aber noch gar nicht wer das ist.
Soll er die Login-Seite ausliefern oder das Dashboard?
Soll er die Login-Seite ausliefern oder das Dashboard?
Solange er nicht genaueres weiss, natürlich das Login. Sobald er weiss, wer die Person ist durch die Login-Authentifizierung (und gespeichert durch Cookie wie von godlie beschrieben oder SessionStorage) das Dashboard.
Um es kurz zu machen: Es läuft, wie schon erwähnt wurde, normalerweise rein mit Cookie.
Mit Login bekommt der Nutzer einen Cookie mit Auth-Token gesetzt, der wird mit jedem danach kommenden Request ja jedes Mal übermittelt. Wenn der Token gültig ist, funktioniert die Anfrage an die API, andernfalls halt nicht.
Mit Login bekommt der Nutzer einen Cookie mit Auth-Token gesetzt, der wird mit jedem danach kommenden Request ja jedes Mal übermittelt. Wenn der Token gültig ist, funktioniert die Anfrage an die API, andernfalls halt nicht.
Hallo,
vieleicht sehe ich das etwas nicht.
Aber sowohl Session als auch Cookie hat der Browser ja mit dem BE-Server, z.B. api.firma.de.
Dies gilt ja nicht für den FE-Server, z.B. app.firma.de.
Der BE-Server könnte dem Client ein Token zurückliefern.
Diesen schickt der Client zum FE-Server und dieser Fragt beim BE-Server zurück ob das Token gültig ist.
Stefan
vieleicht sehe ich das etwas nicht.
Aber sowohl Session als auch Cookie hat der Browser ja mit dem BE-Server, z.B. api.firma.de.
Dies gilt ja nicht für den FE-Server, z.B. app.firma.de.
Der BE-Server könnte dem Client ein Token zurückliefern.
Diesen schickt der Client zum FE-Server und dieser Fragt beim BE-Server zurück ob das Token gültig ist.
Stefan
Dein FE könnte das Cookie-Value einfach durchreichen?
Zitat von @StefanKittel:
Aber sowohl Session als auch Cookie hat der Browser ja mit dem BE-Server, z.B. api.firma.de.
Dies gilt ja nicht für den FE-Server, z.B. app.firma.de.
Aber sowohl Session als auch Cookie hat der Browser ja mit dem BE-Server, z.B. api.firma.de.
Dies gilt ja nicht für den FE-Server, z.B. app.firma.de.
Was meinst du damit, dass es "das mit dem BE-Server hat"?
Sessionstorage oder localstorage sind lokal auf deinem Rechner gespeichert bzw. leben im RAM in deinem Browser. Welche Werte da reingeschrieben werden oder wieder ausgelesen steuert dein Javascript. Ob Javascript die Werte wie ein Auth-Token von deinem BE-Server holt oder irgendwas vom FE-Server oder über eine API Wetterdaten von einem Server in der Antarktis, ist völlig egal. Dein Javascript holt sich die Werte und schreibt diese zur weiteren Verwendung in die Sessionstorage.
Hallo,
bei Session spreche ich vom "traditionellen" Server-basierten-Session. Mit einem Cookie im Browser als ID.
Alles was der Browser im RAM hat, kann ja gestohlen oder manipuliert sein.
Stefan
bei Session spreche ich vom "traditionellen" Server-basierten-Session. Mit einem Cookie im Browser als ID.
Alles was der Browser im RAM hat, kann ja gestohlen oder manipuliert sein.
Stefan
