CORS und CCU – lighttpd: Error 510 bei OPTIONS-Anfragen

[jmaus]

Hast du mal ein Beispiel einer solchen Webanwendung parat zur Hand? Vielleicht als Pythonanwendung oder ähnlich damit ich das selbst hier reproduziert bekomme.

eine Webanwendung läuft in Deinem Browser und ist daher meist in JavaScript geschrieben. Und es ist der Browser, der CORS (Cross-Origin Resource Sharing) implementiert, da er merkt, dass der Port der Website, von dem er die Seite mit dem JavaScript heruntergeladen hat, und der Port der Abfrage an den Skript-Server, unterschiedlich sind (Verstoß gegen Same-Origin).

Der Sinn des CORS-Schutzes ist vielleicht eher zu verstehen, wenn man es als Schutz eines fremden Servers begreift. Es reichen aber schon unterschiedliche Ports auf dem gleichen Server.

Also prinzipiell verstehe ich schon warum und wie dieser CORS Mechanismus da ist und funktioniert. Ich bin mir allerdings noch nicht ganz sicher ob man das wirklich in dem gegebenen kontext braucht und ob man überhaupt diese OPTIONS Abfragen supporten sollte. Du kannst doch auch einfach die Skriptanfragen ohne POST schicken und stattdessen nur als Query string URL parameter verpacken und erreichst das gleiche. Was soll überhaupt deine Javascript-Anwendung da bitte erreichen/machen?

[Karamike]

Also prinzipiell verstehe ich schon warum und wie dieser CORS Mechanismus da ist und funktioniert. Ich bin mir allerdings noch nicht ganz sicher ob man das wirklich in dem gegebenen kontext braucht und ob man überhaupt diese OPTIONS Abfragen supporten sollte. Du kannst doch auch einfach die Skriptanfragen ohne POST schicken und stattdessen nur als Query string URL parameter verpacken und erreichst das gleiche. Was soll überhaupt deine Javascript-Anwendung da bitte erreichen/machen?

Auch GET-Anfragen sind mit CORS geschützt - wenn Sie dann aus einer Webanwendung kommen...

Das Beispiel war ein auf das Wesentliche reduzierte Programm, um den Punkt zu verdeutlichen.

Mein Anwendungsfall ist Bedienkomfort und die Webanwendung etwas umfangreicher:

Auf meiner Zentrale läuft ein Programm, dass an bestimmten nicht vorhersehbaren Tagen einen Heizungsthermostaten ansteuert. Die Daten sind in einer Systemvariablen vom Typ String in Form von "JJJJMMTT,JJJJMMTT,JJJJMMTT,..." gespeichert.

Täglich zu einer bestimmten Uhrzeit prüft ein Homematic-Skript diese Systemvariable, schaut nach, ob das heutige Datum vorkommt und führt ggf. eine Aktion aus, löscht ältere Daten aus dem String und speichert ihn wieder.

Die Eingabe der Daten in die Systemvariable in der Raspberrymatic-WebUI ist für Nicht-Nerds eher ungeeignet und fehleranfällig.

Meine Webanwendung holt sich die Systemvariable, stellt die dort enthalten Daten in Form von Kalenderblättern dar, deren Status durch Anklicken der Tage ein- oder ausgeschaltet wird, und speichert die Daten auf Tastendruck (entsprechend formatiert) wieder in der Zentrale.

Da ein solches Programm kaum auf der Zentrale laufen kann, läuft es halt im abfragenden Webbrowser - in Form eines JavaScripts.

Das Einzige, was dieses Programm braucht, ist eine Möglichkeit den Inhalt der Systemvariablen abzufragen und zu setzen, was die Skript-API im Prinzip ja auch macht... nur dass der Webbrowser in diesem Fall auf Same-Origin besteht oder vom abzufragenden Server die gewünschte Antwort auf die Preflight-OPTIONS-Abfrage verlangt.

Ich bin der CORS-Problematik dadurch aus dem Weg gegangen, dass ich lighttpd.conf erweitert habe und die Abfrage "POST /regex.exe" auch auf Port 443 zulasse. Damit ist sie Same-Origin. Die Abfrage wird dann einfach - wie bei Port 48181 - an localhost:8183 weitergeleitet.

