• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

Frage zu Same Origin Policy

B

bis

New member
Vielleicht hat jemand eine Erfahrung bzw. Kenntnis zu folgendem Problem, zu dem ich nach längerem Studium im Internet keine klare Antwort gefunden habe:

Situation aus drei Komponenten:
1) eine Desktop Applikation mit integriertem Localhost
2) der Web-Browser
3) ein Web-Server mit HTML-Seiten (vorerst nur File Server)

Ziel ist es, zwischen Desktop Applikation und Web-Browser eine engere bidirektionale Kommunikation herzustellen, wobei einige Klicks des Anwenders im Browser zu Aktionen in der Desktop-Applikation führen (z. B. Hilfe im Browser mit Rückkoppelung in der App).

Die jeweils aktuellen HTML-Seiten sollen jedoch vom Web-Server geladen werden.

Der Ablauf wäre also folgender:
a) der Web-Browser wird von der Desktop-Applikation mit einer Start-Url gestartet
b) der Web-Browser lädt diese HTML-Seite jedoch vom Web-Server
c) bestimmte Klicks werden durch Javascript an den Localhost geleitet
d) der Localhost sendet bestimmte Updates an den Web-Browser (z.B. zu ladende Html-Seiten)
e) das Laden von HTML-Seiten erfolgt jedoch immer vom Web-Server

Weiß jemand, ob dies eine Verletzung der Same Origin Policy darstellt bzw. ob dies so machbar ist?

Herzlichen Dank für eine Antwort und einen kurzen Kommentar im voraus
 
Ohne eine serverseitige Skriptsprache kannst du da nichts machen. In PHP wäre dein Localhost für den Webserver in $_SERVER['REMOTE_ADDR'] hinterlegt. Wenn du also möchtest, dass durch einen Klick auf der HTML-Seite Informationen an deinen Localhost geschickt werden, musst du entweder die PHP-Datei direkt verlinken oder mit AJAX einbinden. Ich weiß ja nicht, auf welchen Ports deine Desktop-Applikation liest, aber wenn du einen Apache installiert hast, kannst du bequem übers HTTP connecten.
 
Hm, vielen Dank für die extrem schenlle Antwort, aber das schafft bei mir mehr neue Fragen.

Evtl. zum besseren Verständnis: Das soll am Anfang ein interaktives Hilfe-System im Browser sein, das Settings und "States" aus der Desktop-App erhält und diese im Browser berücksichtigt (durch JS-Logik).

1) Die Desktop App hat einen Web (File) Server integriert. Nix externes nötig, Apache oder so. Ist zwar etwas langsam aber Teil der Desktop App (ist in Smalltalk geschrieben). Das geht über den normalen HTTP-Port. Ich glaube, dieser Localhost Web-Server könnte alle Ports bedienen.

2) Ich kann nicht erkennen, was eine Skriptsprache auf dem Web-Server dabei machen bzw. helfen sollte. M.E. nicht nötig.

Einzige Aufgabe des Web-Servers hierbei ist es, aktuellen Content (Html-Seiten, Flash-Filme) zu liefern und das JavaScript für den Browser. Die Interaktionen kommen allein vom Localhost, also aus der Desktop-App. Alle Klicks in den Html-Seiten gehen an JavaScript, das diese entweder an den Web-Server (neuer Content) schickt oder via Localhost and die Desktop-App und damit Aktionen der Desktop-App auslöst (UI und/oder weitere Daten/States für den Browser).

Z.B. könnte der Browser damit Settings/States der Desktop-App auslisten und vom Web-Server die Erklärungen dazu liefern.

Ist mir völlig unklar, was Dein Aussage "Ohne eine serverseitige Skriptsprache kannst du da nichts machen" dabei meint. Ich sehe dafür weder Sinn noch Notwendigkeit. Vom Web-Server kommt nur statischer Content.

3) Netter Nebeneffekt: Damit könnte ich später ein Browser-UI in JS nutzen, um Daten in der Desktop-App und ihrer lokalen Datenbank zu pflegen und spare mir oft das UI in der Desltop-App. wobei der Browser auch per Ajax mit einem Web-Server und dessen DB kommuniziert. Dafür habe ich mehrere Anwendungen.

4) Anmerkung: Meine Desktop-App kann sogar (derzeit erst rudimentär) Javascript erzeugen. Später kann also sogar das JS, wo nötig, interaktiv für den Browser von der Desktop-App erzeugt werden.

