Jersey ws und http gleicher Pfad

[imox]

Hallo,

ich versuche gerade einen proxy für eine JS API zu bauen. Das durchreichen von den http aufrufen funktioniert (siehe hier), allerdings ruft die API auf der gleichen url und gleichen pfad auch ein Websocket auf. Also nicht komplett gleicher Pfad, der ist aber dynamisch und der Anfang ist gleich. Sprich den Websocket muss ich auch noch durchreichen. Eigentlich müsste es doch gehen oder? Websockets kommen ja mit ws: an und normale aufrufe mit http. Aber ich habe keine Ahnung wie ich das konfigurieren soll. Habt ihr eine Idee?

Vielen Dank schon mal.
Gruß Imox

 

[mihe7]

Grundsätzlich kann man Websockets über einen Proxy laufen lassen. Das führt unmittelbar zur Frage: gibt es einen bestimmten Grund, warum Du nicht etwas fertiges nehmen willst? Zum Beispiel nginx, ein bisschen konfigurieren und fertig ist der Proxy.

 

[imox]

Ich habe eine webapp über die halt alles laufen muss. Deswegen bringt mir ein proxy wie nginx etc. leider nichts. Die aufrufe sollen halt alle direkt über meine webapp gehen.

 

[mihe7]

Ich verstehe zwar immer noch nicht den Zusammenhang, aber gut.

Jersey selbst kann m.W. keine Websockets. Du wirst also vermutlich einen Container mit WS-Support nehmen und dort Jersey integrieren müssen (oder Du nimmst halt gleich was vernünftiges fertiges wie einen Jakarta EE Server, Spring Boot oder Quarkus). Dann musst Du Dich halt um Verbindungsauf- und -abbau zu dem "versteckten" WS-Server kümmern und die Nachrichten in beide Richtungen weiterleiten. Das wäre mal mein Ansatz, ob er in der Form funktioniert... muss man sehen.

 

[imox]

Websockets funktionieren ja schon. Problem ist das mappen von dem path. Die normalen http Aufrufe kommen auf path an wie http aufrufe. Die URL wird scheinbar dynamisch von der API generiert. Also die WS Anfragen kommen in meinem HttpServlet. Wenn versuche ein redirect zu machen klappt das leider nicht. Es passiert leider gar nichts. Also das wäre ja evtl. eine Lösung, die ws Anfragen im servlet auf die andere URL weiterzuleiten. Aber wie mache ich das?

 

[Marinek]

Die Frage ist, was möchtest du machen??

Selbst ein Proxy schreiben? Dann musst du die eingehenenden Requests parsen und exakt Reproduzieren. (Hinsichtlich Cookies, Header, url)

Ohne weiteres würde ich sagen: zunächst einmal gehen Header verloren. Diese muss man sich explizit holen und dann weiterreichen.

Dann kommt die Antwort. Die Antwort muss wiederum die richtigen Pfade zurückgeben. Auch solche Pfade, die „dynamisch“ generiert werden.

Klar gibt es Path variables dünnwandig beachten muss.

Frage ist also:

Wie hast du das bisher gemacht. Warum (fachlich) musst du das machen?

Was passiert aktuell, was nicht funktioniert.

Gruß

Martin

 

[mihe7]

Also die WS Anfragen kommen in meinem HttpServlet.

Das heißt erstmal gar nix. WebSockets werden über normale HTTP-Requests initiiert, insofern kommen die Anfragen natürlich am Servlet an. Im Prinzip sendet der Client einen HTTP-Request: "Hey Server, lass uns nicht weiter HTTP verwenden, machen wir Websockets.", der Server antwortet mit "Okay." und ab dann wird halt über die Verbindung nicht mehr HTTP sondern in Websocket-Frames gesprochen.

In Java/Jakarta EE gibt es für Websockets eine API (JSR-356), die unterstützt allerdings nur URI-Templates vom Typ 1, d. h. Parameter sind möglich, nicht aber Wildcards. Wenn Du also wirklich URL-Patterns mit Wildcards brauchst, solltest Du versuchen, etwas fertiges zu finden. Ansonsten wird Dir wahrscheinlich nichts anderes übrig bleiben, als den Spaß (RFC 6455) selbst zu implementieren und das ist nicht ohne, noch dazu im Zusammenhang mit dem Ressourcen-Management eines Containers. Den Schuh würde ich mir nicht anziehen.

