Seiten über SSL aufrufen

Hallo!

Ich komme leider trotz Recherchen in verschiedenen Foren nicht weiter und muss jetzt doch nochmal hier fragen, ob nicht jemand eine Idee hat:

Ich habe ein Typo-Projekt unter www.meinprojekt.de liegen.
Einzelne Seiten des Projekts sollen über SSL angezeigt werden, dafür exisitert ein eigenes Zertifikat ssl.meinprojekt.de, das einfach auf das Typo-Projekt verweist.

Im direkten Aufruf funktionieren Seiten auch z. B.
https://ssl.meinprojekt.de/index.php?id=18

Nun habe ich beide Typo-Extensions für HTTPS ausprobiert – aber keine läuft.

EXT Secure/Unsecure führt den Redirect für eine SSL-Seite richtig aus, bleibt dann aber in einer Reload-Schleife hängen ("Page is being generated").

https/http Enforcer führt direkt zu einem Fehler ("Die Seite kann nicht angezeigt werden").

Hat jemand eine Ahnung, woran das liegen könnte bzw. wo man noch schauen kann?
Vielen Dank!

Micha

Ich habe das Problem gelöst – und falls jemand vor den gleichen Schwierigkeiten stehen sollte, sei der Weg kurz wiedergegeben:

Zur Extension Secure/Unsecure habe ich leider keinen Weg finden können, die ist wohl einfach noch nicht reif.

Ich habe also die Extension HTTP/HTTPS Enforcer eingebunden. Dort trat ja, wie geschildert, das Problem auf, dass der Aufruf einer SSL-Seite zur "Seite kann nicht angezeigt werden" führte (Host: ProfiHost). Im Server-Log wurde ein Bad Header gemeldet - es knallte also beim Redirect.

Ich konnte die Sache leider nur lösen, indem ich das Coding änderte wie folgt:

Verzeichnis (typoprojekt)/typo3conf/ext/https_enforcer/pi1/ oder File Edit im Extension Manager

Datei: class.tx_httpsenforcer_pi1.php

Und in der Funktion

function ext_hardRedirect($url)
{
	header("HTTP 302 Redirect");
	header("Location: " . $url);
	exit;
}

den 302 Redirect auskommentieren:

function ext_hardRedirect($url)
{
	/* header("HTTP 302 Redirect"); */
	header("Location: " . $url);
	exit;
}

So läuft es bei mir.

Wer eine sauberere Lösung findet, bitte gerne posten :-)

Micha

Hallo Micha,

ich stehe auch gerade vor diesem Ploblem und habe genau wie du die beiden Erweiterungen durchgetestet -- ohne wirklich zufriedenstellenen Erfolg. Zwar laufen bei mir beide Versionen (auch ohne Deinem "hack") und tun erstmal was sie sollen, jedoch werden die Redirect-Anweisungen von Typo3 ge-cache-t.

Zur Verdeutlichung:
Seiten-IDs aus Bereich *ohne* ssl: 1,2
Seiten-IDs aus Bereich *mit* ssl: 4,5

* "Clear all cache" im BE gewählt
* Aufruf der ID1 ( Startseite )
* Link zur ID4 ( redirect auf https-domain )
* Link zur ID5 ( kein redirect, weil immernoch https )
* Link zur ID2 ( redirect zu http ohne ssl)
* Link zur ID5 ( *kein* redirect auf https, weil ID5 ohne redirect im cache liegt )

Leider sind die Erweiterungen somit für mich nicht zu gebrauchen.
Mich würde interessieren, ob dieses Problem bei Dir auch auftritt, oder evtl. mit meiner Installation in Zusammenhang steht.

Viele Grüße von Martin

Hallo,

auch ich hatte die selben Probleme mit ssl:

Secure/Unsecure landet in einer Schleife (?)

Und der HTTP/HTTPS Enforcer ging zuerst auch nicht ("Seite kann nicht angezeigt werden").

Ich hab dann aber die Lösung gefunden (für den Enforcer):

Einfach im Constants Feld folgendes einfügen:

https_enforcer.unsecure_typo3_root = deinedomain.de
https_enforcer.secure_typo3_root = deinessldomain.de

(nicht
plugin.tx_httpsenforcer_pi1.unsecure_typo3_root = www.meinserver.de
plugin.tx_httpsenforcer_pi1.secure_typo3_root = secureserver.de/meineid
wie fälschlicherweise hier im Form zu lesen) #evil#

und noch im setup (bevor die Seite zusammengebaut wird):

page.5 < plugin.tx_httpsenforcer_pi1

Seitdem klappts auch mit dem Nachbar 😃

(Evtl müssen noch im Constant Editor beim HTTPS Enforcer die beiden Häckchen aktiviert werden - die urls können auch hier gleich reingeschrieben werden, dann erscheint der richtige code gleich in den Constants im Template)

sascha

Hallo,

ich denke es ist KEIN HACK,
wenn die Zeile:
//header("HTTP 302 Redirect");
auskommentiert wird.

Schließlich steht im PHP-Manual:

Der zweite Spezialfall ist der "Location:" Header. Es wird nicht nur der Header an den Browser geschickt, sondern auch ein REDIRECT (302) Statuscode, wenn nicht bereits ein 3xx Statuscode gesendet wurde.

Woran es noch hängen kann, dass nicht erkannt wird, ob bereits mit "https://" aufgerufen wird, ist die Funktion: function ext_isSSL()

Hier ist mit phpinf(); zu prüfen, ob die in der Funktion abgefragten Globalen Variablen überhaupt zur Verfügung stehen. Bei mir ist z. B. ["HTTP_SERVER_VARS"]["SERVER_PORT"] kein Unterscheidungsmerkmal und ["HTTP_SERVER_VARS"]["HTTPS"] wird gar nicht ausgegeben. Ich habe mich daher so beholfen:

function ext_isSSL()	{
if($_SERVER['REMOTE_ADDR']!= "XX.XX.XX.XXX") return false;
else return true;
}

Vielleicht hilft das ja jemandem...

Grüße

Ulrich

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.

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

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 ?

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

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 . . .

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 ...

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 😉 )

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ß :-)

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

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 ?

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