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.jmaus hat geschrieben: ↑02.02.2023, 08:49[...]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 hat geschrieben: ↑02.02.2023, 05:15Ich 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:eine genaue Addresse, wie z.B.:Code: Alles auswählen
"Access-Control-Allow-Origin" => "*",
Somit kann nur dieser Rechner auf das cgi zugreifen.Code: Alles auswählen
"Access-Control-Allow-Origin" => "raspi4.meine.eigene.domain"
Also besser andere Schnittstellen nutzen.