Leider kennen wir Deine genauen Anforderungen immer noch nicht, so dass es schwer ist, da irgendeinen Senf dazu abzugeben. Möglicherweise reicht es auch, wenn Dein Client einfach die gewünschte Websocket-URL von Deiner Webanwendung abruft.

 

[imox]

Hey Leute, danke für eure Bemühungen und Antworten. Ihr habt recht, ich sollte euch mal genau beschreiben was ich überhaupt machen will Vielleicht findet sich eine bessere Lösung.

Also ich habe bereits ein REST Projekt mit JPA, Jersey, Guice. Orientiert hatte ich mich damals hier dran.

https://www.vogella.com/tutorials/REST/article.html

Jetzt würde ich gerne onlyoffice mit einbinden. Die JS API funktioniert ja auch ziemlich gut und recht simple. Allerdings läuft die Kommunikation unverschlüsselt ab. Deswegen würde ich gerne den onlyoffice server über den tomcat schleifen. Also dass der onlyoffice server gar nicht im Netz hängt. Also für einen andere bessere Lösung bin ich offen und gerne her damit.

Hier der Links zur onlyoffice API

 

[KonradN]

Wenn es nur darum geht: Nimm einen apache oder ähnliches und lass den das https machen. Das ist ein fertiges Produkt das genau sowas macht.

Das ist übrigens auch eine Taktik, die man oft beim tomcat findet. Das vereinfacht die ganze Konfiguration des Tomcat und ich weis snicht einmal, in wie weit tomcat virtuelle Hosts kann und so ... Und spätestens wenn es um automatische Zertifikatserneuerung geht, ist es mit einem Webserver deutlich einfacher...

 

[imox]

Also vor meinem Tomcat hängt bereits ein Apache. Klappt auch super. Aber bringt mir doch nichts. Onlyoffice ist doch eine JS API. Die wird ja im Browser vom client ausgeführt. Und dann muss die Kommunikation ja vom client zum onlyoffice server gehen.

Hier mal nen kleiner html test. Damit ich dir aufrufe versteht. Im client wird die onlyoffice API von meinem Onlyoffice server geholt. Der holt sich dann das docx von meinem Tomcat. Und wenn man mit dem bearbeiten fertig ist will ein callback an meinen Tomcat zurück geschickt wo eine URL drin steht wo ich die veränderte docx downloaden kann. Und das läuft eben alles unverschlüsselt. Und ich rede jetzt nicht von https, sondern dass es keine Authentifizierung gibt.

<!DOCTYPE html>
<html lang="en" dir="ltr">
    <head>
        <meta charset="utf-8">
        <title></title>
        <script type="text/javascript" src="http://MEIN-ONLYOFFICE-SERVER/web-apps/apps/api/documents/api.js"></script>
    </head>
    <body>
        <div id="onlyoffice"></div>
    </body>

    <script type="text/javascript">

        new DocsAPI.DocEditor("onlyoffice", {
             document: {
                 fileType: "docx",
                 key: Math.random().toString(),
                 title: "test.docx",
                 url: "http://TOMCAT-SERVER.DE:8080/ws/onlyoffice/test.docx",
                 permissions: {
                     download: false,
                 },
             },
             documentType: "word",
             editorConfig: {
                 callbackUrl: "http://TOMCAT-SERVER.DE:8080/ws/onlyoffice/callback",
                 lang: "de",
             },
             height: "500px",
             width: "100%"
         });

    </script>

</html>

 

[KonradN]

Wenn du einen Webserver mit SSL vor dem Tomcat hast: Warum greifst Du dann nicht auch über die entsprechende URL zu? Dann wäre es doch nur eine Anpassung der URLs. Die Adresse darf also nicht http://....:8080/... sein sondern muss https://.../whatever/... sein.

Also einfach nur um einen kleinen Ausschnitt bei mir zu zeigen:

Ich habe etwas auf http://127.0.0.1:3000 laufen. In meinem apache habe ich dann in der entsprechenden site für den vhost für Port 443 neben den SSL Dingen:

    <Proxy balancer://root>
        BalancerMember http://127.0.0.1:3000
    </Proxy>

