Felix Riesterer: CORS bei file:// *fluch*

0 58

CORS bei file:// *fluch*

Felix Riesterer
  • javascript
  • sicherheit
  1. 0
    Emil
  2. 0
    Felix Riesterer
  3. 0
    Rolf B
    1. 0
      Christian Kruse
      1. 2
        Christian Kruse
  4. 0
    JürgenB
    1. 0
      Rolf B
      1. 0
        dedlfix
        1. 0
          Felix Riesterer
          1. 1
            dedlfix
          2. 0
            Rolf B
            1. 0
              Felix Riesterer
              1. 0
                Rolf B
                1. 0
                  Felix Riesterer
                2. 0
                  TS
                  • javascript
                  • sicherheit
                  • software
      2. 0
        JürgenB
    2. 0
      Felix Riesterer
      1. 0
        JürgenB
        1. 0
          Felix Riesterer
          1. 0
            Christian Kruse
            1. 0
              Felix Riesterer
              • javascript
              • menschelei
              • sicherheit
              1. 0
                Christian Kruse
                1. 0
                  Felix Riesterer
          2. 0
            JürgenB
            1. 0
              Felix Riesterer
              1. 0
                Rolf B
              2. 0
                JürgenB
  5. -1
    Emil
    1. 0
      dedlfix
  6. 1
    dedlfix
    1. 0
      JürgenB
    2. 0
      Emil
      1. 0
        dedlfix
        1. 0
          Emil
          1. 0
            dedlfix
            1. -1
              Emil
              1. 0
                dedlfix
                1. -2
                  Emil
                  1. 0
                    dedlfix
                    1. 0
                      Emil
                      1. 0
                        dedlfix
                  2. 0
                    Der Martin
            2. 0
              Emil
              1. 0
                dedlfix
    3. 0
      Rolf B
      1. 0
        dedlfix
      2. 0
        dedlfix
      3. 0
        Rolf B
        1. 0
          dedlfix
          1. 0
            Rolf B
            1. 0
              dedlfix
              1. 0
                Rolf B
                1. 0
                  dedlfix
                  1. 0
                    Rolf B
    4. 0
      JürgenB
      1. 0
        dedlfix
        1. 0
          JürgenB

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

  1. Die CORS entsprechenden Header setzt der Server, nicht der Client. MFG

  2. Holzhammer:

    1. about:config öffnen
    2. security.fileuri.strict_origin_policy auf false setzen

    Mannomann...

    Liebe Grüße

    Felix Riesterer

  3. 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:

    • lokaler Webserver (CORS mit localhost geht)
    • cURL auf die Kiste bringen und ein Script, das den Upload steuert

    Rolf

    --
    sumpsi - posui - clusi
    1. 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

      1. 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

  4. 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

    1. 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

      --
      sumpsi - posui - clusi
      1. 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.

        1. 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

          1. 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.

          2. 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

            --
            sumpsi - posui - clusi
            1. 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

              1. 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

                --
                sumpsi - posui - clusi
                1. 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

                2. 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

                  --
                  Es gibt nichts Gutes, außer man tut es!
                  Das Leben selbst ist der Sinn.
      2. 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

    2. 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

      1. 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

        1. 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

          1. 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

            1. 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

              1. 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

                1. Lieber Christian,

                  Die ist verschlüsselt.

                  😜

                  mit RSA? (via Fefe)

                  Liebe Grüße

                  Felix Riesterer

          2. 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

            1. 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

              1. Hallo Felix,

                nein, beim FileReader greift kein CORS. Weil es ja kein URL-Zugriff ist.

                Rolf

                --
                sumpsi - posui - clusi
              2. 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 bei http(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

  5. Ich kann über das file://-Protokoll aber keine CORS-Header setzen!

    Welche Header sind es denn die du nicht setzen kannst? MFG

    1. 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.

  6. 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 das file://-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.

    1. 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

    2. 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 das file://-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

      1. 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.

        1. 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

          1. 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.

            1. Ich frage mich eher für was derartiger Pfusch gut sein soll. MFG

              1. 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.

                1. 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

                  1. 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.

                    1. 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

                      1. 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.

                  2. 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

                    --
                    Ein Tag, an dem du nicht wenigstens einmal gelacht hast, ist ein verlorener Tag.
            2. 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!

              1. 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.

    3. 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

      --
      sumpsi - posui - clusi
      1. 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.

      2. 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.

      3. 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

        --
        sumpsi - posui - clusi
        1. 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.

          1. 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

            --
            sumpsi - posui - clusi
            1. 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.

              1. 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

                --
                sumpsi - posui - clusi
                1. 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.

                  1. 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

                    --
                    sumpsi - posui - clusi
    4. 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

      1. 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.

        1. 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