Fetch lokal nicht möglich

[Bennyaa]

Hallo, ich kann mit einem fetch weder auf eine lokale Datei, noch auf einen Webserver, welcher auf dem gleichen Rechner läuft zugreifen.
Wenn ich versuche auf die lokale Datei zu zu greifen (und die Anwendung von extern Aufrufe), dann gehts zumindest.
Wenn ich aber lokal einfach die Index.html aufrufe, dann kommt wieder der zugriffsfehler (cors policy).
Gibts denn keine Möglichkeit irgendwie lokale JSON einlesen zu können, so dass es auch mit lokalem Aufruf der html Datei funktioniert?
Und warum kann ich nicht auf einen anderen Server auf meinem Rechner zugreifen?
Über die Adressleiste der Webbrowsers klappt es ja auch.

 

[andy_m4]

Kein Code, keine Erklärung was Du genau und womit machst.
Deine Fragestellung ist für den PoPo. Versuchs nochmal.

 

[0x8100]

https://de.wikipedia.org/wiki/Cross-Origin_Resource_Sharing

 

[Bennyaa]

Kein Code, keine Erklärung was Du genau und womit machst.
Deine Fragestellung ist für den PoPo. Versuchs nochmal.

Ok sorry…. 2. Versuch:

fetch("datei.json")
.then(function(response){
return response.json()
})
.then(function(data){
console.log(data)
});

Das funktioniert, wenn ich es über den Liveserver von vs Code Aufrufe,
Aber nicht, wenn ich lokal einfach die html Datei aufrufe, welche die js Datei implementiert.

Genauso geht das hier garnicht (wird immer geblockt)

fetch("mydomain.de/REST/Anfrage.json")
.then(function(response){
response.json()
})
.then(function(data){
console.log(data)
})

 

[andy_m4]

Wenn ich mich nicht irre braucht fetch für "remote" immer eine vollständige URL.
Also sowas wie mydomain.de/REST/Anfrage.json reicht da nicht. Da muss sowas stehen wie:
https://mydomain.de/REST/Anfrage.json
oder wie auch immer die vollständige URL aussieht.

Genauso geht das hier garnicht (wird immer geblockt)

Was heißt das? "Wird geblockt"?

 

[Joshinator]

Das funktioniert, wenn ich es über den Liveserver von vs Code Aufrufe,
Aber nicht, wenn ich lokal einfach die html Datei aufrufe, welche die js Datei implementiert.

Also ich fände es nicht so toll wenn der Browser einfach so auf das lokale Dateisystem zugreifen kann.
Wenn du mit JS einfach auf "C:\alle_meine_passwoerter.txt" zugreifen kannst würd jede böse Website versuchen alle möglichen Dateien zu lesen.

Wenn der VSCode Server läuft versucht dein Browser nicht eine lokale Datei zu lesen, sondern eine gültige (lokale) URL.
Es gibt ne lokale Filesystem API, aber die ist Chrome-only aktuell.

Genauso geht das hier garnicht (wird immer geblockt)

Wurde dir oben schon verlinkt, das nennt sich CORS.

Wenn "mydomain.de/REST/Anfrage.json" deinem Browser nicht sagt "hey, localhost:8080, du darfst Dateien von mir einfach so laden" dann macht der Browser das auch nicht.
Sonst wär jede Website ein Botnetz wo jeder Besucher unfreiwillig jemand externes DDoSsen könnte.

Es gibt Addons die diesen Sicherheits-Check umgehen, zum entwickeln recht nett. Wenn das auf nem Server liegt gibt es das Problem ja auch nicht mehr, wird dann alles von der selben Domain geliefert und CORS ist zufrieden.

 

[Bennyaa]

Also ich fände es nicht so toll wenn der Browser einfach so auf das lokale Dateisystem zugreifen kann.
Wenn du mit JS einfach auf "C:\alle_meine_passwoerter.txt" zugreifen kannst würd jede böse Website versuchen alle möglichen Dateien zu lesen.

Wenn der VSCode Server läuft versucht dein Browser nicht eine lokale Datei zu lesen, sondern eine gültige (lokale) URL.
Es gibt ne lokale Filesystem API, aber die ist Chrome-only aktuell.



Wurde dir oben schon verlinkt, das nennt sich CORS.

Wenn "mydomain.de/REST/Anfrage.json" deinem Browser nicht sagt "hey, localhost:8080, du darfst Dateien von mir einfach so laden" dann macht der Browser das auch nicht.
Sonst wär jede Website ein Botnetz wo jeder Besucher unfreiwillig jemand externes DDoSsen könnte.

Es gibt Addons die diesen Sicherheits-Check umgehen, zum entwickeln recht nett. Wenn das auf nem Server liegt gibt es das Problem ja auch nicht mehr, wird dann alles von der selben Domain geliefert und CORS ist zufrieden.

Das komische ist ja:
Ich habe meine Webseite auf meinem synology NAS laufen. (Normaler Port 80)
Und die abzufragende url ist auf einem anderen Rechner im Netzwerk. Aber da kommt die gleiche Meldung.

 

[0x8100]

lies dir bitte den wikipedia-link durch. wenn deine anwendung per fetch eine url auf einem anderen server abfragt, dann muss dieser das explizit erlauben und das als http-header in der antwort mitschicken.

 

[Bennyaa]

Ok, aber warum geht es, wenn ich die url direkt in die Browser adresszeile eintrage?
Und warum geht es, wenn ich einen eigenen Server mit Express erzeuge?
Verstehe den Sinn nicht.
Und zu der Aussage, dass der Browser nicht lokal zugreifen soll…. Wenn er auf dem Server liegt, dann greift er ja darauf zu und nicht lokal.
Meine idee war ja, dass er nur lokal da zugreift, wo die Datei liegt.
Sprich: liegt auf dem Server, dann wird dort lokal geschaut und wenn man sich die Verzeichnisse auf den Rechner kopiert, dann so dort eben nach geschaut werden.
Ist das sooooo abwegig?

Oder bezieht sich die url / das Verzeichnis auf den ausführenden Client?

 

[floq0r]

Ist das sooooo abwegig?

Jaaaaa
Du hast scheinbar immer noch nicht den oben verlinkten Wiki Artikel und den weiterführenden Artikel gelesen: https://de.m.wikipedia.org/wiki/Same-Origin-Policy

 

[Bennyaa]

Jaaaaa
Du hast scheinbar immer noch nicht den oben verlinkten Wiki Artikel und den weiterführenden Artikel gelesen: https://de.m.wikipedia.org/wiki/Same-Origin-Policy

Ok, also jetzt stehe ich total auf dem Schlauch.
Erst dachte ich der Sender und Empfänger dürfen nicht gleich sein, jetzt verstehe ich den Artikel so, dass sie gleich sein müssen….
Ist das so?
Wenn ja, warum gehen dann bspw. Lokale Daten nur, wenn ein Webserver läuft und warum kann ich keinen fetch auf einen lokalhost senden? Weil der Port abweicht?

 

[bog]

ist eigentlich recht einfach: aktuelle browser halten die SOP ein.

ausnahmen der SOP kann ein zielserver (in dem fall bspw. der server auf dem deine .json-datei liegt; "B") per CORS headers deklarieren. in dem fall darf dann ein script, das auf origin A ausgefuehrt wird auch eine ressource von origin B aufrufen.

eine ausnahme fuer letzteres sind wiederum dateisystem-URIs (also wenn du die .html-datei einfach aus dem dateimanager im browser oeffnest), die auf nichts zugreifen koennen (zumindest per xhr/fetch in chrome?).

ein origin definiert sich ueber protokoll (http/s) + domain + port

 

[Bennyaa]

Das bedeutet ich kann mit einem fetch aus dem browser heraus nur:
1. Dateien einlesen, wenn die App auf nem Webserver läuft und dort die Dateien liegen.
2. eine http Anfrage an genau diesen Webserver stellen.

3. KEINE Rest Abfrage von 3. durchführen?
=> Dachte dafür sollte fetch genutzt werden können.

 

[0x8100]

wie jetzt schon mehrfach geschrieben, kann man mittels fetch daten von einem anderen server aus nur abrufen, wenn dieser cors mit hilfe von http-header explizit erlaubt. siehe https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

wenn du diesen externen server nicht kontrollierst und cors konfigurieren kannst, dann muss deine anwendung die daten von dort serverseitig holen und selbst an den client ausliefern anstatt das dem browser des clients zu überlassen. in diesem fall ist die same-origin-policy wieder erfüllt.

 

[BeBur]

Sprich: liegt auf dem Server, dann wird dort lokal geschaut und wenn man sich die Verzeichnisse auf den Rechner kopiert, dann so dort eben nach geschaut werden.
Ist das sooooo abwegig?