Der Apache tritt hier also als Proxy auf, wenn der virtuelle host aufgerufen wird.

Das ist die typische Konfiguration. Das Gleiche kannst Du mit Deinem Tomcat machen, so dass Du eben nicht mehr auf den Port 8080 vom Tomcat zugreifst.

Die Anwendung selbst ist dann natürlich so konfiguriert, dass diese weiss: Ich bin unter https://some-virtual-host/ erreichbar. Das ist aber halt in der Regel keine Tomcat Konfiguration (den interessiert nur der Port 8080 und dass es nur auf 127.0.0.1 gebunden wird). Vermutlich hast DU also in deinen Konfigurationen irgendwo angegeben, dass der Callback http://TOMCAT-SERVER.DE:8080/ws/onlyoffice/callback ist. Aber das ist ja anpassbar (nachdem Du die entsprechende Konfiguration im Apache gemacht hast!)

Alternativ kannst Du natürlich auch den Tomcat mit SSL konfigurieren. Du hast ja im Apache ein SSL Zertiifkat - das kannst du auch dem Tomcat geben und dann z.B. den Port 8443 nutzen. Aber das ist natürlich deutlich komplexer und unschöner. Und da wäre die URL natürlich auch anzupassen.

Oder ist das auf Port 8080 nicht der Tomcat? Was genau sprichst Du da an? Egal, was es ist: Das kannst Du hinter den Apache packen und nicht mehr direkt ansprechen. (Und aus Sicherheitsgründen würde ich da auch nur auf localhost binden und nicht auf eine Fireall vertrauen und so.)

 

[imox]

Ich bin doch gar nicht auf dem Port 8080. Und bei mir läuft alles über https und über apache. Das war nur ein Test. Das löst doch trotzdem nicht das Problem. Dass die Anfragen an den onlyoffice server gehen und nicht an meinen Tomcat. Nicht der Tomcat muss mit dem onlyoffice server Kommunizieren, sondern der user.

Und localhost geht nicht, weil der Client, Also Du als user das ja im Browser aufruft. Also geht das doch nicht über localhost Genau das will ich doch. Und Onlyoffice kommt ja auch schon mit nginx. Schau dir mal bitte mein Beispiel noch mal genau an ich glaube dann verstehst du auch mein Problem. Aber trotzdem vielen Dank für meine Mühe.

 

[mihe7]

Also, wenn ich es richtig verstehe, willst Du doch eigentlich so etwas:

 

[imox]

Falsch


User -> Apache -> Tomcat -> onlyoffice

Es geht mir auch nicht um https. Das ist ja gar kein Problem.

 

[KonradN]

Also ich verstehe weiterhin nicht, was Du willst....

Du versuchst die Zugriffe auf OnlyOffice auch durch Tomcat zu schleusen und versuchst da einen Proxy zu entwickeln. Aber das macht doch keinen Sinn.

Die Requests gehen doch bereits vom Client aus. Und die gehen dann zum Apache. Wieso da nicht konfigurieren, dass die Requests für OnlyOffice direkt zu dem OnlyOffce Server gehen? Warum muss der Apache diese erst an den Tomcat geben? Das macht keinen Sinn.

Und wenn es Di rum irgendwelche Callbacks geht - wenn der OnlyOffice Server irgendwelche Callbacks macht, dann ist das kein Thema. Das ist vom Client unabhängig. Und das geht unabhängig davon, wie das genau konfiguriert wurde.

 

[mihe7]

User -> Apache -> Tomcat -> onlyoffice

Wenn Du keinen bestimmten Grund dafür hast, besteht der Unterschied doch nur darin, dass Du Dir über den Tomcat mehr Arbeit aufhalst.

Der Client arbeitet einfach mit einer URL und der Apache (oder nginx, oder was auch immer) leitet die Anfragen halt an den passenden Dienst (Tomcat bzw. OnlyOffice) weiter. Ob das jetzt getrennte Maschinen wie im Bild sind oder alles auf einem Rechner läuft, spielt auch keine Rolle.

 

[imox]

