Zum Inhalt springen

Seiten über SSL aufrufen

Erstellt am 13. Oktober 2003 · 15 Antworten · letzte Antwort am 21. Januar 2006

Tags: Server & Hosting, Frage

sunfish ·

Ja horschdi,

was hast du denn dem " Enforce HTTPS (SSL)" »gesagt«, woran er erkennen kann, ob das Protokoll bleiben kann oder gewechselt werden muss?

Bei mir klappt es auch mit einem SSL-Proxy und als Überprüfungskriterium die IP dieser SSL-Adresse.

Ulrich

horschdi ·
sunfish schrieb

Ja horschdi,

was hast du denn dem " Enforce HTTPS (SSL)" »gesagt«, woran er erkennen kann, ob das Protokoll bleiben kann oder gewechselt werden muss?

Bei mir klappt es auch mit einem SSL-Proxy und als Überprüfungskriterium die IP dieser SSL-Adresse.

Ulrich

Hallo Ulrich,

wie meinst du das ?

Das eigenartige ist, ich starte die seite schon mit https://ssl.web......... u.s.w.

dann gehe ich auf login/logout (Anmeldeschirm), melde mich mit nem FE-User an und Schwup springt er auf http://...... 77.0.html zeigt die ID der Seite an, wo ich mit redirect at login hingesprungen bin,aber nur in der Browserleiste, nicht jedoch als Seite.

Dann gehe mit Zurück im Browser und wieder auf Login/Logout, dann bekomme ich wieder https:// ......77.0.html

????

Wo musss ich dem Enforce HTTPS (SSL), was sagen.

Danke für weitere Antworten.

Kann es sein, dass sich dkd_redirect_at_login mit dem Enforce beisst ?

sunfish ·

Kann es sein, dass sich dkd_redirect_at_login mit dem Enforce beisst ?

Ja, das hört sich deutlich nach Konflikten an.
Schau mal bei deiner Extension im Verzeichnis pi in der Datei class.tx_httpsenforcer_pi1.php bei der Funtion function main($content,$conf).

Da wird einfach vor das Linkziel der https-Pfad geschrieben. Wenn das Linkziel aber über einen redirect neu im Header festgelegt wird, kann das diese Funktion mit hoher Wahrscheinlichkeit nicht wissen.

Diese Extension-Kombination habe ich nicht im Einsatz. Es ist in jedem Fall empfehlenswert, du versucht erst die httpsenforcer Extension mit einer "normalen" Seite zu testen, dann kannst du Probleme besser aufspüren, was bei einer komlexen Anwendung wie Typo3 eh schwer genug ist.

Wo musss ich dem Enforce HTTPS (SSL), was sagen.

In deiner Extension im Verzeichnis pi in der Datei class.tx_httpsenforcer_pi1.php bei der Funtion function ext_isSSL() - siehe mein vorletztes Posting. Es steht auch im Manual der Extension, zugegebenermaßen nur in dürren Worten.

Good Luck

horschdi ·

hallo sunfish,

vielen dank für deine gedanken, wir haben eben versucht, da wir die auswertungen bzw. nen fileupload sowieso aus typo3server ausgelagert haben, sie entsprechenden php scripte angepasst.
<form action="https://ssl.webpack.de/secure ........
Springen also direkt die HTTPS URL an, funktioniert auch soweit, jedoch kann dann nicht mehr die Session_ID von Typo3 fe_typo_user ausgewertet werden, die ip auch nicht, logisch weil ssl, wir müssen dies aber auswerten, da jeder angemeldete fe_user einen überblich über seine hochgeladenen files bekommen soll.

also, das war es erstmal mit ssl.

Danke nochmal und bis dahin . . .

delphin ·

Für HostEurope Nutzer!

Jedenfalls klingt ssl.webpack.de ziemlich nach HostEurope. Wir sind da nämlich auch und ich habe mich eben auch mit dem Problem rumgeschlagen.

Liegt daran, dass HE irgendwie sich nicht an die Standards so ganz hält, oder irgendwie die Info verloren geht, dass die Verbindung bereits über ein SSL-Proxy läuft.

In der Datei:
/.../ext/https_enforcer/pi1/class.tx_httpsenforcer_pi1.php

Wir die SSL-Verbindungsprüfung normalerweise in der Funktion ab Zeile 43 geprüft mit

	function ext_isSSL($port = 443)
	{
		if(@$GLOBALS["HTTP_SERVER_VARS"]["SERVER_PORT"] != $port)
			return false;			
		if(@$GLOBALS["HTTP_SERVER_VARS"]["HTTPS"] != "on")
			return false;  
		return true;
	}

Das greift bei HE leider nicht und deshalb immer der ständige Redirect.

Man kann die Funktion aber ersetzen gegen:

	function ext_isSSL()
	{
		if($_SERVER['HTTP_VIA']!= "1.1 ssl.webpack.de") 
			return false;  
		return true;
	}

und dann funktioniert es im Moment so bei HostEurope.

..

Hilft leider nicht gegen die verlorenen Session_IDs 😢 .. Denn genau das ist jetzt auch unser Problem... Mal schauen, was es da so gibt ...

delphin ·

