Hallo Community,
PAYBACK nutzt in seinem aktuellen Setup eine externe Vorschau. Die PHP-basierte Frontend-Applikation interpretiert dynamische Markups (XML-Tags), die von entsprechenden Seiten- und Absatzvorlagen ausgegeben werden um das Benutzer- und Zustandsbasierte Verhalten auch in der Vorschau zur Verfügung zu stellen. Hierzu nutzen wir die in der Doku unter Kapitel 4.3.1.9 beschriebene Möglichkeit über den Parameter "preview.externalDeliveryURL" der fs-server.conf:
preview.externalDelivery=*
preview.externalDeliveryURL=http://dev1.payback.com:8443
Der unter dem Port 8443 erreichbare Server beinhaltet die PHP-basierte Frontend-Applikation, die auch die Produktionsseite (=deployed version) ausliefert.
Im aktuellen Setup werden die Module der Frontend-Applikation über Markups referenziert, die über FirstSpirit Absatzvorlagen generiert werden um sie für den Redakteur einfach einbindbar zu gestalten.
Der Redakteur kann aktuell bereits Inhalte anlegen, die Vorschau anzeigen und innerhalb der ersten Seite eines Workflows (z.B. Anmeldung zum PAYBACK-Programm oder Login) auch Inhalte direkt in der Vorschau pflegen.
PROBLEM
Aus Security-Gründen nutzen alle Workflows SSL-gesicherte POST-Requests, die in der Vorschau zu einem Fehler führen und die Anwendung (PHP-basierte Frontend-Applikation) nicht korrekt arbeiten lässt. Der FirstSpirit-Server quittiert einen POST-Request aktuell mit einem Status 403 (Forbidden). Damit kann der Redakteur weder die Inhalte in allen Fehler-Konstellationen pflegen einen Workflow (z.B. Anmeldung) in der Vorschau bedienen. Dies stellt insbesondere bei der Inhaltspflege einen gravierenden Nachteil dar.
WORKAROUND via GET-Request
Die Vorschau-Applikation ist als voll funktionsfähige Webseite ausgelegt und der Benutzer kann somit auch Produktions-Karten zum Login verwenden. Stelle ich die Formulare auf GET um, generiere ich dadurch ein Sicherheitsloch und gefährde die Daten meiner Kunden.
Ferner wird für das Rollout der Applikation sowohl auf dem Vorschau- als auch auf den Produktions-Servern mit einem einzigen Artefakt realisiert. Damit wäre es mit einem deutlichen Aufwand verbunden, beide Request-Methoden zuzulassen und dauerhaft zu unterstützen.
ERWARTUNG
Aus Sicht eines Redakteurs muss die integrierte Vorschau - genau wie Webedit und die Produktionsseite - vollständig bedienbar sein.
Dies bedeutet, dass das Preview-Servlet die originäre URL als HTTP-Header mitliefert, damit die Vorschau-Applikation diese als Anfrage-URL nutzen kann (z.B. für Formulare oder als Base-Href) und zusätzlich dazu POST-Requests zulässt und die Request-Parameter an die Vorschau-Applikation durchschleift.
Wünschenswert wäre zudem, das komplette HTTP-Protokoll (darunter z.B. PUT) für AJAX-basierte Applikationen zu unterstützten.
ANALYSE
Ruft der Redakteur eine Seite (in diesem Fall die Login-Maske) auf, so wird im Client die URL
http://dev1.payback.com:8000/fs5preview/preview/13144/page/EN/current/13147/13476/noEvent/guiLanguag...
angezeigt.
Schicke ich das Login-Formular ab so postet der (externe oder integrierte) Vorschau-Browser gegen die URL
http://dev1.payback.com:8443/fs5preview/preview_cache/13144/EN_c_13476.13147_t1357899224300.html
da diese auch beim Vorschau-Webserver ankommt.
Die im Formular veränderte URL resultiert daraus, dass der Sub-Request des FirstSpirit-Servers (fs5preview-Servlet) gegen den mit "preview.externalDeliveryURL" konfigurierten externen Vorschau-Server effektiv
127.0.0.1 - - [11/Jan/2013:11:29:08 +0100] "GET /fs5webedit/preview_cache/13144/EN_c_13476.13147_t1357899224300.html HTTP/1.1" 200 63511 "-" "Jakarta Commons-HttpClient/3.1"
lautet. Die eigentliche URL steht dem Vorschau-Server damit nicht zur Verfügung.
Selbst wenn die URL des Formulars auf die URL des FirstSpirit-Vorschau-Servlets korrigiert wird, kommt bei einem POST des Formulars auf dem externen Vorschau-Server leider nur ein GET-Request an, dem die notwendigen Request-Paremeter fehlen.
Der zurückgegebene 403-Fehler resultiert vermutlich daher, dass die referenzierte Datei auf dem Filesystem, die von FirstSpirit in der Vorschau generiert wird, nicht mehr oder nicht unter der "falschen" URL existiert.
Feature-Request
Für PAYBACK stellt eine integrierte, voll funktionsfähige Vorschau eine essentielle Funktionalität dar. Aus diesem Grund wünsche ich mir für die künftige Version von FirstSpirit eine vollständige Unterstützung des HTTP-Protokolls für externe Vorschau-Applikationen. Dies ist IMHO nicht nur für PAYBACK ein sehr interessantes Feature, sondern auch für FirstSpirit selbst, da sich FirstSpirit konzeptionell nicht um die Generierung von dynamischen Inhalten kümmern möchte.