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

[Silverstar]

[...]

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.

Und sobald der Otto-Normal-Verbraucher dies über die Webui oder so einfach setzen kann, wird er das für seinen PC dort eintragen, da er entweder, bevor er etwas auf einen pi o.ä. deployed, das am PC testen möchte oder gar immer von diesem PC ausführen möchte. Und sobald das Gerät auch für "normales Internet" genutzt wird, ist das wieder potentiell möglich.

Also besser andere Schnittstellen nutzen.

[Karamike]

Die CORS-OPTIONS-Antwort in der lighttpd-Konfigurationsdatei einzustellen ist interessant.

Allerdings ist es mir zu umständlich, da ich sie für 3 Adressen benötigen würde (der IP des Raspi im lokalen Netz, den Namen des Raspi im lokalen Netz und der IP des Raspi im Wireguard-Netz). Außerdem ist die Änderung von den IPs im Netzwerk abhängig.

In soweit finde ich meinen Vorschlag, nur die eine POST-Abfrage in den normalen HTTPS-Raum einzublenden und mit Passwort zu sichern, etwas einfacher.

CORS ist weiterhin aktiv und kommt nur für die Webanwendungen nicht zur Anwendung, die von der Zentrale geladen werden. Eine Webanwendung von woanders, z.B. aus dem Internet, würde wieder an CORS (und seiner nicht vorhandenen Implementierung) scheitern.

Der Einsatzfall hier ist die Beeinflussung eines von mir geschriebenen HMS-Skripts in der Zentrale, also nichts, was für den "normalen" Anwender interessant wäre.

Ansonsten kann ich mich den Vorrednern nur anschließen. Jemand, der Änderungen an Konfigurationsdateien vornimmt, weiß was er tut... oder sollte es...

Meine einzige Bitte ist eine Möglichkeit, eine solche Erweiterung der lighttpd-Konfiguration "Firmware Update"-resistent zu machen (ähnlich wie beim SSH-Server, /usr/local/etc/rc.local usw.), z.B. mit einem Include am Ende der Konfigurationsdatei, wenn eine entsprechende Datei unter /usr/local vorhanden ist.

Dann können die Kinder mit ihren Konfigurationserweiterungen weiter spielen, Jens braucht keine OPTIONS zu implementieren, der normale Benutzer bekommt ehe nichts mit und alle sind zufrieden