Ja ist es. Wie schon geschrieben wurde willst du, dass eine Website auf gar keinen Fall Zugriff erhält auf dein Dateisystem. Auch nicht mit "Bestätige hier mal eben, sonst kannst du Win11CrackNoVirusTopPlusPremium.exe nicht runterladen" u.ä.
Browsser bzw. HTML haben aber sehr ausgiebige Caching-Mechanismen, so dass nicht immer alles neu geladen werden muss. In diese Richtung könntest du mal schauen.

 

[Bennyaa]

wie jetzt schon mehrfach geschrieben, kann man mittels fetch daten von einem anderen server aus nur abrufen, wenn dieser cors mit hilfe von http-header explizit erlaubt. siehe https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

wenn du diesen externen server nicht kontrollierst und cors konfigurieren kannst, dann muss deine anwendung die daten von dort serverseitig holen und selbst an den client ausliefern anstatt das dem browser des clients zu überlassen. in diesem fall ist die same-origin-policy wieder erfüllt.

Ja ok aber:
warum kann ich denn von einem programm, welches auf meinem rechner, oder einem rechner im netzwerk läuft keine rest api abfragen?
wenn ich die adresse der rest api inden webbrowsereintragen funktioniert es ja auch und er gibt mit ein JSON zurück.

 

[BeBur]

warum kann ich denn von einem programm, welches auf meinem rechner, oder einem rechner im netzwerk läuft keine rest api abfragen?

Es gibt hier drei Akteure: Dein Browser, der Server A und dein REST API Server B. Wie man dir schon schrieb, sobald Domäne[bzw. IP]/Port/Protokoll von A und B nicht identisch sind sind das zwei unterschiedliche Akteure und wenn du A ansurfst dann ist in dem Moment B ein "Drittserver", ob der 'im selben Netzwerk' ist ist da komplett irrelevant und imHo auch gar nicht im Allgemeinen trivial zu ermitteln vom Browser.

wenn ich die adresse der rest api inden webbrowsereintragen funktioniert es ja auch und er gibt mit ein JSON zurück.

In dem Fall gibt es auch keine drei Akteure und keinen "Drittserver".

Ganz simples Beispiel:
Du gehst auf Website X und die sagt dann: 'Browser, hol mir mal bitte ganz Wikipedia auf Nacken von deinem Nutzer". Nicht so gut.

 

[Bennyaa]

Es gibt hier drei Akteure: Dein Browser, der Server A und dein REST API Server B. Wie man dir schon schrieb, sobald Domäne[bzw. IP]/Port/Protokoll von A und B nicht identisch sind sind das zwei unterschiedliche Akteure und wenn du A ansurfst dann ist in dem Moment B ein "Drittserver", ob der 'im selben Netzwerk' ist ist da komplett irrelevant und im Ho auch gar nicht im Allgemeinen trivial zu ermitteln vom Browser.

Das bedeutet man kann nur zwei unterschiedliche Parteien miteinander Kommunizieren lassen?
Also Bspw. wenn man einen eigenen Server hat und dieser den fetch an eine andere Rest API stellt?
Sobald einbrowser als client drin ist gehts nicht mehr?

In dem Fall gibt es auch keine drei Akteure und keinen "Drittserver".

Hier geht es, weil nur 2 akteure aktiv sind?

 

[Joshinator]

Das ganze einmal Schritt für Schritt zum mitschreiben:

• User öffnet example.com in seinem Browser
• irgendwo auf der Seite wird Javascript geladen
• das Javascript sagt "lad mal was von computerbase.de/irgendeine_ressource"
• der Browser macht jetzt folgendes:
• ist die aktuelle URL in der URL-Bar vom Browser die gleiche wie computerbase.de?
• wenn ja -> ab die Post
• wenn nein -> sende einen sogenannten preflight Request, der verrät dem Browser ob der CORS-Header von computerbase.de es erlaubt example.com auf die Ressource zuzugreifen

Ersetze die Domains mit egal was, eine Domain wird am Ende auch nur auf Protokoll, IP und Port übersetzt.
Wenn localhost:8080 auf 192.168.178.5 (oder wo dein NAS auch liegt) zugreifen will sieht der Browser ganz stumpf "localhost:8080 != 192.168.178.5".
Bei Subdomains das gleiche Spiel, sobald die Ziel-Domain nicht die aktuelle Domain im Browser ist brauchst du einen CORS-Header wo die Ziel-Domain sagt "Domain XYZ darf von mir Daten haben".


Wie bereits schon gesagt, das ist ein Sicherheitsmechanismus vom Browser.
Stell dir vor jemand schafft es bei Facebook ein fremdes Script einzuschleusen, und dieses Script macht einfach massig Requests zu computerbase.de.
Wenn dann tausende Browser von Facebook-Usern anfangen einen Server zu fluten nennt man das DDoS, in dem Fall mit einem "Botnetz".

Server haben solche CORS-Checks nicht, weil der Code vom Server auch nur auf deinem Server läuft.
Dann gibt es nur einen Client der Unsinn treibt (den man auch extrem gut blocken kann), und nicht 100.000 echte unwissende User.
Wenn du eine Ressource direkt so im Browser aufrufst funktioniert das auch, eben weil man das nicht missbrauchen kann.

Das meiste ist auch im MDN erklärt, oder könnte man durch googlen herausfinden.
Das Forum ist zwar zum helfen da, aber von dir muss auch Eigeninitiativewenn kommen wenn dir Leute schon die passenden Links raussuchen.
Es wird nicht immer Leute geben die dir Links zurechtkauen.
Googeln, die richtigen Links finden und verstehen ist 90% der Jobbeschreibung.

 

[Bennyaa]

Das ganze einmal Schritt für Schritt zum mitschreiben:

• User öffnet example.com in seinem Browser
• irgendwo auf der Seite wird Javascript geladen
• das Javascript sagt "lad mal was von computerbase.de/irgendeine_ressource"
• der Browser macht jetzt folgendes:
• ist die aktuelle URL in der URL-Bar vom Browser die gleiche wie computerbase.de?
• wenn ja -> ab die Post
• wenn nein -> sende einen sogenannten preflight Request, der verrät dem Browser ob der CORS-Header von computerbase.de es erlaubt example.com auf die Ressource zuzugreifen

Ersetze die Domains mit egal was, eine Domain wird am Ende auch nur auf Protokoll, IP und Port übersetzt.
Wenn localhost:8080 auf 192.168.178.5 (oder wo dein NAS auch liegt) zugreifen will sieht der Browser ganz stumpf "localhost:8080 != 192.168.178.5".
Bei Subdomains das gleiche Spiel, sobald die Ziel-Domain nicht die aktuelle Domain im Browser ist brauchst du einen CORS-Header wo die Ziel-Domain sagt "Domain XYZ darf von mir Daten haben".


Wie bereits schon gesagt, das ist ein Sicherheitsmechanismus vom Browser.
Stell dir vor jemand schafft es bei Facebook ein fremdes Script einzuschleusen, und dieses Script macht einfach massig Requests zu computerbase.de.
Wenn dann tausende Browser von Facebook-Usern anfangen einen Server zu fluten nennt man das DDoS, in dem Fall mit einem "Botnetz".

Server haben solche CORS-Checks nicht, weil der Code vom Server auch nur auf deinem Server läuft.
Dann gibt es nur einen Client der Unsinn treibt (den man auch extrem gut blocken kann), und nicht 100.000 echte unwissende User.
Wenn du eine Ressource direkt so im Browser aufrufst funktioniert das auch, eben weil man das nicht missbrauchen kann.

Das meiste ist auch im MDN erklärt, oder könnte man durch googlen herausfinden.
Das Forum ist zwar zum helfen da, aber von dir muss auch Eigeninitiativewenn kommen wenn dir Leute schon die passenden Links raussuchen.
Es wird nicht immer Leute geben die dir Links zurechtkauen.
Googeln, die richtigen Links finden und verstehen ist 90% der Jobbeschreibung.

OK, danke für die Erklärung.
Jetzt habe ich verstanden, dass wenn man eine Ressource direkt in die Adresszeie einträgt, wird es nicht blockiert, da dies sonicht beachtet wird, sondern nur aus dem JavaSkript code heraus.

Des Weiteren dachte ich bis dato, dass nicht der Browser, sondern der Server den fetch blockiert.
Wenn das schon der Browser macht, dann ist das auch klar.

Wenn ein Server diesen Sicherheitsmechanismus nicht macht.... wäre es dann nicht für Hacker möglich diesen Umweg zu nutzen?
Also indem Sie vom dem client die gewollte Anfrage zum eigenen Server senden und der sendet es dann als anfrage zum gewollten Server (Bspw. Homebanking)