<p>gluon-status-page-api: Verbesserung der Cross-Origin-Policy</p>
Access-Control-Allow-Origin: * ist vielleicht eine schlechte Idee für die Statusseiten-Api, da andere Websites die Geo-Location des WLAN-Clients von der Statusseite ableiten könnten, indem sie über Ajax auf die API zugreifen.
Als Referenz: ähnliches Problem im WLAN von DB
lemoer
Alle 3 Kommentare
Sehr richtig. Ich sehe zwei mögliche Lösungen, ohne die Statusseite vollständig zu zerstören:
- Wir senden den Header überhaupt nicht, wenn die API über eine "generische" (next_node) Adresse aufgerufen wird. Dies macht es unmöglich, Informationen zu sammeln, ohne die Adresse des Knotens zu kennen, mit dem ein Benutzer im Voraus verbunden ist. Allerdings muss serverseitig viel mehr Logik implementiert werden (wir ignorieren derzeit einfach den Host-Header AFAIK).
- Wir senden nur
Access-Control-Allow-Origin: $site.next_node.name$. Dadurch werden nur Nachbardaten angezeigt, wenn die Statusseite ursprünglich über die next_node-Adresse aufgerufen wurde (auch wenn Sie dann von Ihrem nächsten Knoten weg navigieren).
jplitza
am 30. Juli 2017
Ich mag (2). Es scheint eine kleine Änderung zu sein und wird das Problem beheben. <<<- Ich habe meine Meinung geändert. Ich verlinke noch mehr.
christf
am 4. Aug. 2017
Dies wird zwar eine gewisse Übergangszeit benötigen, aber wir sollten einfach die Statusseite so ändern, dass sie tatsächlich auf die Statusseiten anderer Knoten verweist, anstatt nur die Backend-URL zu ändern, wenn ein anderer Knoten ausgewählt wird, um das ganze Problem zu vermeiden.
Wir könnten immer noch einen einzelnen Access-Control-Allow-Origin: * Endpunkt bereitstellen, der nur eine leere Seite zurückgibt, die verwendet werden kann, um die Erreichbarkeit zu überprüfen (und basierend darauf die Adresse eines Nachbarknotens auszuwählen, wie es derzeit bereits für die Backend-URL gemacht wird).
NeoRaider
am 7. Aug. 2017
Verwandte Themen
kpanic23
·
5Kommentare
jenell95
·
3Kommentare
lephisto
·
5Kommentare
mweinelt
·
3Kommentare
sargon
·
4Kommentare
Hilfreichster Kommentar
Dies wird zwar eine gewisse Übergangszeit benötigen, aber wir sollten einfach die Statusseite so ändern, dass sie tatsächlich auf die Statusseiten anderer Knoten verweist, anstatt nur die Backend-URL zu ändern, wenn ein anderer Knoten ausgewählt wird, um das ganze Problem zu vermeiden.
Wir könnten immer noch einen einzelnen
Access-Control-Allow-Origin: *Endpunkt bereitstellen, der nur eine leere Seite zurückgibt, die verwendet werden kann, um die Erreichbarkeit zu überprüfen (und basierend darauf die Adresse eines Nachbarknotens auszuwählen, wie es derzeit bereits für die Backend-URL gemacht wird).