Vielen lieben Dank für die ausführliche Erklärung. Das hat mir sehr weiter geholfen. Da steckte doch mehr dahinter als ich dachte. Semantic versioning ist auch ein tolles und wichtiges Thema. Freue mich schon.
Ich finde das neue Format sehr vielversprechend. Mal sehen wie gut der Spagat mit der Themenverteilung funktioniert, aber ich bin optimistisch. Es wäre schade wenn Architekturthemen unter der Zusammenfassung leiden würden.
[gr] Cool, das freut mich, vielen Dank! Was die Themenverteilung angeht, hoffen wir, einen guten Mix hinzubekommen. Diese Woche ist es tatsächlich etwas Dev-lastiger, aber ich denke, langfristig wird sich das ausgleichen. Und wie gesagt Wenn Du Ideen, Wünsche, … für Themen hast - immer her damit 😊
Theorie: Es macht nur für ganz ganz wenige APIs Sinn "Access-Control-Allow-Origin: *" zu nutzen. Realität: Frage: Warum steht da ein "*"? Antwort: Sonst geht es nicht.
Hallo, bedeutet das, dass wenn ich von meiner Webseite, welche auf meinem Synology NAS liegt einen fetch auf einen Rechner in meinem Netzwerk mache, dass deshalb nicht geht, weil die Synology ungleich der REST API auf dem anderen Rechner ist? Dies Funktioniert allerdings, wenn ich einen eigenen Webserver mit express erstelle und von dort aus den fetch ausführe. => Warum geht das denn in diesem Fall??? denn der Port und damit der Server ist ja auch unterschiedlich. Wenn ich mit dem fetch Befehl eine Datei öffnen möchte, welche im Verzeichnis der Anwendug liegt, so geht das auch solange es auf einem Server läuft. warum geht das nicht, wenn meine Anwendung lokal auf meinem systemliegt und über bspw. die index.html durch Doppelklick geöffnet wird? Danke schon mal für die Antworten.
[gr] Im Prinzip ja. Die Webseite (also die UI) und die API müssen vom gleichen Host kommen (gleicher Hostname und gleicher Port), damit der Zugriff ohne CORS funktioniert. Stammen sie von unterschiedlichen Hosts muss man CORS für die API entsprechend konfigurieren. Wichtig dabei ist aber, dass der Server (also die API) nur die Information liefert, verhindert wird der Zugriff vom Browser. Es ist also ein Sicherheitsfeature des Browsers - was auch erklärt, warum es nicht für Server, die als Relay auftreten, gilt.
Vielen lieben Dank für die ausführliche Erklärung. Das hat mir sehr weiter geholfen. Da steckte doch mehr dahinter als ich dachte. Semantic versioning ist auch ein tolles und wichtiges Thema. Freue mich schon.
[gr] Freut mich sehr, dass wir weiterhelfen konnten - und wenn Du weitere Ideen oder Wünsche hast, immer gene in die Kommentare damit 😊
Ich finde das neue Format sehr vielversprechend. Mal sehen wie gut der Spagat mit der Themenverteilung funktioniert, aber ich bin optimistisch. Es wäre schade wenn Architekturthemen unter der Zusammenfassung leiden würden.
[gr] Cool, das freut mich, vielen Dank!
Was die Themenverteilung angeht, hoffen wir, einen guten Mix hinzubekommen. Diese Woche ist es tatsächlich etwas Dev-lastiger, aber ich denke, langfristig wird sich das ausgleichen.
Und wie gesagt Wenn Du Ideen, Wünsche, … für Themen hast - immer her damit 😊
super erklärt. Danke. jetzt ist da Licht am Tunnelende ;)
[gr] Das hört sich doch gut an 😊
richtig gut erklärt, vielen Dank!
Vielen Dank 😊
super verständlich, vielen Dank!
[gr] Gerne 😊
Sehrschön erklärt! 💫
Vielen Dank aus Georgia!
[gr] Gerne, das freut mich 😊
Jetzt alle dreimal schnell hintereinander Access-Control-Allow-Origin' header. ;)
Das Format gefällt mir besser, also etwas tiefer einzusteigen. (Mal wieder was gelernt). Danke. Was sind das für Pads an deinem Whiteboard?
[gr] Das freut mich, vielen Dank für Dein Feedback!
Die Pads sind die hexagonalen Shapes von Nanoleaf.
Cool Danke :)
Theorie: Es macht nur für ganz ganz wenige APIs Sinn "Access-Control-Allow-Origin: *" zu nutzen.
Realität: Frage: Warum steht da ein "*"? Antwort: Sonst geht es nicht.
[gr] 🤣
Wie kann man denn am besten den Client vor Script-Injection schützen, dass in der Webseite keine Anfragen an ganz fremde Server geschickt werden?
👍
[gr] Danke 😊
Hallo, bedeutet das, dass wenn ich von meiner Webseite, welche auf meinem Synology NAS liegt einen fetch auf einen Rechner in meinem Netzwerk mache, dass deshalb nicht geht, weil die Synology ungleich der REST API auf dem anderen Rechner ist?
Dies Funktioniert allerdings, wenn ich einen eigenen Webserver mit express erstelle und von dort aus den fetch ausführe.
=> Warum geht das denn in diesem Fall??? denn der Port und damit der Server ist ja auch unterschiedlich.
Wenn ich mit dem fetch Befehl eine Datei öffnen möchte, welche im Verzeichnis der Anwendug liegt, so geht das auch solange es auf einem Server läuft.
warum geht das nicht, wenn meine Anwendung lokal auf meinem systemliegt und über bspw. die index.html durch Doppelklick geöffnet wird?
Danke schon mal für die Antworten.
[gr] Im Prinzip ja. Die Webseite (also die UI) und die API müssen vom gleichen Host kommen (gleicher Hostname und gleicher Port), damit der Zugriff ohne CORS funktioniert. Stammen sie von unterschiedlichen Hosts muss man CORS für die API entsprechend konfigurieren. Wichtig dabei ist aber, dass der Server (also die API) nur die Information liefert, verhindert wird der Zugriff vom Browser. Es ist also ein Sicherheitsfeature des Browsers - was auch erklärt, warum es nicht für Server, die als Relay auftreten, gilt.
@@thenativeweb danke für die Erklärung.
Das bedeutet, von Server zu Server geht immer?
[gr] Ganz genau 😊
@@thenativeweb
Also: Client => Server = SOP & CORS
Server => Server (bspw. Ein eigener Express Server zu einer API) = völlig frei?
[gr] Ja.