Es geht um die Security. Ich möchte direkt aus der webapp Dokumente bearbeiten können und der User loggt sich ja ein. Und onlyoffice kann sich zum Laden der Dokumente z.b. nicht authentifizieren. Heißt ich müsste meine Dokumente öffentlich für alle machen. Das darf einfach nicht sein. Ich meinte doch oben schon, dass ich gern für eine andere Lösung bereit wäre. Das was ihr mir alle schreib so habe ich das doch schon 😉 und das funktioniert ja auch. Es fehlt halt leider die Security.

Gruß Imox

 

[mihe7]

Und onlyoffice kann sich zum Laden der Dokumente z.b. nicht authentifizieren.

Soweit ich das sehe, unterstützt OnlyOffice doch entsprechende Security-Settings: https://api.onlyoffice.com/editors/signature/

 

[imox]

Ja scheint so, aber irgendwie auch nur so halb. Ich kann zwar den token setzen und der kommt auch beim request bei mir am tomcat an, aber die Datei downloaden geht ohne token. Also die API downloaded test.docx von meinem Server. Da kann ich den token prüfen und alles ist ok. Dann bearbeite ich das docx file und dann wird ein callback an meinen tomcat geschickt. Ist ein JSON wo die download URL von dem bearbeiteten test.docx file drin ist. Super klappt auch nur die URL kann man ohne token öffnen. Klar wenn die Übertragung über https geht, kennt ja niemand die URL und kann man ja eigentlich auch nicht mitlauschen und somit ja eigentlich sicher. Finde ich trotzdem ziemlich fragwürdig und nicht so cool. Deswegen hätte ich eigentlich gern die Kommunikation über meinen Tomcat komplett.

 

[imox]

Hier gibst halt noch ein JAVA example. Ich muss aber gestehen, dass ich mir das schon mal bissel länger angeschaut habe und da einfach nicht so richtig durchblicke. Und das example funktioniert auch nicht oob. Also wie es beschrieben ist einfach nur file storage und url setzen und starten und testen klappt einfach nicht. Selbst das css sieht bei mir ziemlich buggy aus. Werdet ihr daraus vielleicht schlauer?

https://api.onlyoffice.com/editors/demopreview

 

[mihe7]

Super klappt auch nur die URL kann man ohne token öffnen

Moooment. Du musst doch nur den Part absichern, der die Datei ausliefert.

 

[imox]

Was meinst du damit?

 

[mihe7]

Die URL zur Datei muss ja von einem Server bedient werden. Vermutlich ist das entweder Dein Tomcat, Dein Apache oder Dein OnlyOffice. Der betreffende Dienst muss ja nur das Token prüfen, bevor es die Datei sendet.

 

[imox]

Onlyoffice liefert logischerweise die Datei. Und onlyoffice prüft den Token an dieser Stelle nicht.

 

[Oneixee5]

Praktischerweise wird bei uns die Authentifizierung und Autorisierung schon auf dem Proxy der Anwendung vorgenommen. In den Header wird dann ein Feld für die Id des Nutzers und ein Feld für seine Rolle(n) eingefügt. Im Response werden diese vom Proxy wieder entfernt. Der Proxy leitet die Requests an die jeweilig konfigurierten Services weiter, (wenn berechtigt). Also muss sich eine Service, an welchen der Request weitergeleitet wird überhaupt nicht darum kümmern. Es sei denn ganz spezielle Beschränkungen, welche nicht über Rollen abgedeckt werden können und z.B. nur über die ID des Nutzers erlangt werden können. Dabei entspricht der Aufbau in etwa der Zeichnung von mihe7, nur gibt es viel mehr Services.
In deinem Fall wird das nicht weiter helfen, da du deine Anwendung nicht komplett umbauen willst/kannst. Du kannst, meiner Meinung nach, die Websocket-Requests in deinem Tomcat so verarbeiten, das der Tomcat wieder als Client auftritt und die Anfragen an den eigentlichen Websocket-Server stellt, also als "man in the middle" s. (mitmproxy, https://mitmproxy.org/)
Ich denke dazu könnte man den org.apache.tomcat.websocket.server.WsFilter, https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/tomcat/websocket/server/WsFilter.html missbrauchen.

 

[mihe7]

Onlyoffice liefert logischerweise die Datei. Und onlyoffice prüft den Token an dieser Stelle nicht.

Hast Du die Validierung denn auch aktiviert? https://helpcenter.onlyoffice.com/installation/docs-configure-jwt.aspx