Vielleicht ist ein persistenter Include am Ende von lighttpd.conf nach /usr/local einfacher zu implementieren als die Antworten auf CORS-Anfragen...

[jmaus]

[...]
Meine Webanwendung holt sich die Systemvariable, stellt die dort enthalten Daten in Form von Kalenderblättern dar, deren Status durch Anklicken der Tage ein- oder ausgeschaltet wird, und speichert die Daten auf Tastendruck (entsprechend formatiert) wieder in der Zentrale.

Da ein solches Programm kaum auf der Zentrale laufen kann, läuft es halt im abfragenden Webbrowser - in Form eines JavaScripts.

Das Einzige, was dieses Programm braucht, ist eine Möglichkeit den Inhalt der Systemvariablen abzufragen und zu setzen, was die Skript-API im Prinzip ja auch macht... nur dass der Webbrowser in diesem Fall auf Same-Origin besteht oder vom abzufragenden Server die gewünschte Antwort auf die Preflight-OPTIONS-Abfrage verlangt.

Verstehe. Problem ist nur, das ich das ganze aktuell nur wenig überschauen kann, denn du bist quasi der erste und bis jetzt auch einzigste der mit dieser CORS-Problematik um die Ecke kommt. Bisher werden solche Skriptabfragen eben nicht via Browser-basierten Javascript-Anweisungen erledigt, sondern diese werden in den meisten Fällen entweder via tclsh skripte innerhalb eines Addons direkt auf der Zentrale ausgeführt oder eben via curl/wget aufrufe und dann entsprechend weiterverarbeitet. Und wie du weisst führen eben mehrere Wege nach Rom und die frage wäre schon warum du die ganze Logik und die Skriptabfrage im Kontext des Webbrowsers via XMLHTTPRequests stattfinden lassen musst und nicht irgendwelche cgi/tclsh skripte dir baust oder die JSONRPC-API nutzt um die notwendigen Daten für deine Webanwendung vorzubereiten? Und da bin ich mir eben nicht ganz sich ob man da nicht Tür und Tor für etwas öffnen würde, wenn der Webserver der Skriptengine jetzt auf diese OPTIONS Anfragen entsprechend antworten würde/müsste, das man vielleicht so aber gar nicht will oder braucht. Auch wüsste ich aktuell ehrlich gesagt nicht wie genau ich das ganze am optimalsten in dem Webserver umsetzen sollte damit das nicht nur funktioniert, sondern auch die OPTIONS antworten entsprechend sicher und korrekt sind. Wie gesagt ist das ganze bzgl. CORS recht großes Neuland für mich und ich bräuchte da erst einmal einen konkreten Anwendungsfall an dem ich mir das anschauen und vielleicht exemplarisch umsetzen könnte.

Ich bin der CORS-Problematik dadurch aus dem Weg gegangen, dass ich lighttpd.conf erweitert habe und die Abfrage "POST /regex.exe" auch auf Port 443 zulasse. Damit ist sie Same-Origin. Die Abfrage wird dann einfach - wie bei Port 48181 - an localhost:8183 weitergeleitet.

Vielleicht ist ein persistenter Include am Ende von lighttpd.conf nach /usr/local einfacher zu implementieren als die Antworten auf CORS-Anfragen...

Vielleicht könntest du ja mal zusätzlich hier genauer darlegen/zeigen was du genau an der lighttpd konfig angepasst/erweitert hast um dein Problem zu lösen/umgehen. Vielleicht findet sich ja auch ein Weg auf Webserverebene um diese OPTIONS Anfragen vor dem nachgelagerten Webserver der Skriptengine entsprechend schon zu bearbeiten/beantworten damit diese von lighttpd direkt beantwortet werden statt an den sehr limitierten Webserver der Skriptengine weitergeleitet zu werden. Oder wir finden irgendeine Art&Weise um schon im Vorfeld irgendwelche Header in der initialen GET Anfragen so anzupassen das die Webbrowser dafür schon gar keine OPTIONS Anfragen senden müssen/wollen?!?

[Karamike]

Vielleicht könntest du ja mal zusätzlich hier genauer darlegen/zeigen was du genau an der lighttpd konfig angepasst/erweitert hast um dein Problem zu lösen/umgehen.

Ich habe nach dem Öffnen der Root-Partition die Datei /etc/lighttpd/lighttpd.conf ganz unten wie folgt erweitert.