Gruß
 
bis schrieb:
c) bestimmte Klicks werden durch Javascript an den Localhost geleitet
Zum Vergrößern anklicken....
das ist der punkt. was bedeutet das? neue seite? xmlhttprequest?

wozu brauchst du überhaupt noch den browser? das kann doch die desktop app erledigen

EDIT: zu spät, aber

bis schrieb:
1) Die Desktop App hat einen Web (File) Server integriert. Nix externes nötig, Apache oder so. Ist zwar etwas langsam aber Teil der Desktop App (ist in Smalltalk geschrieben). Das geht über den normalen HTTP-Port. Ich glaube, dieser Localhost Web-Server könnte alle Ports bedienen.
Zum Vergrößern anklicken....
warum gehst du dann nicht immer über diesen?
 
Zuletzt bearbeitet:
bis schrieb:
Vielleicht hat jemand eine Erfahrung bzw. Kenntnis zu folgendem Problem, zu dem ich nach längerem Studium im Internet keine klare Antwort gefunden habe:

Situation aus drei Komponenten:
1) eine Desktop Applikation mit integriertem Localhost
2) der Web-Browser
3) ein Web-Server mit HTML-Seiten (vorerst nur File Server)

Ziel ist es, zwischen Desktop Applikation und Web-Browser eine engere bidirektionale Kommunikation herzustellen, wobei einige Klicks des Anwenders im Browser zu Aktionen in der Desktop-Applikation führen (z. B. Hilfe im Browser mit Rückkoppelung in der App).

Die jeweils aktuellen HTML-Seiten sollen jedoch vom Web-Server geladen werden.

Der Ablauf wäre also folgender:
a) der Web-Browser wird von der Desktop-Applikation mit einer Start-Url gestartet
b) der Web-Browser lädt diese HTML-Seite jedoch vom Web-Server
c) bestimmte Klicks werden durch Javascript an den Localhost geleitet
d) der Localhost sendet bestimmte Updates an den Web-Browser (z.B. zu ladende Html-Seiten)
e) das Laden von HTML-Seiten erfolgt jedoch immer vom Web-Server

Weiß jemand, ob dies eine Verletzung der Same Origin Policy darstellt bzw. ob dies so machbar ist?
Zum Vergrößern anklicken....
Nein und ja. Die SOP tritt nur dann ein, wenn ein JS das von einer Seite A eingebunden wird (dabei kann das Skript auch von Seite B kommen) versucht auf Seite B zu zugreifen.

Ein JS darf immer nur die Dokumente verändern, von denen es eingebunden wird. Die Herkunft des JS ist in dem Fall belanglos.
 
hesst schrieb:
das ist der punkt. was bedeutet das? neue seite? xmlhttprequest?
Zum Vergrößern anklicken....
Nicht neue Seite, denn die kommt vom Web-Server (per Link oder via JS).

Zum Localhost ist das ein Ajax Datentrasfer, der nicht unbedingt Daten/Content zurück erwartet, also z.B. nur eine Aktion in der Desktop-App auslöst oder aber Daten (Settings/States) von dort abfragt.

hesst schrieb:
wozu brauchst du überhaupt noch den browser? das kann doch die desktop app erledigen
Zum Vergrößern anklicken....
Die Desktop-App kann leider kein Html rendern und kein Flash zeigen. Damit erstelle ich EIN einziges UI in JS (Ext JS) sowohl für die Desktop-App als auch für eine echte Internet/Intranet Anwendung. Anmerkung: App mit Localhost kann auch hinter Apache sitzen und damit als echter Web-Application-Server agieren (besserer PHP-Ersatz).

Fener kann man das Browser-Fenster voll in ein Window der Desktop-App integrieren, so daß es dem Benutzer wie ein Fenster der App erscheint, technisch ist es aber eine eigene Browser-Instanz. Das allein schafft ungeahnte Möglichkeiten.

hesst schrieb:
warum gehst du dann nicht immer über diesen?
Zum Vergrößern anklicken....
Siehe oben, weil der aktuelle Content vom Web-Server kommen soll. Sonst müßte dieser auf tausenden von Clients (wo App läuft) installiert und aktualisiert werden. Warum?! Dieser "public content", der auch permanent aktualisiert wird, muß vom zentralen Web-Server kommen.
 
