Cross Domain Web-Worker?

Habe ich https://domain1.com (domain1) und https://domain2.com (domain2).

Domain2 dient eine Seite mit javascript mit einem header "Access-Control-Allow-Origin: *"

Domain1 läuft einige javascript-code, der ruft:

new Worker("//domain2.com/script.js")

Browser werfen-Sicherheit Ausnahmen.

Seit dem schreiben dieser Frage, habe ich dieses problem umgehen, indem ajaxing das Skript, blobbing es und es läuft, doch bin ich etwas fehlt in der ursprünglichen Idee?

  • Es gibt eine doppelte here und die here aber keiner von Ihnen scheinen zu haben eine definitive Antwort.
  • Mit Hilfe des ajax - Daten die URL-Ansatz funktioniert nicht in allen Browsern, laut das MDN-Seite.
  • Und soweit ich das sagen kann, aus der W3C-Spezifikation, die Regeln implizieren, dass der worker-Skripts wirklich zu tun haben werden, stammen aus der gleichen Domäne wie die zugehörige Seite. Ich glaube nicht, dass CORS-Header werden auch überprüft.
  • Zahlen, da die Registerkarte "Netzwerk" gar nicht nahe, dass es sogar das abrufen der Seite zu überprüfen. Also, wenn AJAX es tun können, warum können wir nicht tun, es direkt? :/
  • Ich weiß nicht, die Idee, die hinter der Art, wie es funktioniert. Im Falle von ajax, gut, das ist ein älterer standard. Und wieder bitte beachten Sie, dass Sie die Problemumgehung wird nicht unbedingt funktionieren, da einige Browser betrachten, dass die Daten-URL, die Sie bauen, zählt nicht als "same-origin" für eine web-worker.
  • dies kann man dieses Problem lösen. stackoverflow.com/questions/21913673/...

InformationsquelleAutor user1277170 | 2013-12-05
  1. 10

    Ich habe auch das gleiche problem, hoffe dies kann Ihnen helfen, https://gist.github.com/jtyjty99999/a730a17258fca04bfca3 

     function XHRWorker(url, ready, scope) {
      var oReq = new XMLHttpRequest();
      oReq.addEventListener('load', function() {
          var worker = new Worker(window.URL.createObjectURL(new Blob([this.responseText])));
          if (ready) {
              ready.call(scope, worker);
          }
      }, oReq);
      oReq.open("get", url, true);
      oReq.send();
  }

  function WorkerStart() {
      XHRWorker("http://static.xxx.com/js/worker.js", function(worker) {
          worker.postMessage("hello world");
          worker.onmessage = function(e) {
              console.log(e.data);
          }
      }, this);
  }

  WorkerStart();
    • Nur ein Hinweis, dass diese nicht auf IE11 und unten. Dass Browser werfen SecurityError.
    • Wow, wie diese Lösung. Vor allem die Verkettung new Blob mit URL.createObjectURL. Wusste nicht, dass es möglich ist.
    InformationsquelleAutor John Hou
  2. 5

    Hinweis : Die URI als parameter übergeben, von der Arbeiter-Konstruktor muss gehorchen
    die same-origin-policy. Es gibt derzeit Unstimmigkeiten zwischen
    Browser-Hersteller auf, was URIs sind des gleichen Ursprungs; ...

    Zitat von https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers

    Den HTML5-Arbeiter ist ein ziemlich neues Konzept, und ich bin mir nicht sicher, wie Sie denselben Ursprung Ausnahmen gelten jedoch, mit XmlHttpRequest, ist es möglich, den Zugriff auf Ressourcen in einer anderen Domäne , wenn man die Kontrolle über den server, es läuft auf. Ressourcen auf fremden Domänen erfolgt über Preflight requests Bedeutung, dass zunächst eine OPTIONS-Anfrage gesendet wird, um eine Ressource und wenn die Antwort darauf hat die entsprechenden access-control-Header (Access-Control-Allow-Methods, Access-Control-Allow-Origin als minimum), dann wird die Anfrage wiederholt mit der ursprünglichen Methode und erhält die Ressource in der Antwort.

    • Dies ist die wahre. Aber aus der Beschreibung der web-worker-Skript abrufen Prozess, es ist nicht klar, dass ein user-agent ist auch soll zu prüfen, für die überschriften. Es ist einfach Kräfte die URL abgerufen werden, die von der besitzenden Seite Herkunft, und es setzt die "Kraft gleichen Ursprungs-flag", um sicherzustellen, dass die Weiterleitung nicht beeinflussen.
    • Ich bin mir nicht sicher... Der zitierte doc sagt "darüber hinaus können Sie führen I/O mithilfe von XMLHttpRequest ...". Vor diesem hintergrund gehe ich von der zugrunde liegenden transport ist immer noch standard-HTTP-Anfragen.
    • Oh ja, ich denke, das ist wahr. Aber die spec lässt mich vermuten, dass der user-agent soll die fetch-Skripte nur vom "Besitzer"Herkunft.
    • Die spec auf diese mehrdeutig ist über owner origin. Klar, die MDN-doc sagt, dass "Die URI als parameter übergeben, von der Arbeiter-Konstruktor muss gehorchen den gleichen-origin policy" und über die same-Origin-Policy, es sagt, dass cross-origin-Zugriff unter bestimmten Voraussetzungen erlaubt: developer.mozilla.org/en-US/docs/Web/JavaScript/...
    • Und dies macht Sinn, da das Ziel der Beschränkungen für cross-origin-Zugriff zu verhindern, die Zugriff auf eine Ressource zu, wenn seine Besitzer nicht wollen, dass es auf die zugegriffen werden. Aber, wenn Sie sind der Besitzer der mehrere Ursprünge, Sie können cross-access-Ressourcen unter Ihnen.
    • Kann ich nur Zustimmen, aber die W3C-Formulierung macht es den Anschein strenger, als dass.
    • Von spec ich meinte die W3-spec. 4.6 die Faust-Satz definiert die url, der Besitzer Dokument, Inhaber browsing-Kontext, etc. aber nicht definieren Beziehung zwischen Ihnen, noch es erwähnt, cross-origin.
    • Schauen 4.6 (Processing Model) der Nummer 3. Sie sagt, Sie holt aus der "Eigentümer" Herkunft explizit.

    InformationsquelleAutor marekful
  3. -1

    Haben Sie ermöglichen, Methoden gesetzt?

    Versuchen Sie, diese zu Ihrem header:

    Access-Control-Allow-Methods: POST, GET, OPTIONS
    • Nope, funktioniert nicht.
    InformationsquelleAutor Lenny
Schreibe einen Kommentar