Code: Alles auswählen

$HTTP["url"] == "/regex.exe" {
  $HTTP["request-method"] == "POST" {
        auth.backend           = "rega"
        auth.backend.rega.port = 1998
        auth.cache             = (
            "max-age" => "600",
        )
        auth.require           = (
            "" => (
                "method"  => "basic",
                "realm"   => "theRealm",
                "require" => "user=user",
            ),
        )
        url.access-allow = ("")
        proxy.server = (
            "" => (
                "localhost" => (
                    "host" => "127.0.0.1",
                    "port" => 8183,
                ),
            ),
        )
   }
}

Dies erlaubt eine Ausnahme für den Befehl POST /regex.exe (und nur für den).

Die Weiterleitung nach Port 8183 entspricht dem, was zuvor in der Konfigurationsdatei für Port 48181 (dem externen Port des Skript-Servers) definiert ist.

Nach dem Verschließen der Root-Partition und Stop/Start von lighttpd kann ich nun den Skript-Server über den "normalen" https-Port ansprechen. Damit ist die Anfrage Same-Origin und die CORS-Problematik mit den oben beschriebenen Problemen entfällt.

Da lighttpd beim Zugang über 48181 auch nichts anderes macht als nach 8183 weiterzuleiten, ist wahrscheinlich, dass die Prüfung der Authentifizierung (falls in den Einstellungen gesetzt) im Skript-Server selbst stattfindet.

Update 27.01.2023: Das scheint nicht der Fall zu sein. In dieser Form ist keine Authentifizierung notwendig

Update 28.01.2023: Code um auth-Teil ergänzt. Erklärung siehe nächster Post.

Soweit ich erkennen kann, ist der einzige Unterschied zum "normalen" Zustand, dass ich den Zugang zum Skript-Server nicht mehr über die Port-Firewall blocken kann. Dafür kommt aber jetzt die Web-App an die Daten und kann sie nach Belieben darstellen.

Der Grund, weshalb ich überhaupt eine Web-App für die Darstellung verwende, ist, die ganze Prozessorleistung für Weiterverarbeitung und Darstellung nicht dem recht langsamen Raspberry aufzubürden. Die meiste Arbeit macht der abrufende Rechner, der Raspberry braucht nur am Anfang einmal die Daten zu liefern und am Ende die Systemvariablen auf den neuen Wert zu setzen.

[Karamike]

Erklärungen zum obigen Code.

Entgegen meiner früheren Annahme, ist der Skript-Server (den wir über Umwegen mit dem POST ansprechen wollen) nicht für die Authentifizierung verantwortlich, sondern lighttpd.

Ganz zu Beginn der lighttpd-Konfiguration wird das Modul "mod_authn_rega" geladen, das wahrscheinlich für die Authentifizierung verantwortlich ist, zumindest legt das der Name nahe.

Wenn in der WebUI bei "Einstellungen > Systemsteuerung > Sicherheit > Authentifizierung" die Option "Authentifizierung aktiv" gesetzt ist, wird im Dateisystem eine Datei erzeugt, die beim nächsten Start des Webservers (meist nach einem Neustart) bewirkt, dass die oben gezeigten auth-Befehle in die Konfiguration von lighttpd eingefügt werden. Sie haben zur Folge, dass Zugriffe nur authentifiziert erfolgen können.

Zu dem Zeitpunkt, an dem der oben gezeigte Teil der Konfiguration ausgeführt wird, hat der zuvor ausgeführte Teil der Konfiguration den Authentifizierungszwang für die Ports 80 und 443 (normales HTTP/HTTPS) wieder aufgehoben. Der Sinn ist klar: Man kann sich nur dann authentifizieren, wenn der Anmeldedialog auch dann erreichbar ist, wenn man eben noch nicht authentifiziert ist.

Beim "normalen" Skript-Server-Port (48181) wird der Authentifizierungszwang nicht aufgehoben und funktioniert wie erwartet.

Da der Sinn der ganzen Sache war, den Skript-Server wegen CORS auf dem Port 443 ansprechbar zu machen, müssen die auth-Befehle hier wiederholt werden, um eine Authentifizierung zu erzwingen, und dies im Übrigen unabhängig von der oben erwähnten Option.
Wenn man das nicht will, lässt man den auth-Teil weg.