Das beim SSL-Proxy beim Wechsel zwischen SSL und ungesichertem Bereich immer die SessionID verloren geht, wäre hier ein Ansatz, dass man SSL über den Proxy nicht mehr verlassen kann, ohne sich von der Seite abzumelden.

Dazu ersetze man folgendes

else if (!$this->ext_requiresSSL())

mit

else if (!$this->ext_requiresSSL() && !$GLOBALS['TSFE']->loginUser)

In der Datei class.tx_httpsenforcer_pi1.php (ziemlich weit unten).
Resultat: Auch wenn man für eine Seite nicht gesagt hatt, dass diese SSL aktiviert haben muss, wird kein Redirect in den NICHT-SSL Bereich gemacht, sofern man noch das Login aktiv ist. Erst wenn man sich abgemeldet hat, kann man den SSL-Proxy wieder verlassen. (Mal schauen, was die Praxis dazu sagt 😉 )

dpieper ·

Ich habe mich jetzt drei Stunden lang gefilmt, bin aber zum Erfolg gekommen. Zuerst fehlten mit die Settings in Template -> Home -> setup. Hier muss folgendes Ergänzt werden, damit vor dem Parsen entschieden wird, ob ssl verwendet werden soll oder nicht..

####################################
# Page Object
####################################

# Default PAGE object:
page = PAGE
page.typeNum = 0
page.10 < plugin.tx_httpsenforcer_pi1
page.20 < temp.mainTemplate

Danach ist eine Manipulation an /typo3conf/ext/https_enforcer/pi1/class.tx_httpsenforcer_pi1.php notwendig, da bei ALL inkl und vielleicht auch anderen Providern SSL NICHT über Port 443 läuft bzw. im var_dump['SERVER'] nur Port 80 ausgegeben wird. Hier ein kleiner Workaround:

function ext_isSSL($port = 443) {
if (isset($_SERVER['HTTP_X_FORWARDED_SERVER']) AND $_SERVER['HTTP_X_FORWARDED_SERVER'] == 'ssl-account.com'){
return true;
}
elseif (@$GLOBALS['HTTP_SERVER_VARS']['SERVER_PORT'] != $port) {
return false;
} elseif (@$GLOBALS['HTTP_SERVER_VARS']['HTTPS'] != 'on') {
return false;
} else {
return true;
}
}

^ Ich prüfe einfach, ob ich mich schon auf dem SSL Account befinde. Ansonsten lande ich in einer Endlosschleife, die ohne diesen workaround nicht unterbrochen wird, dadie Funktion ext_isSSL ja immer false zurückgibt.

Viel Spaß :-)

metan ·

Hallo,

habe mir den https_enforcer ebenfalls installiert und bekomme es nur zum Teil zu laufen.

Switch von http://www.domain.com auf
https://www.domain.com funktioniert schon gar nicht.

Swich von http://www.domain.com auf
https://ssl.kundenserver.de/domain.com funktioniert, jedoch geht die Session verloren und der Kunde findet seine Daten nicht mehr.

Habe sämtliche Lösungsvorschläge von diesem Topic durchprobiert, hat leider nichts gebracht.
Verwende einen Managed Server von 1und1.

Grüße
metan

-br3ak- ·

Das würde aber auch heißen, das ich die Domain nur über https besuchen kann, oder ?

Ich habe bei mir ein ganz normales Typo mit einem Shop am laufen, bei mir sollte nur der Shop per https laufen, damit die Robots auch den Rest durchsuchen können 😉

Aber wie setze ich ein Typo-Link (ink. Unterseiten) auf https ?

-br3ak- ·
horschdi schrieb

folgende Fehlermeldung popt auf !

"Redirection limit for this URL exceeded. Unable to load the requested page. This may be cused by cookies that are blocked."

Hat jemand eine Idee.

Habe die Kunden Login/logout Seite im Header mit Enforce HTTPS (SSL) versorgt. der springt mir nach der Anmeldung aber immer wieder in den ollen http:// Mode zurück auf die erste Seite (Shortcut), dann gehe ich im Browser zurüch und noch nochmal auf Kunden Login/Logout und habe wieder die https:// Seite.

Mein Hoster hat nur nen SSL-Proxy.

also https://ssl.webpack.de/subdomain.de

Hilfe, Heul.

Danke.

wenn ich auf dem client mit netstat -ano schaue, sehe ich auch nen offenen 443 port.

Genau das Problem habe ich auch (Host Europe, Webpack L)

Wenn ich bei

https_enforcer.unsecure_typo3_root = www.handwerks-plattform.de/cms
https_enforcer.secure_typo3_root = ssl.webpack.de/www.handwerks-plattform.de/cms

noch ein / nach dem cms mache, gibt es keine Fehlermeldung, er lädt irgendwas, landet dann aber auf der Startseite.
Die URL sieht danach so aus :

https://ssl.webpack.de/www.handwerks-plattform.de/cms//firmeneintrag.html

(mit // vor dem Firmeneintrag.html)

Wenn ich es ohne / nach dem cms ins TypoScript schreibe, gibt es die Fehlermeldung mit den Cookies 🙁

Das komische an der Sache ist : Das Kontakt-Formular läuft ohne Probleme (wurde auch nicht auf "SSL erzwingen" gestellt)

https://ssl.webpack.de/www.handwerks-plattform.de/cms/kontakt.html