Frage wegen redirect-Erweiterung

[CrazyHorst]

Ich hab die Erweiterung von Andreas installiert und wollte das mal testen, wie das mit der Weiterleitung zwischen http und https funktioniert. Ich hab ein Modul mit 'SSL-Weiterleitung' und ein Modul mit 'Nicht-SSL-Weiterleitung' angelegt und auch 2 Layouts für jedes Modul. Die Weiterleitungsdomain hab ich bei beiden Modulen leer gelassen. Seiten die normal über http aufgerufen werden sollen, hab ich das Layout ohne SSL vergeben und die Seiten die per https aufgerufen werden sollen das Layout mit SSL. Ich bekomm aber beim Aufruf einer https Seite die Fehlermeldung:

Fehlercode: ssl_error_rx_record_too_long

Hoster ist All-Inkl, hab mal in einem Ticket gelesen, wo Leo beschreibt was man bei All-Inkl als Hoster in der localconfig schreiben soll

if (strpos($_SERVER['HTTP_X_FORWARDED_SERVER'], 'ssl') !== false)
{
$_SERVER['HTTPS'] = 1;
} 

Das hab ich auch gemacht. Weiß trotzdem nicht woran das liegen soll

[planepix]

Hallo CrazyHorst,

ich bin u.a. bei allinkl.

Für das Modul SSL-Weiterleitung ist eingetragen:
Weiterleitungsdomain: ssl-account.com/domain.tld

Für das Modul keine SSL-Weiterleitung:
weiterleitungsdomain: www.domain.tld

Als SSL wird das Proxy-SSl von allinkl verwendet.

[CrazyHorst]

Super hat funktioniert, danke.

[planepix]

Gerne doch.

[miss.moxy]

Hallo!

Ich hoffe, es ist ok, wenn ich mich hier dran hänge - mein Problem hat auch mit [redirect] und dem all-inkl-SSL zu tun…

Ich habe den redirect funktionierend installiert, d.h. die Seiten, die verschlüsselt laufen sollen, werden so wie ich es will weitergeleitet, allerdings funktioniert der Mitglied-Login nicht. Wenn ich mich einlogge und z.B. meine Profil-Daten (geschützte Seite + SSL-Weiterleitung) ansehen will, erhalte ich einen 403-Error, es scheint, als würden die Login-Daten nicht auf die gesicherte Domain (ssl-account.com/meinedomain.tld) weiter gereicht?

Kann mir wer vom Schlauch helfen?

Danke und einen guten Rutsch!
mi.mo

TL 1.7.5 + aktuellste Erweiterungsversionen

[planepix]

Hallo mi.mo,

hast Du 2 Seitenlayouts erstellt (1x mit SSL-Modul, einmal ohne) und dann den Seiten, die via SSL aufgerufen werden sollen, das Seitenlayout mit SSL zugewiesen?

[miss.moxy]

Hi

Ja, die Weiterleitungen selbst funktionieren soweit ich es sehen kann problemlos - ich lasse mir ein "SSL aktiv" bzw. "SSL inaktiv" ausgeben, die geschützten Seiten verwenden definitiv das SSL-Layout.
Nur eben der Login funktioniert nicht so wie ich es will

[planepix]

Hmm, ich teste das mal eben mit der Konstellation allinkl, TL 2.7.6 und Mitglieder-Login.
Ok, ich habe den Mitglieder-Login ohne SSL bisher benutzt, nun umgestellt erhalte ich auch eine forbidden-Meldung.

Ok, wieder was für die To-Do-Liste 2010
Also aktuell leider keine schnelle Lösung

[miss.moxy]

Ok - danke fürs Nachprüfen! Dann liegt es nicht an mir, ich dachte schon, ich bin zu doof

Ich brauch das Ganze auch nur, weil ein Webshop dran hängt und der Kunde ein SSL-Zertifikat verwenden will.
Wenn ich nicht-verschlüsselt Waren in den Warenkorb lege und mir diesen dann verschlüsselt ansehen will, ist er auch leer.
Die Cookies werden also scheinbar nicht übergeben, oder?
Weil wenn ich die Login-Seite selbst auch schon verschlüssel geht es.
Doof
Das Kunden-SSL liegt auf der gleichen Domain, vielleicht geht es ja so.
Ansonsten muss ich (bis eine Lösung gefunden wurde) halt den ganzen Shop weiterleiten.

DANKE!

[planepix]

Du könntest mal mit der Firefox Erweiterung HTTPLiveHeaders schauen was aufgerufen wird - meist kommt man damit ein Schritt weiter (Pfade etc).

[miss.moxy]

…jetzt verlangst du aber was von mir…

Ich kann da nur rauslesen, dass auf der nicht-verschlüsselten Login-Seite der FE_USER_AUTH-Cookie gesetzt wird. Das Login-Formular leitet auf die Mein-Konto-Seite weiter, die das SSL-redirect-Modul hat, also auf die verschlüsselte Mein-Konto-Seite weiterleitet. Und genau da gehen die gesetzten Cookies verloren und es wird eine neue Session gestartet.
Mehr kann ich da jetzt leider auch nicht sehen