[Spoon3er]

Hallo,
bei mir läuft debmatic auf einem Raspi und zur Kommunikation verwende ich die JSON-RPC. Ich bin schon vor einiger Zeit über die preflight (OPTIONS) Anfrage gestolpert und hab mir damals mit einem hack weiter geholfen.

Ich denke die lighttpd.conf ist bei debmatic anders eingebunden wie beim RaspberryMatic, aber das Schema sollte ähnlich sein. Weiter verwende ich kein https, aber bei der JSON-RPC ist auch preflight notwendig.

Ich habe die /etc/lighttpd/conf-available/20-debmatic.conf verändert um die OPTIONS Abfrage mit dem richtigen header zu beantworten:

Code: Alles auswählen

$SERVER["socket"] == ":" + var.debmatic_webui_http_port {
  server.errorfile-prefix    = "/www/error/error-"
  server.document-root = "/www"

  $HTTP["url"] =~ "^/api/homematic.cgi" {
    $HTTP["request-method"] == "OPTIONS" {
      setenv.add-response-header += (
            "Access-Control-Allow-Origin" => "*",
            "Access-Control-Allow-Methods" => "OPTIONS, GET, HEAD, POST",
            "Access-Control-Max-Age" => "86400",
            "Access-Control-Allow-Headers" => "accept, origin, x-requested-with, content-type, x-transmission-session-id",
            "Access-Control-Expose-Headers" => "X-Transmission-Session-Id"
            )
      proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 80)))
    }
  }
  $HTTP["url"] =~ "^/.*\.(exe|oxml|hssml).*" {
    $HTTP["remoteip"] !~ "^(127\.0\.0\.1|::ffff:127\.0\.0\.1|::1)$" {
      url.access-deny = ( "" )
    }
  }
  $HTTP["url"] !~ "^/(config/)|(upnp/)|(webui/)|(ise/)|(api/)|(tools/)|(pda)|(pages/jpages)|(addons).*" {
    proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 8183)))
  }
  $HTTP["url"] =~ "^/(pages/jpages).*" {
    proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 39292)))
  }
  proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 30080)))
}
$SERVER["socket"] == "[::]:" + var.debmatic_webui_http_port {
  server.errorfile-prefix    = "/www/error/error-"
  server.document-root = "/www"

  $HTTP["url"] =~ "^/api/homematic.cgi" {
    $HTTP["request-method"] == "OPTIONS" {
      setenv.add-response-header += (
            "Access-Control-Allow-Origin" => "*",
            "Access-Control-Allow-Methods" => "OPTIONS, GET, HEAD, POST",
            "Access-Control-Max-Age" => "86400",
            "Access-Control-Allow-Headers" => "accept, origin, x-requested-with, content-type, x-transmission-session-id",
            "Access-Control-Expose-Headers" => "X-Transmission-Session-Id"
            )
      proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 80)))
    }
  }
  $HTTP["url"] =~ "^/.*\.(exe|oxml|hssml).*" {
    $HTTP["remoteip"] !~ "^(127\.0\.0\.1|::ffff:127\.0\.0\.1|::1)$" {
      url.access-deny = ( "" )
    }
  }
  $HTTP["url"] !~ "^/(config/)|(upnp/)|(webui/)|(ise/)|(api/)|(tools/)|(pda)|(pages/jpages)|(addons).*" {
    proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 8183)))
  }
  $HTTP["url"] =~ "^/(pages/jpages).*" {
    proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 39292)))
  }
  proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 30080)))
}

Im Prinzip habe ich bei der Abfrage nach den 'socket' noch eine Abfrage der 'url' und eine für 'request-method' = OPTIONS eingefügt. Trifft das zu hänge ich dem response header die benötigten CORS-Attribute an.

Soweit wäre dann der preflight erledigt, doch seit neuestem ist auch in der eigentlichen POST Anfrage der richtige response header notwendig.
Die ist bei debmatic unter /etc/debmatic/lighttpd/conf.d/headers.conf zu finden.
Meine Version:

Code: Alles auswählen

