SSL und unsichere Elemente

novalgin · February 29, 2012, 12:31pm

Hallo zusammen,

ich bin im Moment etwas ratlos und leider hat meine sehr intensive Suche hier im Forum nur bedingt weitergebracht.

Ich habe auf meinem Server ein SSL Zertifikat installiert was auch einwandfrei funktioniert.
In der config Datei habe ich folgendes eingetragen:


$this->sShopURL = 'http://www.meinedomain.de'; // eShop base url, required
$this->sSSLShopURL  = 'https://www.meinedomain.de';            // eShop

Wenn man nun auf Schritt 2 im Warenkorb geht, erscheint in allen Browsern die Meldung, dass unsichere Elemente angezeigt werden. Nachfolgend aufgelistet:


http://www.meinedomain.de/out/com/img/favicon.ico
http://www.meinedomain.de/out/com/src/bg/bg_body.png
http://www.meinedomain.de/out/com/img/menu-divider.png
http://www.meinedomain.de/out/com/img/arrow-down.png
http://www.meinedomain.de/out/com/img/lang/de.png
http://www.meinedomain.de/out/com/img/lang/en.png
http://www.meinedomain.de/out/com/img/x.png
http://www.meinedomain.de/out/com/img/logo.png
http://www.meinedomain.de/out/com/img/header/shipping.png
http://www.meinedomain.de/out/com/img/header/freeshipp.png
http://www.meinedomain.de/out/com/img/header/paket.png
http://www.meinedomain.de/out/com/img/basket.png
http://www.meinedomain.de/out/com/img/search-icon.png
http://www.meinedomain.de/out/com/img/steps.png
http://www.meinedomain.de/out/com/img/line-innershadow.png
http://www.meinedomain.de/out/com/img/vatmsg-bg.png

Die meisten Bilder wurden in den Templatedateien per $oViewConf->getImageUrl() eingebunden, andere sind als Hintergundbilder im Stylesheet deklariert.
Das scheint kein SSL Link zurück zugeben. Der Ordner com ist übrigens ein von mir modifiziertes Azure Template was aber eigenständig läuft.
Bilder von Fremdanbietern sind übrigens auch nicht eingebunden.

Bin durch Zufall auf diesen etwas älteren Bug gestossen, der anscheinend das gleiche Problem verursacht, allerdings bei getBaseDir :

https://bugs.oxid-esales.com/view.php?id=3156

Hat jemand eine Idee? Ich bin wirklich ratlos.

Schon mal vielen Dank im Voraus.

nova

aggrosoft · February 29, 2012, 12:32pm

das verrät es dir

http://www.whynopadlock.com/

benutze die vies zum ansprechen. z.B. /index.php?cl=user

novalgin · February 29, 2012, 12:57pm

Hey,

erstmal danke für die Antwort.

So richtig schlauer bin ich allerdings auch nicht, den der Test ergab eben, dass alle CSS, Bilder und js Dateien nicht mit https sondern eben nur http eingebunden werden.

Und ich versteh eben nicht, warum das so ist. Noch einen Vorschlag?

aggrosoft · February 29, 2012, 1:38pm

du darfst nicht mit absoluten pfaden arbeiten also immer so

/out/com/img/favicon.ico
/out/com/src/bg/bg_body.png

so nicht

http://www.meinedomain.de/out/com/img/menu-divider.png
http://www.meinedomain.de/out/com/img/arrow-down.png

novalgin · February 29, 2012, 1:48pm

Das tue ich auch nicht.

Wie du siehst, betrifft es auch das Favicon, was in der base.tpl

eingebunden wird.

Das bg Bild in der css hab ich so angegeben:

background-image:url(../bg/bg_body.png);

Das Grundproblem ist ja schon, warum er z. B. das ocid.css nicht mit https einbindet, sondern nur via http, obwohl eine SSL aktive Seite besucht wird, und $oViewConf->isSsl() true ist.

novalgin · February 29, 2012, 2:53pm

Ok, Problem zumindest erkannt, denke ich.

$oViewConf->isSsl() ergibt nicht true, wenn man sich auf einer SSL Seite befindet.
Deshalb werden die Files auch nicht via HTTPS eingebunden.

Wenn ich mir die Funktion anschaue, dann wird geprüft, ob die Servervariable HTTPS gesetzt ist. Das ist sie bei mir.


