Hallo zusammen. Gibt es etwas zu beachten, wenn ich ein eigenes Plugin entwickeln möchte, welches die Kommunikation per HTTPS ermöglicht, falls im Backend aktiviert? Speziell interessieren mich sämtliche Einstellungen (Konstanten, Methoden, Änderungen an der .htaccess oder Apache-Konfig) die für eine Korrekte Funktion via Port 443 nötig sind. Vielen Dank im Voraus
[quote=„fdehn“] Gibt es etwas zu beachten, wenn ich ein eigenes Plugin entwickeln möchte, welches die Kommunikation per HTTPS ermöglicht, falls im Backend aktiviert? [/quote] Mir scheint es hier (nicht unbedingt nachvollziehbar) ab und an seltsame Verhaltensweisen von Shopware zu geben, gerade was das Handling von HTTP und HTTPS anbetrifft. Bspw. kann ich wie folgt einen Link generieren: $successUrl = $this-\>Front()-\>Router()-\>assemble(array( 'action' =\> 'end', 'transactionId' =\> $sometransaction, 'id' =\> $someid, )); Der Router erzeugt mir dabei vollqualifizierte URLs, je nach aktuellem Controller mit HTTP oder HTTPS. Ich habe dabei (soweit ich weiß) keine Handhabe, was das Erzwingen von HTTPS angeht. Dabei kann es durchaus erwünscht sein, dass aus einem Controller heraus ein Link zu einem anderen Controller (welcher gesichert per HTTPS kommunizieren soll) erstellt werden soll. Derzeit behelfe ich mir, in dem ich die komplette (sub-)Domain des Shops auf HTTPS redirecten lasse. Dies lässt sich mit zwei zusätzlichen Zeilen Code in der .htaccess im Shopware-Root bewerkstelligen. RewriteCond %{HTTPS} !=on RewriteRule .\* https://%{SERVER\_NAME}%{REQUEST\_URI} [R,L] Diese Zeilen sollten direkt unter folgender Zeile ergänzt werden: RewriteEngine on sodass es später in etwa so aussieht: [code]
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
#RewriteBase /shopware/
…
[/code]
Ich würde mir zu dem weiter oben beschrieben Sachverhalt mit der Router-Komponente (ursprünglich eine Komponente des Zend-Frameworks) Feedback seitens Shopware wünschen…
Hi, um bei der Url-Erzeugung eine “HTTPS”-Url zu bekommen, muss man einfach zusätzlich den Parameter “forceSecure” mit dem Wert “true” übergeben. Das würde z.B. so aussehen: $successUrl = $this-\>Front()-\>Router()-\>assemble(array('action' =\> 'end', 'forceSecure' =\> true)); Heiner
[quote=“Heiner Lohaus”] $successUrl = $this-\>Front()-\>Router()-\>assemble(array('action' =\> 'end', 'forceSecure' =\> true)); [/quote] Wunderbar, Danke. In diesem Fall muss ich aber vorher entscheiden können, ob gerade SSL überhaupt aktiv ist. Use-Case: Auf URL weiterleiten, Aktion ausführen, auf URL (in den Shop) zurückleiten. Wenn ich nun aus einem HTTPS-Shop komme, weiterleite, meine Aktion durchführe und schließlich in den Shop mit HTTP (ohne S!) zurückleite, so könnte es vorkommen, dass meine Session futsch ist (-> Warenkorb, User, …) (Stichwort session.cookie_secure = on, http://php.net/manual/en/session.configuration.php) Gibt’s keine fesche Methode, um den Status von SSL im Backend abzufragen? Ich könnte natürlich ne Abfrage auf die Datenbank starten, aber ne hübsche Funktion/Methode wäre nettt. Auch zu Dokumentationszwecken. Darüber hinaus beantwortet die knappe Antwort meine Frage nur zum Teil: Gibt es Dinge zu beachten, wenn man Subklassen vom “Shopware_Controllers_Frontend_Payment”-Controller erzeugt mit aktiviertem SSL (und evtl. kruden Einstellungen zu Session-Cookies in PHP)? Beim Testen mit dem Internet Explorer 9 bin ich mit einem selbst-zertifizierten SSL-Zertifikat auf ein seltsames Verhalten gestoßen: beim Checkout leitet Shopware auf eine weitere, selbst-zertifizierte Webapplikation weier. Der IE fragt brav nach, ob das Zertifikat akzeptiert werden soll. In diesem Schritt hatte Shopware aber bereits alle Daten an per POST versendet, also die Bestellung final ausgeführt. Nach dem Akzeptieren des eigenen Zertifikats sendet Shopware den Warenkorb erneut ab… somit resultiert eine Bestellung in zweien. Gut, dies könnte tatsächlich dem eigenen Zertifikat geschuldet sein und wird wohl so in der freien Wildbahn kaum vorkommen… dennoch: ein seltsamer Beigeschmack bleibt. Des weiteren: Wäre es nicht sinnvoller, bei aktiviertem SSL sämtliche URLs des Shops auf HTTPS (Port 443) umzubiegen? Wenn nein, weshalb?
Hi, die Option „forceSecure“ hat übrigens jetzt schon nur eine Auswirkung, wenn der Shop dafür aktiviert wurde. Eine Abfrage dafür (davor) zu bauen ist daher nicht nötig. Das Verwenden von SSL im ganzen Shop ist übrigens auch nicht ratsam, da HTTPS um einiges langsamer ist als HTTP und auch mehr Ressourcen verbraucht. Ein Session-Problem sollte es dabei auch nicht geben, da die genannte Option nie in Shopware-Shops aktiv ist. Sonst würde nämlich der ganze Bestellprozess in Shopware nicht funktionieren. Heiner
[quote=“Heiner Lohaus”] die Option “forceSecure” hat übrigens jetzt schon nur eine Auswirkung, wenn der Shop dafür aktiviert wurde. Eine Abfrage dafür (davor) zu bauen ist daher nicht nötig. [/quote] Okay, war offensichtlich ein Problem mit dem Cache. [quote=“Heiner Lohaus”] Das Verwenden von SSL im ganzen Shop ist übrigens auch nicht ratsam, da HTTPS um einiges langsamer ist als HTTP und auch mehr Ressourcen verbraucht. [/quote] Diese These würde ich gerne belegt haben. Da es sich bei der Kommunikation per SSL um eine weitere Schicht handelt, der Handshake erst ausgehandelt werden muss etc. ist mir durchaus klar. Aber: in wie fern soll sich dies denn auf die “Geschwindigkeit” auswirken? Bei lokalen Tests erwies sich meine Testmaschine bei HTTPS sogar als einen Tick performanter. Was sagt denn Apache Bench oder JMeter dazu in Sachen Datendurchsatz oder Reaktionszeit eines Servers? [quote=“Heiner Lohaus”] Ein Session-Problem sollte es dabei auch nicht geben, da die genannte Option nie in Shopware-Shops aktiv ist. Sonst würde nämlich der ganze Bestellprozess in Shopware nicht funktionieren. [/quote] Was, wenn ein Shared-Hoster diese Option gesetzt hat, man aber in seiner Kundeninstanz keinen Einfluss auf die Settings hat? In diesem Falle hätte man eine grundsätzliche Trennung von HTTP und HTTPS, was die Sessions betrifft. Dass der Checkout-Prozess dann durchaus seltsame Verhaltensweisen präsentieren könnte… klar. Für diesen Fall wäre eine grundsätzliche Umleitung auf HTTPS sicherlich die praktikabelste Lösung…