Grüße!

[bird]

Hallo,

ich hänge mich hier auch mal an die Diskussion.

Ich möchte ebenfalls bei einem Webspace von all-inkl den User nach dem Frontend-Login auf SSL/TLS geschützte Seiten weiterleiten.

Ist es sinnvoll, schon die Login-Seite per SSL/TLS zu schützen oder reicht es, wenn die Zielseite geschützt ist?

Ist unter TL 2.8 das o.g. Problem (Fobidden-Meldung / neue Session) behoben?

LG
hangover

[andreas.schempp]

Du solltest auf jeden Fall auch die Login-Seite verschlüsseln, sonst werden 1. die Daten ohne Verschlüsslung übertragen und 2. ist ev. sein Cookie dann nicht gültig.

[bird]

Hallo Andreas,

danke für die Antwort, der Meinung bin ich mittlerweile auch.
Wenn man bei den großen Online-Shops und Plattformen schaut, ist der Login-Bereich in der Regel auch geschützt.

Deiner Antwort entnehme ich zudem, dass unter TL 2.8 (und Übergabe von einer SSL-geschützen Login-Seite) die Session nicht mehr abgebrochen wird?

LG
hangover

[andreas.schempp]

Da wäre ich mir nicht sicher, ich glaube nicht dass da etwas mit 2.8 geändert hat. Das Problem ist dass das Cookie für eine andere Adresse gültig ist. Müsstest du ausprobieren

[bird]

Ok :-)
Aber das Problem dürfte doch eigentlich nicht auftreten, wenn die Login-Seite auch schon über https läuft und sich an der TLD nichts mehr ändernt (egal, ob ein in der URL vorgeschaltetes all-inkl Zertifikat oder ein eigenes Zertifikat genutzt wird?

LG
hangover

[andreas.schempp]

Probier's aus, hab's nie versucht

[bird]

Ok...jetzt bin ich neugierig!
Du hast ja schon viele Module/Projekte mit TL realisiert und jede Menge Erfahung. Hast Du SSL in der Form noch nicht benötigt oder das Problem grundsätzlich anders gelöst?

[andreas.schempp]

Ich mach keine Webseiten sondern nur Entwicklungen. Umsetzen tun meine Kunden - die Agenturen.

[bird]

Das ist natürlich ein Punkt.
Trotzdem ist die Entwicklung ja im Regelfall zielgerichtet und es hätte natürlich sein können, dass sich ein Kunde in Bezug auf dieses Modul bzw. die Entwicklung und Funktion gemeldet hat, weil die Umsetzung gut funktioniert oder Probleme bestehen...

[Tim G]

Hey Leute,
sorry, dass ich das Thema wieder aufwärme, aber gibt es inzwischen eine Lösung für das oben beschriebene Problem?

Ich sitz grad an einer Seite mit Kundenlogin(SSL) und Isotope Webshop, gehostet auf 1und1. Verwende den ssl-proxy.

Selbst wenn ich die ganze Seite permanent auf SSL laufen lasse, kriege ich Conti nicht dazu den user einzuloggen. auch ein inserttag mit den aktuellen benutzerdaten bleibt leer, Gast-Module bleiben sichtbar. Referer-Prüfung ist auch deaktiviert.

Ohne SSL funzt alles.

Gibts dazu ne Lösung?

Grüße,
Tim

[xchs]

Hallo Tim G,

gestern gab es dazu eine Diskussion im Zusammenhang mit SSL und ".htaccess"-Anpassungen - allerdings für den Hoster "ALL-INKL". Vielleicht kannst Du daraus auch irgendwelche Schlüsse für Deinen Fall ableiten...

[Tim G]

Hey,
habs ausprobiert. Das ist es allerdings nicht.

Im Grunde funktioniert ja alles mit SSL (benutze die ssl-redirect extension dafür). Nur Frontend-Benutzer logins werden nicht übernommen, also irgendwo bleiben die Sessions und Cookies hängen.
Daher werden geschützte Module, Seiten, die Kasse von Isotope etc. nicht angezeigt bzw. können nicht verwendet werden.

Any idea?

[jan.theofel]

Hi,

Live-Beispiele?

Jan

[Tim G]

Ja, kann ich geben:

ich leite jetzt auch gleich alle Seiten auf den ssl-proxy um, nur um den benutzerlogin zu testen, der mit ssl nicht übernommen wird. (ohne funktioniert es).
(ist alles rein auf dummy, also ohne css)

www.public-poetry.com/cms
user: test
pw: 12345678

scheint aber mehr ein conti problem zu sein, als vom redirect modul.

ps. wenn der login erfolgreich wäre, würde man mit Hallo und dem jeweiligen Vor- / Nachnamen begrüßt werden und die geschützten Seiten "Mein Konto, Logout, etc." wären sichtbar.

Thx