Array
(
    [HTTPS] => On
    [SCRIPT_NAME] => /test.php
    [SCRIPT_FILENAME] => /WWWROOT/208965/htdocs/test.php
    [DOCUMENT_ROOT] => /WWWROOT/208965/htdocs
    [REDIRECT_STATUS] => 200
    [HK_PROXY_ADDR] => 10.1.6.5
    [SCRIPT_URL] => /test.php
    [SCRIPT_URI] => https://www.meinedomain.de/test.php
    [HK_AUTH] => 
    [HTTP_HOST] => www.meinedomain.de
    [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    [HTTP_ACCEPT_ENCODING] => gzip,deflate,sdch
    [HTTP_ACCEPT_LANGUAGE] => de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
    [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.3
    [HTTP_COOKIE] => sid_key=oxid; oxidadminprofile=0%40Standard%4010%401; oxidadminlanguage=de; admin_sid=j1upnmnaftgooe0v3rpaadqqs0; oxidadminhistory=%7Cadmin_start%7Cnavigation; language=0; sid=jtf8lnv89v0441s2rmb07fm640
    [HTTP_VIA] => 1.1 mproxy5.kontent.com (squid/3.0.STABLE8)
    [HTTP_X_FORWARDED_FOR] => XX.XXX.148.101
    [HTTP_CACHE_CONTROL] => max-age=259200
    [HTTP_CONNECTION] => keep-alive
    [SERVER_SOFTWARE] => Apache/2.2
    [SERVER_NAME] => www.meinedomain.de
    [SERVER_PORT] => 443
    [REMOTE_ADDR] => XX.XXX.148.101
    [SERVER_ADMIN] => [email protected]
    [REMOTE_PORT] => 33928
    [REDIRECT_URL] => /test.php
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.0
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => 
    [REQUEST_URI] => /test.php
    [PATH] => /bin:/usr/bin:/usr/local/bin
    [ORIG_PATH_INFO] => /test.php
    [PHP_SELF] => /test.php
    [REQUEST_TIME] => 1330523334
    [argv] => Array
        (
        )

    [argc] => 0
)

Ich blick es im Moment echt nicht. Vielleicht hat da ja noch jemand Rat.

leofonic · February 29, 2012, 3:34pm

Bei dir steht “On”, im Code steht “on”, das ist nicht dasselbe.

novalgin · February 29, 2012, 3:55pm

Hallo Frank,

du hast mich einen wirklich einen großen Schritt weiter gebracht. VIELEN DANK!

Ich denke, grundsätzlich war das, das Problem. Allerdings geht das jetzt nur in manchen Bereichen problemlos.

Da es in den meisten SSL geschützten Bereichen aber immer noch zu diesen Meldungen kommt, habe ich in der oxconfig temporär folgendes eingebunden.


print "<pre>";
print_r($_SERVER);

Ich bin dann alle Seiten durch und was musste ich feststellen? In den Bereichen wo es nicht funktioniert - z.B. 2 Schritt im Bestellvorgang, ist die Servervariable HTTPS nicht gesetzt, und auch $oViewConf->isSsl() ergibt immer false.

Liegt das am Provider? Warum funktioniert das an manchen Stellen, und an manchen nicht?

Hast du eine Erklärung?

leofonic · February 29, 2012, 4:51pm

Vielleicht bei POST-Requests? Du könntest das Array mal durchforsten ob du eine andere Variable oder Kombination findest anhand dessen sich Https bei deinem Provider identifizieren lässt.

novalgin · February 29, 2012, 5:25pm

Du hast Recht.

Alle Seiten wo es nicht geht, wird ein Post Request gesendet.
Bei allen restlichen wo es funktioniert, nur Get.

Warum ist das so? Das muss doch an der Serverkonfiguration liegen, oder?

Bis jetzt hab ich noch nichts gefunden, womit ich HTTPS sonst noch identifizieren könnte.

Idee?

leofonic · February 29, 2012, 5:38pm

Dann musst du wohl den Provider bitten dass er das auch bei POST aktiviert.

novalgin · February 29, 2012, 6:19pm

Vielen lieben Dank Frank!
Darauf wäre ich in 100 Jahren nicht gekommen.

Hab mir kurz ein kleines Script geschrieben, und es wird definitiv nur bei GET die Server Variable HTTPS gesetzt, bei POST hingegen nicht.

LG nova

novalgin · March 5, 2012, 10:53am

Vielleicht kannst du mir nochmals einen Ansatz liefern, denn das POST Problem ist zwar behoben, nur leider hat sich ein neues ergeben.

Sobald nun in dem Warenkorb versucht wird, auf Schritt 2 zu gelangen, wird sofort auf die Startseite weitergeleitet. Auch wenn man versucht sich anzumelden, wird man auf die Startseite geleitet.
Weder in der EXCEPTION_LOG noch auf dem Servereigenen LOG File sind Fehler verzeichnet.

Irgendwelche Ideen oder Vorschläge?

leofonic · March 5, 2012, 6:41pm

Sieht aber doch nach einem POST Problem aus? Gibt es eine Url?