#cache nothing but images
$HTTP["url"] =~ "^/.*\.(jpg|jpeg|png|svg|ico|gif)" {
        setenv.set-response-header += (
        "Cache-Control" => "private, must-revalidate, no-transform, max-age=120"
          )
} else {
  setenv.set-response-header += (
    "Cache-Control" => "private, no-cache, must-revalidate, no-transform, max-age=0",
    "Access-Control-Allow-Origin" => "*",
  )
}

Auch hier musste die "Access-Control-Allow-Origin" => "*" eingefügt werden.


Damit kann ich dann per javascript im browser meine CCU steuern:

Code: Alles auswählen

async function postData(args = {}, url = 'raspi4:8083/api/homematic.cgi', log = true) {
	if(log) console.log(args);

	const response = await fetch(url, {
    		method: 'POST',
    		cache: 'no-cache',
    		headers: {'Content-Type': 'application/json'},
    		body: JSON.stringify(args)
  	});
	if(response.ok)
  		return await response.json()

}

[jmaus]

Danke für diese Ausführungen. Nun es wäre natürlich ein leichtes nach diesem Template RaspberryMatic bzw. die CCU bzw. die lighttpd.conf generell so zu ertüchtigen das sie immer ein "Access-Control-Allow-Origin: *" mit in den Response-Headern ausliefert. Die Frage ist jedoch: Will man das wirklich generalisieren? Denn eigentlich ist das CORS ja eine Sicherungsmaßnahme und wenn ich jetzt generell "Access-Control-Allow-Origin: *" ausliefern würde schalte ich diese Sicherungsmaßnahme ja ab. D.h. z.B. könnte dann ja eine unsichere Drittanbieterseite im Internet dort eine Javascript-Anfrage auf ihren Webseiten einbauen die im Grunde versucht rauszubekommen ob es eine lokale CCU/RaspberryMatic gibt und eben versucht z.B. auf homematic.cgi zuzugreifen. Und aktuell läuft das ja in die CORS Protection rein und es würde/wird nicht funktionieren weil der Webbrowser das dann abblockt. Wenn nun allerdings generell ein "Access-Control-Allow-Origin: *" ausgeliefert wird, dann dann kann die externe Seite versuchen über den Browser des Nutzer nicht nur rausbekommen das es eine CCU/WebUI im lokalen Netzwerk gibt und dann auch entsprechende Attacken via des Webbrowsers dagegen fahren. Und das ist ja nicht gerade im Sinne des Erfinders, oder? Insofern überschaue ich das aktuell wirklich nicht komplett was das für Auswirkungen hätte. Das einzige was ich mir vorstellen könnte wäre, eine Konfiguratiosnmöglichkeit für "Access-Control-Allow-Origin" irgendwo unter zu bringen wo man dann einstellen kann welche Targets wirklich eine positive Antwort erhalten würden das sie diese Seite aufrufen dürfen. Dann kann der Nutzer das selbst entscheiden. Aber solch eine Konfigurationsmöglichkeit macht nicht nur arbeit, sondern auch da ist es fraglich wie man das gestaltet und ob sich der Aufwand überhaupt lohnt.

[Spoon3er]

Sehr guter Einwand und absolut richtig! Deswegen hab ich ja auch "hack" geschrieben.
Meine CCU ist auch nur lokal eingebunden.

Ich habe das hier nur allgemein gehalten um nicht für Verwirrung zu sorgen. Richtig wäre es, und wie ich es auch bei mir laufen habe:
statt:

Code: Alles auswählen

"Access-Control-Allow-Origin" => "*",

eine genaue Addresse, wie z.B.:

Code: Alles auswählen

"Access-Control-Allow-Origin" => "raspi4.meine.eigene.domain"

Somit kann nur dieser Rechner auf das cgi zugreifen.

Aber wie du schon sagst ist die Frage ob sich der Aufwand wirklich lohnt und vorallem wie man das umsetzten könnte. Von meiner Seite aus hätte ich mir damals viel Zeit erspart, wenn ich da was vernünftiges googeln hätte können.
Beim Umgang mit der json-rpc hat mir dieses Forum sehr viele gute Ansatzpunkte geliefert.

An dieser Stelle sein noch mal ein Dank an Dich, Alex und all die anderen schlauen Köpfe hinter diesem Projekt, gesagt.

grüße
Spooner

[jmaus]