Du kannst doch über den localhost die Daten anzeigen lassen, dieser holt sich aber die Daten vom öffentlichen Web-Server.
 
hesst schrieb:
Nein und ja. Die SOP tritt nur dann ein, wenn ein JS das von einer Seite A eingebunden wird (dabei kann das Skript auch von Seite B kommen) versucht auf Seite B zu zugreifen.

Ein JS darf immer nur die Dokumente verändern, von denen es eingebunden wird. Die Herkunft des JS ist in dem Fall belanglos.
Zum Vergrößern anklicken....

Also konkret:
- Seite A (Web-Server) liefern Html-Content und das JS.
- Dann dürfte dieses JS nicht mit Localhost kommunizieren, weil hier Seite B.
- Würden die Teile des JS, die mit Seite B kommunizieren sollen, auch von Seite B geliefert, sollte das nicht gelten?
- Können dann die "beiden JS-Herkünfte" miteinander kommunizieren?

Interpretiere ich das richtig?
 
bis schrieb:
Fener kann man das Browser-Fenster voll in ein Window der Desktop-App integrieren, so daß es dem Benutzer wie ein Fenster der App erscheint,
Zum Vergrößern anklicken....
also doch in der Desktop-App

bis schrieb:
technisch ist es aber eine eigene Browser-Instanz. Das allein schafft ungeahnte Möglichkeiten.
Zum Vergrößern anklicken....
und sollte auch die sop umgehen können



bis schrieb:
Siehe oben, weil der aktuelle Content vom Web-Server kommen soll. Sonst müßte dieser auf tausenden von Clients (wo App läuft) installiert und aktualisiert werden. Warum?! Dieser "public content", der auch permanent aktualisiert wird, muß vom zentralen Web-Server kommen.
Zum Vergrößern anklicken....
der lokale server kann doch den eigentlichen inhalt vom webserver weiterleiten
 
Du kannst doch über den localhost die Daten anzeigen lassen, dieser holt sich aber die Daten vom öffentlichen Web-Server.
Zum Vergrößern anklicken....
Zur Präzisierung:
- "Die Daten" sind Settings/States in der Desktop-App (später auch Anwender-Daten). Die kennt der Web-File-Server gar nicht.
- Nur Html/Flash Content und die generelle JS-Logik kommen vom Web-File-Server.
- "Daten" im eigentlichen Sinne müssen immer via Localhost aus der Desktop-App kommen. Nur da sind sie.
- Es gibt (vorerst) keinen Web-Applikation-Server.

Theretisch denkbar wäre, daß Localhost alles Html, Flash und JS erst direkt vom öffentlichen Web-Server lädt und dann an den Browser sendet. Das wäre aber "von hinten durch die Brust ins Auge" und würde die Sache erheblich verlangsamen und komplizieren.
 
Zuletzt bearbeitet:
das oben ist kein zitat von mir

du kannst ja von überall einbinden, aber nur mit der domain der seite kommunizieren (in einem browser)
 
@hesst
Ja, pardon, aber der neue Edior hier ist so klein. Da hab ich das falsch kopiert. Pardon! Hab's korrigiert.
 
aber andersherum kennt der lokale die des webservers(bzw. kann die aufrufe weiterleiten)
Zum Vergrößern anklicken....
Klar kennt die App/Localhost die Url des zentralen Web-Servers, sogar die Strukturen des Html dort. Weiterleiten sollte möglich sein, aber kostet viel Zeit (ist wesentlich langsamer als Apache) und ist kompliziert.
 
Zuletzt bearbeitet:
bis schrieb:
Klar kennt die App/Localhost die Url des zentralen Web-Servers, sogar die Strukturen der Daten. Weiterleiten sollte möglich sein, aber kostet viel Zeit (ist wesentlich langsamer als Apache) und kompliziert.
Zum Vergrößern anklicken....
ja ok, du hast mehrere möglichkeiten. eine musst du dir aussuchen.
wobei es wohl nicht wesentlich langsamer sein wird. die kommunikation über localhost sollte nicht die rolle spielen
 
Also daß dieser Umweg geht, war mir klar:
- App/Localhost läd allen Content vom Web-Server (Html, Flash, JS)
- und schickt alles als Localhost an den Web-Browser
- der immer nur mit Localhost kommuniziert

Das geht sicher, aber das will ich unbedingt vermeiden, wenn es irgendwie geht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben