Questions & Answers

[matthiasforberg]

Hallo zusammen,

ich stehe vor einer besonderen Herausforderung, und zwar sollen mit FirstSpirit (5.0) ausschließlich Dateien im Format Velocity Template erzeugt werden, die in einer Webapplikation ausgewertet werden. Die Dateien enthalten zwar den vollständigen HTML Code (also nicht nur Schnipsel), sind aber natürlich in der Vorschau relativ unbrauchbar für die direkte Anzeige.

Nun haben wir uns was ausgedacht, wie man die Vorschau umkonfigurieren könnte, dass eine Instanz der Webapplikation auf das /fs5preview Verzeichnis zugreifen kann. Wir haben das noch nicht getestet, aber ich gehe davon aus, das wir das hinbekommen.

Jetzt will der Kunde aber unbedingt WebEdit benutzen und da habe ich etwas bedenken. Hier meine eigentliche, ganz allgemeine Frage:

Läuft WebEdit automatisch über die Applikation, wenn man die Vorschau umkonfiguriert oder was muss man da noch speziell beachten? Kann das überhaupt funktionieren oder funktioniert dann das Servlet für WebEdit gar nicht mehr?

Grüße

Matthias

[isenberg]

Das Login-Ticket ist eine gewisse Zeit gültig. Ein Web-Proxy zwischen dem Browser und Preview-Server könnte beispielsweise mehrere Requests abrufen, bevor er die Seite an den Client weitergibt. Wenn dabei keine Session-Cookies verwendet werden, wird erneut nach der Anmeldung gefragt.

Die IP-Adresse in den FirstSpirit-Logmeldungen ist vermutlich die lokale des Clients, also nicht die, die tatsächlich aus Sicht des Servers für die Verbindung verwendet wird, sofern ein NAT-Router dazwischen liegt.

[matthiasforberg]

Hallo nochmal,

leider konnten wir den Fehler bislang immer noch nicht beheben, aber vermutlich haben wir jetzt die Ursache identifiziert:

Die JSESSIONID wird beim ersten Aufruf (z.B. neu gestarteter Browser) nicht bzw. zu spät gesetzt. Im Gegensatz zur Vorschau über Jetty, wo das beim ersten Request gesetzt wird (siehe Screenshot im Anhang), wird das bei der Vorschau über die externe Applikation erst beim zweiten Request (bei der ersten eingebundenen Datei lib.js) gesetzt und da nützt es offenbar nicht mehr für den Rest der ersten geladenen Seite. Dadurch werden sämtliche Ressourcen (JS, CSS, Bilder etc.) in der Seite nicht geladen. Das erklärt aber andererseits auch, warum es bei nachfolgenden Versuchen dann auf Anhieb klappt - da ist die JSESSIONID dann bereits vorhanden.

Könnte das evtl. doch ein Bug sein? Oder gibt es noch eine spezielle Konfiguration, die ich nicht finde?

Grüße

Matthias

[isenberg]

Hallo Matthias,

weil das Problem zumindest bei PHP als Dateityp, also mod_php im Apache httpd nicht auftritt, kann es eigentlich kein Fehler in der WebApp fs5preview sein. Weil Velocity aber Java-basiert ist, PHP nicht, könnte eine Ursache die doppelte Verwendung des Cookie-Namens "JSESSIONID" sein. Falls Velocity ein Cookie mit Namen JSESSIONID definiert: Kann man Velocity so einstellen, dass es kein JSESSIONID selbst definiert oder einen anderen Namen für die Sessioninformationen verwendet?

[matthiasforberg]

Hallo Holger,

nicht schlecht, Deine Vermutung!

Wir hatten tatsächlich eine Verdopplung von JSESSIONID drin. Das haben wir aber gestern geändert, die Anwendung erzeugt jetzt eine andere Variable. Jetzt frage ich mich nur warum der Jetty (der setzt doch den ersten Request ab, oder?) in diesem Fall die JSESSIONID nicht beim ersten Request setzt (wie in meinem Screenshot oben), sondern erst beim zweiten? Ich glaube, wenn wir das verstehen, haben wir vermutlich auch die Lösung gefunden. Aber momentan verstehe ich es nicht.

[Peter_Jodeleit]

Jetzt frage ich mich nur warum der Jetty (der setzt doch den ersten Request ab, oder?) in diesem Fall die JSESSIONID nicht beim ersten Request setzt (wie in meinem Screenshot oben), sondern erst beim zweiten?

Anhand des Screenshots kann ich das Verhalten nicht nachvollziehen. Verhält sich denn ein Tomcat genauso?

[isenberg]

Ein ähnliches Problem hatten wir schon einmal beim Einsatz von Web Application Firewalls (Reverse Proxy), die auch gerne JSESSIONID als Standard verwenden.

Aber warum es jetzt immer noch nicht funktioniert, erklärt es somit nicht. Es gibt manchmal Situationen bei WebApp-Servern, wo ein Servlet den Response-Header nicht mehr erweitern kann, also z.B. eben kein Cookie mehr eintragen kann, was von der Größe des Output-Buffers abhängt. Das könnte hier so etwas sein. Um das auszuschliessen, einmal eine sehr kurze .vm-Datei erstellen, nur wenige Bytes, und nur 1 externe Resource wie .css dort verlinken.

[matthiasforberg]

@ Peter: der Screenshot zeigt den ersten Request in Firebug für eine Vorschau in Jetty - also die funktionierende Variante. Bei unserer Applikation (übrigens Weblogic) fehlt die gelb markierte Zeile, dieser Eintrag ist dann beim zweiten Request drin (bei der 1. externen Ressource, die geladen wird).

@ Holger: okay, das werde ich mal ausprobieren. In der Tat sind die Dateien sehr groß, weil sie neben diversen XML-Metadaten auch noch die komplette Zeitsteuerung enthalten, d.h. pro Zeitabschnitt einen kompletten HTML/Velocity-Code...

[matthiasforberg]

So, wieder neue Erkenntnisse:

eine kurze Datei hat auch kein anderes Ergebnis geliefert, die Ressource wird nicht geladen. Aber wir haben inzwischen noch etwas anderes herausgefunden:

Wir haben festgestellt, dass anscheinend Cookies, welche durch die externe Preview-Anwendung gesetzt werden, zu dem Fehler führen. Wenn diese einen Cookie setzt (und dabei ist der Cookie-Name beliebig), so fügt der FirstSpiritServer den eigenen SessionCookie nicht an den Response an. Wenn die externe Anwendung keinen Cookie setzt, so wird der Session-Cookie durch FirstSpirit gesetzt und die nachfolgenden Requests sind erfolgreich. Wie kann das sein?

Den Cookie nicht zu setzen ist für uns leider keine Option, da wir die Session in der externen Anwendung für unterschiedliche Szenarien benötigen.

[Peter_Jodeleit]

Ich lasse das prüfen unter der internen ID #155446.

Kannst du parallel dazu ein Ticket beim Helpdesk öffnen?

Ich melde mich dann hier wieder, wenn wir neue Erkenntnisse haben.