Sehr guter Einwand und absolut richtig! Deswegen hab ich ja auch "hack" geschrieben.
Meine CCU ist auch nur lokal eingebunden.

Das ist ja – wenn ich das Sicherheitsproblem hinter CORS richtig verstehe – genau der Trugschluss. Auch wenn deine CCU nur "lokal" eingebunden ist, d.h. vom Internet nicht erreichbar ist wäre es nun möglich dich mit dem System und Webbrowser mit dem du dich auf der CCU einloggen kannst auf eine externe Webseite zu locken und dort ist dann auf dieser externen Webseite javascript-code eingebunden der genau solche cross-origin aufrufe macht. D.h. auf der externen Webseite eben Javascript code im Kontext deines Webbrowser aufruft um entweder nur zu schauen ob es eine CCU im lokalen Netzwerk gibt oder eben direkt eine Attacke gegen diese zu fahren (z.B. via Remote-ReGa-Skript diese komplett löschen lassen) ohne das du das merkst. Und das das "Access-Control-Allow-Origin" eben NICHT auf "*" gesetzt ist verhindert das normalerweise. Wenn du oder ich das allgemein umsetzen würden und nun "*" dort immer mit ausliefert kann dein eigener Browser dich nicht vor solchen malignen externen Webseiten schützen die nur den Sinn haben dein lokales Netzwerk auszusperren bzw. Daten abzugreifen oder gar Schaden anzurichten.

Genau deshalb werde ich das auch so nicht 1:1 umsetzen und einfach das "Access-Control-Allow-Origin" auf "*" setzen. Ebene weil ansonsten solche Attacken erst – meinem Verständnis nach - möglich werden.

Ich habe das hier nur allgemein gehalten um nicht für Verwirrung zu sorgen. Richtig wäre es, und wie ich es auch bei mir laufen habe:
statt:

Code: Alles auswählen

"Access-Control-Allow-Origin" => "*",

eine genaue Addresse, wie z.B.:

Code: Alles auswählen

"Access-Control-Allow-Origin" => "raspi4.meine.eigene.domain"

Somit kann nur dieser Rechner auf das cgi zugreifen.

Ja, das wäre im Grunde die einzig sichere Möglichkeit. Aber das würde es eben notwendig machen dieses "Access-Control-Allow-Origin" Ziel irgendwo als Nutzer in der WebUI konfigurieren zu können. Da aber CORS schon recht starkes Spezialwissen benötigt halte ich das nicht für sinnvoll dem Otto-Normal-Verbraucher solch eine Option zu präsentieren. Was ich mir allerdings vorstellen könnte wäre, irgendeine Variable im Dateisystem der Zentrale zu haben die man manuell über die Kommandozeile setzen könnte und diese wird dann für den "Access-Control-Allow-Origin" header beim starten des webbrowsers verwendet sodass dieser dann diesen entsprechend ausliefern kann. Aber selbst da ist die Frage ob das wirklich etwas ist das mehr als 1-2 Nutzer wirklich benötigen. Ich denke nämlich weiterhin das es mitunter keine gute Idee ist solche API Abfrage direkt im Kontext des Webbrowser durchführen zu lassen und es besser/effektiver ist so etwas direkt auf der Zentrale selbst ausführen zu lassen oder aber auf einem anderen vollwertigen System/Anwendung wie z.B. ioBroker.

[Spoon3er]

... zu lassen und es besser/effektiver ist so etwas direkt auf der Zentrale selbst ausführen zu lassen oder aber auf einem anderen vollwertigen System/Anwendung wie z.B. ioBroker.

Ich bin da voll bei Dir, und das war jetzt auch keine Feature-Anfrage.

Das ganze ist ja irgendwie auch Hobby und ich fuchs mich da gern durch. Ich mags halt gerne selber realisieren. z.B. schrieb ich das CMS zu einer HP selber, obwohl es da bestimmt locker 10 bessere/fertige Lösungen gab.

Der Ansatz mit der Variable ist auch sehr schick und impliziert ein gewisses Maß an Sachverständnis.
Nichts desto trotz langt doch eigentlich schon dieser Forumsbeitrag um versiert und mit diesem Problem behaftete, User weiter zu helfen. Eventuell noch was mit CORS in die Überschrift und schon führt eine vage Googlesuche direkt zu diesem Beitrag.