CORS bei file:// *fluch*
Felix Riesterer
- javascript
- sicherheit
0 Emil0 Felix Riesterer0 Rolf B0 JürgenB-1 Emil0 dedlfix
1 dedlfix
Liebe Mitlesende,
ich muss eine Textdatei auf einem Windows-Rechner per POST-Request an einen Server übertragen. Diese Textdatei wird vor der Übertragung mit einem Passwort verschlüsselt. Kann der Server die Textdatei mit diesem Passwort entschlüsseln, nimmt er sie an und verarbeitet sie.
Das tat ich bisher mit XMLHttpRequest und dem file://
-Protokoll. Heute morgen macht der FF nach dem Update auf 68 aber unter Hinweis auf CORS nicht mehr mit. Ich kann über das file://
-Protokoll aber keine CORS-Header setzen! Wie soll ich denn nun für den Endanwender bequem (bisher Doppelklick auf ein Desktop-Icon -> HTML-Dokument im Browser - fertig) den Dateiupload realisieren? Auch fetch-API und Konsorten machen beim file://
-Protokoll mit CORS jetzt Ernst.
Liebe Grüße
Felix Riesterer
Die CORS entsprechenden Header setzt der Server, nicht der Client. MFG
Holzhammer:
false
setzenMannomann...
Liebe Grüße
Felix Riesterer
Hallo Felix,
das ist leider so. Deine eigene Kiste wird als am wenigsten vertrauenswürdig gesehen. Verstanden habe ich das auch nicht, aber offenbar gab es hinreichend viele Exploits, so dass man das ändern musste.
Man kann es angeblich abschalten, über about:config und security.fileuri.strict_origin_policy - das wird Dir aber wahrscheinlich nicht helfen und ich weiß auch nicht ob es im 68er Fuchs greift.
Edit: Ups. Zu lange rumeditiert :)
Alternativen:
Rolf
Hallo Rolf,
das ist leider so. Deine eigene Kiste wird als am wenigsten vertrauenswürdig gesehen. Verstanden habe ich das auch nicht, aber offenbar gab es hinreichend viele Exploits, so dass man das ändern musste.
Ja, die letzte große Sicherheitslücke hat diesbezüglich auch die Runde durch die Presse gemacht: https://www.heise.de/mac-and-i/meldung/Ungewollte-Kameraaktivierung-Apple-stopft-schwere-Luecke-in-Zoom-mit-Silent-Update-4467716.html
LG,
CK
Hallo Ingrid,
Ja, die letzte große Sicherheitslücke hat diesbezüglich auch die Runde durch die Presse gemacht: https://www.heise.de/mac-and-i/meldung/Ungewollte-Kameraaktivierung-Apple-stopft-schwere-Luecke-in-Zoom-mit-Silent-Update-4467716.html
Diesbezüglich auch interessant: Why Do Web Browsers Allow Access to the Local Network? – das wusste ich nämlich in der Tat auch noch nicht. Und ich halte das auch für bedenklich…
LG,
CK
Hallo Felix,
der FF war der letzte Browser, der Ajax mit file:// noch zugelassen hat. Das ist jetzt Geschichte. Auch wenn das html von der Festplatte kommt, also gar kein CORS vorliegt, wird Ajax geblockt.
Du wirst wohl auf den FileReader zurückgreifen müssen.
Gruß
Jürgen
Hallo JürgenB,
setzt der nicht voraus, dass der User die Datei auswählt?
Was nicht in Felix' Sinn war, wenn ich das richtig verstehe.
file:// Webseiten als lokale Tools für irgendwas ergeben mittlerweile kaum noch Sinn. Ob sie das je getan haben, bleibe dahingestellt 😉
Rolf
Tach!
setzt der nicht voraus, dass der User die Datei auswählt?
Was nicht in Felix' Sinn war, wenn ich das richtig verstehe.
Ja, ohne Nutzeraktion auf Dateien zugreifen ist eben kritisch. Wenn man das möchte, sollte man nicht mit dem Browser arbeiten, der Code sonstwoher holen und ausführen kann, und gegen Missbrauch schützen möchte. Gewünscht ist hier eigentlich eine Desktop-Anwendung, der man pauschal getraut hat, dass sie keinen Unsinn anstellt, und entsprechende Rechte im System gewährt hat.
dedlfix.
Lieber dedlfix,
Ja, ohne Nutzeraktion auf Dateien zugreifen ist eben kritisch.
völlig richtig. In meinem Fall handelt es sich um ein drei Jahre altes Provisorium, an das ich in diesem Sommer herangehen werde, um es abschaffen zu können.
Gewünscht ist hier eigentlich eine Desktop-Anwendung, der man pauschal getraut hat, dass sie keinen Unsinn anstellt, und entsprechende Rechte im System gewährt hat.
Ich für Windoof eine Anwendung programmieren? Das ist mir den Aufwand nicht wert. Da das Provisorium ohnehin seinem Lebensende entgegen geht, wird das mit mir und Windows-Desktop nix mehr.
Liebe Grüße
Felix Riesterer
Tach!
Gewünscht ist hier eigentlich eine Desktop-Anwendung, der man pauschal getraut hat, dass sie keinen Unsinn anstellt, und entsprechende Rechte im System gewährt hat.
Ich für Windoof eine Anwendung programmieren? Das ist mir den Aufwand nicht wert. Da das Provisorium ohnehin seinem Lebensende entgegen geht, wird das mit mir und Windows-Desktop nix mehr.
Muss ja nicht Windows-Programmierung sein. Es gibt zum Beispiel auch Electron: Desktop-Programmierung (nicht nur für Windows) mit Webtechniken, sprich: HTML, CSS und Javascript.
dedlfix.
Hallo Felix,
Ich für Windoof eine Anwendung programmieren?
Nee, sollst Du doch gar nicht. Alles schon fertig. cURL gibt's für Windows, und einen Batch-Einzeiler kriegst Du bestimmt hin bzw. den baut Dir hier zur Not einer (isch nisch, hab kein cURL...).
Rolf
Lieber Rolf,
(isch nisch, hab kein cURL...).
aha... Du sprichst hier also nicht aus Erfahrung? Nur Mutmaßung?
Auch ein Batch-Script ist für mich eine Windows-Desktop-Anwendung. Den POST-Request muss ich für cURL ja auch erst noch basteln, damit es meine Daten schön verschlüsselt POSTen kann. Und wie ist das mit dem Verschlüsseln auf Batch-Ebene...?
Liebe Grüße
Felix Riesterer
Hallo Felix,
aha...
Ja, entschuldige bitte, dass ich einen Vorschlag gemacht habe. Wieso muss ich mit den Tools Erfahrung haben, um ein mögliches Commandline-Tool vorschlagen zu können? Ob die Idee für Dich taugt, musst Du ohnehin selbst feststellen. Ich weiß jedenfalls, dass cURL ziemlich verbreitet ist und POST Requests kann.
damit es meine Daten schön verschlüsselt POSTen
Ach ja, verschlüsseln musst du auch noch. Sorry, vergessen.
Ich versuche es mal auf diese Tour: Warum verschlüsseln, wenn's der Server gleich wieder entschlüsselt? Soll getestet werden, ob die Verschlüsselung funktioniert? Oder geht's um sichere Übertragung? Im zweiten Fall würde ich https: rufen wollen. Tante Google meint, cURL könnte das (sofern die Zertifikate auf dem Compi sauber sind).
Andernfalls, wenn Du deinen mutmaßlichen JS-Verschlüsseler weiter verwenden willst, käme mir noch node.js in den Sinn, da kannst Du das Ergebnis auch unter non-Windows gebrauchen...
Rolf
Lieber Rolf,
Warum verschlüsseln, wenn's der Server gleich wieder entschlüsselt?
weil das eine Login-Prozedur vor dem Upload ersetzen soll.
Liebe Grüße
Felix Riesterer
Hello,
ich vermute, dass ein wget helfen könnte. Das kann, ganz entgegen des Namens, auch posten, und man kann diverse Parameter einstellen oder sogar aus Dadateien dazuladen.
Und es gibt Versionen für Linux und für Windoof.
Glück Auf
Tom vom Berg
Hallo Rolf,
file:// Webseiten als lokale Tools für irgendwas ergeben mittlerweile kaum noch Sinn. Ob sie das je getan haben, bleibe dahingestellt 😉
dir fehlt die nötige Phantasie 😉.
Ich konnte meine Ajax-Anwendung bisher auch ohne Netz, z.B. im Bus testen, jetzt muss ich mir einen xampp installieren, oder wie Felix beschrieben die Browserkonfig ändern.
Auch einige Anwender meines Scripts haben es überwiegend ohne Server genutzt. Ich warte schon auf die „Support“-Anfragen.
Gruß
Jürgen
Lieber JürgenB,
der FF war der letzte Browser, der Ajax mit file:// noch zugelassen hat. Das ist jetzt Geschichte. Auch wenn das html von der Festplatte kommt, also gar kein CORS vorliegt, wird Ajax geblockt.
immerhin haben sie in den Einstellungen die Möglichkeit geschaffen, beim file://
-Protokoll getrennt von anderen Protokollen CORS abzustellen. Sonst hätte man nur generell CORS oder nicht gehabt. So ist das noch im Rahmen.
Du wirst wohl auf den FileReader zurückgreifen müssen.
Nein, der löst mein Problem ebensowenig. Auch da greift CORS.
Liebe Grüße
Felix Riesterer
Hallo Felix,
Du wirst wohl auf den FileReader zurückgreifen müssen.
Nein, der löst mein Problem ebensowenig. Auch da greift CORS.
wie kommst du darauf? Ich kann meine Web-Anwendung vom Web-Server oder von der lokalen Platte starten, beidemale habe ich über eine Fileselect-Box Zugriff auf die lokalen Daten. Denn genau dafür wurde der Filereader doch gemacht.
Gruß
Jürgen
Lieber JürgenB,
habe ich über eine Fileselect-Box Zugriff
was ist eine Fileselect-Box? Doch nicht etwa ein <input type="file">
, welches eine weitere Nutzeraktion benötigt? Die will ich ja gerade vermeiden! Die Idee war eine Art Autostart beim Laden des Dokuments im Browser. Und da jegliches value
-Attribut bei einem <input type="file">
aus $Gründen fleißig ignoriert wird, stehe ich wieder bei Los.
Liebe Grüße
Felix Riesterer
Hallo Felix,
Und da jegliches
value
-Attribut bei einem<input type="file">
aus $Gründen fleißig ignoriert wird, stehe ich wieder bei Los.
Weil das hier sonst möglich wäre?
<form style="display:none" ...>
<input type="file" name="foo" value="/etc/passwd">
</form>
<script>
document.forms[0].submit();
</script>
LG,
CK
Lieber Christian,
Weil das hier sonst möglich wäre?
<form style="display:none" ...> <input type="file" name="foo" value="/etc/passwd"> </form> <script> document.forms[0].submit(); </script>
zum Beispiel. Aber Dein Bitcoin-Wallet wäre da schon wertvoller. Oder die Datei, in der Du Deine Zugangsdaten zum Online-Banking abgelegt hast...
Liebe Grüße
Felix Riesterer
Hallo Felix,
Aber Dein Bitcoin-Wallet wäre da schon wertvoller.
Isch abe gar keine Bitcoin-Wallet.
Oder die Datei, in der Du Deine Zugangsdaten zum Online-Banking abgelegt hast...
Die ist verschlüsselt.
😜
LG,
CK
Hallo Felix,
Lieber JürgenB,
habe ich über eine Fileselect-Box Zugriff
was ist eine Fileselect-Box? Doch nicht etwa ein
<input type="file">
, welches eine weitere Nutzeraktion benötigt?
doch, so und inzwischen auch nur noch so kommst du an die lokalen Dateien ran. Oder eben über about:config die Tür wieder aufmachen. Aber CORS greift hier nicht.
Gruß
Jürgen
Lieber JürgenB,
Oder eben über about:config die Tür wieder aufmachen.
eben. Sagte ich doch schon.
Aber CORS greift hier nicht.
Wiebitte? Wenn es das nicht täte, hätte ich doch diesen Thread nicht gestartet!? Neu ist, dass es das jetzt auch beim file://
-Protokoll tut, wo es vorher nur bei http(s)://
gegriffen hatte.
Liebe Grüße
Felix Riesterer
Hallo Felix,
nein, beim FileReader greift kein CORS. Weil es ja kein URL-Zugriff ist.
Rolf
Hallo Felix,
Wiebitte? Wenn es das nicht täte, hätte ich doch diesen Thread nicht gestartet!? Neu ist, dass es das jetzt auch beim
file://
-Protokoll tut, wo es vorher nur beihttp(s)://
gegriffen hatte.
CORS hat auf den FileReader keine Wirkung. Der FileReader funktioniert nur bei Zugriff auf das lokale Filesystem, egal von wo das HTML/Javascript kommt.
Aber da die Nutzeraktion über die Fileselectbox keine Option für dich ist, brauchen wir über den FileReader auch nicht weiter zu diskutieren.
Gruß
Jürgen
Ich kann über das file://-Protokoll aber keine CORS-Header setzen!
Welche Header sind es denn die du nicht setzen kannst? MFG
Tach!
Ich kann über das file://-Protokoll aber keine CORS-Header setzen!
Welche Header sind es denn die du nicht setzen kannst?
Ähm, wie setzt man denn "server"seitig Header beim file://-Protokoll?
dedlfix.
Tach!
Das tat ich bisher mit XMLHttpRequest und dem
file://
-Protokoll. Heute morgen macht der FF nach dem Update auf 68 aber unter Hinweis auf CORS nicht mehr mit. Ich kann über dasfile://
-Protokoll aber keine CORS-Header setzen!
Zumindest kann man bei fetch() angeben, dass CORS nicht verwendet werden soll.
fetch('file://D|/test.html', {mode: 'no-cors'})
.then(r => r.text())
.then(console.log);
Das läuft bei mir im 68er Firefox durch, wenn es in einer über File-Open oder Drag-Drop geöffneten Datei steht. Anscheinend gibt es für XMLHttpRequest keine Alternative und nur fiese Hacks mit Proxy, um CORS zu umgehen.
dedlfix.
Hallo dedlfix,
Zumindest kann man bei fetch() angeben, dass CORS nicht verwendet werden soll.
fetch('file://D|/test.html', {mode: 'no-cors'}) .then(r => r.text()) .then(console.log);
danke für den Tipp. Das ist für mich das erste „zwingende“ Argument, endlich auf fetch
umzusteigen.
Gruß
Jürgen
Tach!
Das tat ich bisher mit XMLHttpRequest und dem
file://
-Protokoll. Heute morgen macht der FF nach dem Update auf 68 aber unter Hinweis auf CORS nicht mehr mit. Ich kann über dasfile://
-Protokoll aber keine CORS-Header setzen!Zumindest kann man bei fetch() angeben, dass CORS nicht verwendet werden soll.
fetch('file://D|/test.html', {mode: 'no-cors'}) .then(r => r.text()) .then(console.log);
TypeError: NetworkError when attempting to fetch resource.
MFG
Tach!
TypeError: NetworkError when attempting to fetch resource.
Du hast den Teil "wenn es in einer über File-Open oder Drag-Drop geöffneten Datei steht" nicht beachtet? Von http(s):// auf file:// zuzugreifen wird vom Browser nicht gestattet und mit diese Meldung quittiert.
dedlfix.
Tach!
TypeError: NetworkError when attempting to fetch resource.
Du hast den Teil "wenn es in einer über File-Open oder Drag-Drop geöffneten Datei steht" nicht beachtet? Von http(s):// auf file:// zuzugreifen wird vom Browser nicht gestattet und mit diese Meldung quittiert.
Wenn ich die Datei per Drag+Drop öffne kommt die Meldung auch. MFG
Tach!
TypeError: NetworkError when attempting to fetch resource.
Wenn ich die Datei per Drag+Drop öffne kommt die Meldung auch. MFG
Der gleiche Fehler kommt auch, wenn du auf eine nicht existierende Datei zuzugreifen versuchst. Hast du das als Ursache ausgeschlossen?
dedlfix.
Ich frage mich eher für was derartiger Pfusch gut sein soll. MFG
Tach!
Ich frage mich eher für was derartiger Pfusch gut sein soll.
Meinst du das was Felix vorhat oder meinen Code-Schnipsel?
Da du die eigentliche Frage ignoriert und stattdessen einen Themenwechsel vorgenommen hast, werte ich mal so, dass du keinen Einwand mehr zur Funktionsweise an sich hast.
dedlfix.
Tach!
Ich frage mich eher für was derartiger Pfusch gut sein soll.
Meinst du das was Felix vorhat
Keine Ahnung was der vorhat. Meine diesbezüglichen Fragen hat er ja auch nicht beantwortet. Vermutlich hat er die Frage gar nicht verstanden, obwohl ich da selbst einen zielführenden Hinweis gegeben habe.
MFG
Tach!
Ich frage mich eher für was derartiger Pfusch gut sein soll.
Meinst du das was Felix vorhat
Keine Ahnung was der vorhat.
Gut, dann meinst du also meinen Code-Schnippsel mit dem "Pfusch"? Wenn ja, dann bin ich auf die Begründung (und eine bessere Lösung) gespannt.
dedlfix.
Die bessere Lösung ist, dem Benutzer die Auswahl der lokalen Dateien zu überlassen. Dazu gibt es eine FileAPI. Jeder Versuch, per CODE und am Benutzer vorbei auf lokale Dateien zugreifen zu wollen ist Pfusch! MFG
Tach!
Die bessere Lösung ist, dem Benutzer die Auswahl der lokalen Dateien zu überlassen.
Die bessere Lösung? Wenn die Vorgabe ist, dass die Datei ohne weitere Nutzerhandlung zu verarbeiten ist?
Jeder Versuch, per CODE und am Benutzer vorbei auf lokale Dateien zugreifen zu wollen ist Pfusch!
Und was ist, wenn der Benutzer genau diese Funktionalität haben möchte, wenn er also die Datei, die das tut, eben aus diesem Grunde öffnet?
dedlfix.
Hallo,
Meine diesbezüglichen Fragen hat er ja auch nicht beantwortet. Vermutlich hat er die Frage gar nicht verstanden, obwohl ich da selbst einen zielführenden Hinweis gegeben habe.
aha, dann hast du also noch nicht verstanden, dass er im Kontext file:// unterwegs ist, wo weit und breit kein HTTP-Server im Spiel ist.
Ciao,
Martin
Tach!
TypeError: NetworkError when attempting to fetch resource.
Wenn ich die Datei per Drag+Drop öffne kommt die Meldung auch. MFG
Der gleiche Fehler kommt auch, wenn du auf eine nicht existierende Datei zuzugreifen versuchst. Hast du das als Ursache ausgeschlossen?
Wenn ein NetworkError erscheint, ist die Frage, ob die Datei existiert absolut überflüssig!
Tach!
TypeError: NetworkError when attempting to fetch resource.
Wenn ich die Datei per Drag+Drop öffne kommt die Meldung auch.
Der gleiche Fehler kommt auch, wenn du auf eine nicht existierende Datei zuzugreifen versuchst. Hast du das als Ursache ausgeschlossen?
Wenn ein NetworkError erscheint, ist die Frage, ob die Datei existiert absolut überflüssig!
Wenn du es für absolut überflüssig hältst, das zu prüfen, können wir an dieser Stelle aufhören. Das ändert aber nichts daran, dass genau diese Meldung im oben genannten Szenario kommt.
dedlfix.
Hallo dedlfix,
die Fetch-Spec sagt, dass man bei no-cors eine "opaque filtered response" bekäme.
Das ist so definiert: An opaque filtered response is a filtered response whose type is "opaque", URL list is the empty list, status is 0, status message is the empty byte sequence, header list is empty, body is null, and trailer is empty.
Ich probier's gleich mal selbst aus, aber dieser Text liest sich, als wäre das eher der Stein der Waisen als Weisen.
Rolf
Tach!
die Fetch-Spec sagt, dass man bei no-cors eine "opaque filtered response" bekäme.
Selbige Spec sagt aber auch zum file-Scheme:
For now, unfortunate as it is, file URLs are left as an exercise for the reader.
Ob man sich dann noch an die Gegebenheiten von no-cors halten muss, wenn das ganze File-Handling ausgeklammert ist?
Jedenfalls ist der nächste Satz:
When in doubt, return a network error.
Womit wir dann auch geklärt hätten, warum es bei file://
durchaus zu Netzwerkfehlern kommen kann.
dedlfix.
Tach!
die Fetch-Spec sagt, dass man bei no-cors eine "opaque filtered response" bekäme.
Das ist so definiert: An opaque filtered response is a filtered response whose type is "opaque", URL list is the empty list, status is 0, status message is the empty byte sequence, header list is empty, body is null, and trailer is empty.
Mein Firefox gibt jedenfalls als Antwort
Response {
body: ReadableStream { locked: false }
bodyUsed: false
headers: Headers { }
ok: true
redirected: false
status: 200
statusText: "OK"
type: "basic"
url: "file:///D:/test.html"
}
Nix mit opaque und hastenichgesehen.
dedlfix.
Hallo Ingrid,
führe ich meine Probierseite von localhost aus, bekomme ich den Inhalt meiner Textdatei. Egal ob mode:no-cors oder nicht, egal ob Chrome (75) oder Firefox (69). Läuft unter Windows 10.
Über file:// geht's nicht, mit Unterschieden im Verhalten bei Chrome und FF. Aber vielleicht mache ich ja was falsch?
Chrome:
Führe ich sie via file:// aus, läuft fetch in beiden Fällen ins catch. Im Error-Objekt steht "Failed to fetch", im Stacktrace zusätzlich noch TypeError.
In der Console erscheint noch:
Ohne no-cors:
Fetch API cannot load file:///D:/temp/php/fetch/test.txt. URL scheme must be "http" or "https" for CORS request.
Mit no-cors:
Fetch API cannot load file:///D:/temp/php/fetch/test.txt. URL scheme "file" is not supported.
Firefox:
Führe ich sie via file:// aus, läuft der cors-fetch ins catch. Im Error-Objekt steht "TypeError: NetworkError when attempting to fetch resource.", in der Konsole steht noch Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf file:///D:/temp/php/fetch/test.txt. (Grund: CORS-Anfrage war nicht http).
Der no-cors Fetch gelingt - gewissermaßen. Er liefert eine response mit body=null und type="opaque".
Testseite (Auszug):
<button id="corsfetcher">Fetch with cors</button>
<button id="nocorsfetcher">Fetch with no-cors</button>
<div id="fetched">
<script>
document.getElementById("corsfetcher").addEventListener("click", fetchCors);
document.getElementById("nocorsfetcher").addEventListener("click", fetchNoCors);
let fetched = document.getElementById("fetched");
function fetchCors() {
handleFetch(fetch("test.txt"));
}
function fetchNoCors() {
handleFetch(fetch("test.txt", { mode: "no-cors" }));
}
function handleFetch(promise) {
promise
.then(
response => response.text()
)
.then(
text => fetched.textContent = text
)
.catch(
err => fetched.textContent = err
)
}
</script>
Rolf
Tach!
Über file:// geht's nicht, mit Unterschieden im Verhalten bei Chrome und FF. Aber vielleicht mache ich ja was falsch?
Chrome:
Über den haben wir auch nicht geredet, der lehnt generell ab mit:
Fetch API cannot load file:///D:/test.html. URL scheme "file" is not supported.
Firefox:
Hier muss ich nochmal was korrigieren zu meinem Versuch von heute morgen. Anscheinend habe ich es gar nicht ohne mode:'no-cors'
probiert, denn jetzt nochmal getestet, spielt es bei mir keine Rolle, ob das gesetzt ist oder nicht. Es geht immer.
Führe ich sie via file:// aus,
Was genau meinst du damit? Datei in den Browser ziehen? Oder File-Open? Oder firefox -url file:///...
?
Testseite (Auszug):
Mach es nicht zu kompliziert. Das ist alles Zeug, das man nachvollziehen muss, das Fehler enthalten kann, das nichts zum Problem beiträgt.
dedlfix.
Hallo dedlfix,
wenn es bei Dir funktioniert - welchen Fuchs verwendest Du? 67 oder 68? Hast Du ggf. den security.fileuri.strict_origin_policy Schalter geändert? Wenn ich den auf false setze, geht es bei mir auch. Aber mNn sollte man den nicht umschalten.
Führe ich sie via file:// aus,
Was genau meinst du damit?
Ich meine, dass ich meine Testseite via file-URL im Browser aufrufe. Also das Szenario, an dem Felix rumknabbert.
Mach es nicht zu kompliziert.
Was heißt kompliziert? Ich mache den ersten Schritt dessen, was Felix getan hat: Die Testseite möchte via fetch eine Datei vom PC laden. Die Hypothese war doch, dass das mit no-cors gelingen könnte. Wobei ich sogar noch eine Komplikation weggelassen habe - ich mache es in einem click-Handler. Als Reaktion auf eine Useraktion erlauben Browser oft mehr.
Rolf
Tach!
wenn es bei Dir funktioniert - welchen Fuchs verwendest Du? 67 oder 68? Hast Du ggf. den erwähnten Security-Schalter geändert?
68 und nein.
Führe ich sie via file:// aus,
Was genau meinst du damit?
Ich meine, dass ich meine Testseite via file-URL im Browser aufrufe. Also das Szenario, an dem Felix rumknabbert.
Achso, ja, ist dasselbe wie die anderen Methoden.
Mach es nicht zu kompliziert.
Was heißt kompliziert?
Ich meine, dass ein simples fetch() ausreicht, ohne irgendwelche Buttons und Zeug drumherum.
dedlfix.
Hallo dedlfix,
ja ok. Aber das Script an sich funktioniert; es soll ja auch nur den Fetch antriggern.
Trotzdem lädt er bei mir nicht. Bei Dir schon? Merkwürdig.
Rolf
Tach!
ja ok. Aber das Script an sich funktioniert; es soll ja auch nur den Fetch antriggern.
Trotzdem lädt er bei mir nicht. Bei Dir schon? Merkwürdig.
Die Meldung "TypeError: NetworkError when attempting to fetch resource." sehe ich nur, wenn das Script von http://
aus auf file://
zugreifen soll. Die Zusatzmeldung sehe ich nicht (Filter sind keine aktiv). Bist du sicher, dass du richtig schaust?
dedlfix.
Hallo dedlfix,
ja, bin sicher. HTML wird von file:// URL geladen und der Zugriff auf die Ressource erfolgt - wie du oben siehst - relativ, d.h. aus dem gleichen Ordner und mit dem gleichen Schema.
Rolf
Hallo
ich habe das gerade mal im FF68 unter Windows 10 getestet. Der Fetch läuft durch, .text() liefert aber nur einen String der Länge 0. Mit der Änderung von security.fileuri.strict_origin_policy auf false wird der Dateiinhalt angezeigt.
Gruß
Jürgen
Tach!
ich habe das gerade mal im FF68 unter Windows 10 getestet. Der Fetch läuft durch, .text() liefert aber nur einen String der Länge 0. Mit der Änderung von security.fileuri.strict_origin_policy auf false wird der Dateiinhalt angezeigt.
Eigenartig. Bei mir steht diese Direktive auf Standardwert true. Auch Windows 10 (noch 1803), und mittlerweile auch auf einem zweiten System getestet mit unverändertem Ergebnis. Ich kann nicht ausschließen, mal irgenwelche anderen Einstellungen geändert zu haben. An Sicherheitsdinge kann ich mich aber nicht erinnern (was nichts heißen mag), aber auch für file://
hatte ich bisher keinen Bedarf.
Übrigens, die zweite Zeile wegzulassen und nur ein .then(console.log)
auszuführen, zeigt das Response-Objekt an, inklusive Status, also etwas mehr debug-relevante Information.
Aber auch eigenartig ist, dass du nun schon der nächste bist, der das nicht nachvollziehen kann. Da scheint es noch andere Unterschiede zu geben, die das Verhalten beeinflussen.
dedlfix.
Hallo,
die Eigenschaft ok
hat den Wert false
, daher liefert die Methode text()
dann nur einen leeren String. Aber was bei dir anders ist, als auf meinen beiden W10 (1809 und 1903), weiß ich auch nicht.
Gruß
Jürgen