Frontend-Login auch für externe Seite verwenden

[althoffc]

Hallo,

ich bin mir nicht sicher, ob ich hier mit meinem Thema richtig bin.

Für unseren Verein gibt es zwei Websites. Die eine ist mit Typolight erstellt worden. Die andere ist vor langer Zeit komplett auf (nicht von mir) selbst erstellten Html/PHP-Skripten/Mysql-DB erstellt worden.
Für beide Seiten (die eigentlich zusammengehören), ist zur Zeit für den gleichen Benutzer jeweils ein Login erforderlich. (Die Benutzerdaten liegen in zwei verschiedenen MySQL-Datenbanken.)

Ich möchte gerne erreichen, dass sich die Vereinsmitglieder im TL-Frontend in den geschützten Mitgliederbereich anmelden und anschließend über einen Link auf die zweite Seite ohne weiteren notwendigen Login gelangen können. Die Zugangsberechtigung zur TL-Seite gilt prinzipiell auch für die "externe" Seite, so dass eine zweite Prüfung der Zugangsberechtigung nicht erforderlich wäre.

Es soll also die Zugangsberechtigung für den Mitgliederbereich (TL) auf die externe Seite "mitgenommen" werden, so dass kein weiterer Login erforderlich ist.

Lässt sich so etwas lösen?
Wie könnte dazu ein Ansatz aussehen?

Gruß, Carsten

[opcode]

Hallo Carsten,

ich stehe gerade genau vor dem gleichen Problem und wollte mal anfragen ob du zu einer Lösung gekommen bist, da scheinbar hier im Forum das ganze auch noch nicht behandelt wurde..

Ich muss nach erfolgtem Frontend-Login dem Mitglied (in meinem Fall dem Händler) einen Link zur Verfügung stellen der auf eine externe Shopseite linkt. Der Link besteht aus einem MD5-Hash /login.php?id=209c16cfed516fe3909529d925327e3f), welcher sich aus dem Username und der Postleitzahl zusammen setzen muss. Damit wäre der Händler dann beim betreten der Shopseite auch gleich eingeloggt.

Die Homepage ist vor etlichen Jahren mit Typo3 umgesetzt wurden und dort wurde das Problem mit einem Modul gelöst. Der Link erfolgte somit auf eine unsichtbare Seite der Homepage in welcher das Modul diese Weiterleitung zum Shop generierte..

Könnte man doch eigentlich auch mit Contao lösen oder??? Wie hast du das Problem gelöst??
Vielleicht kannst Du oder jemand anderes hier im Forum mir mal damit helfen.

Danke

[soweit_ok]

Das SSO-Modul bei Typo3 basiert auf OpenSSL. Ließe sich sicher auch in Contao integrieren, doch den Aufwand dafür wollte wohl bisher noch niemand treiben. Vermutlich wird es auch bei euch auf Programmierung einer Bridge zur ext. Webseite hinauslaufen.

Falls doch SSO-Implementierung, lasst es mich bitte wissen - könnte ich auch gut gebrauchen.

[althoffc]

Hallo,

ich habe selbst bisher keine Lösung gefunden. Ich habe das Thema nicht mehr ernsthaft weiterverfolgt, da es für uns ohnehin nur eine Übergangslösung gewesen wäre, bis die beiden bisher getrennten Webseiten in eine zusammengefasst werden.

Ich weiss selbst nicht, wie man eine "bridge" umsetzen müsste. Auch eine "SSO"-Lösung sagt mir nichts.
Leider kann ich zu diesem Thema nicht weiterhelfen.

Gruß
Carsten

[soweit_ok]

Hallo Carsten,

SSO ist die Abkürzung für "Singl Sign On", das sich also Mitglieder bei mehreren dafür autorisierten Webseiten nur einmal anmelden müssen. Es gibt auch eine Doku darüber, wie das SSO-Modul auf Basis von OpenSSL bei Typo3 funktioniert - bei Interesse kannst Du die gewiss mit Google finden.

Für eine Bridge gibt es keine Einheitslösung. Dafür muss analysiert werden wie die Benutzerauthentifikation der beteiligten Webseiten arbeitet. Prinzipiell müssen die Datenbankeinträge synchronisiert und beim Übergang des Benutzers auf die entfernte Webseite per aut. Anmeldung im Hintergrund die Session erzeugt werden.

Da ihr jedoch sowieso die Webseiten zusammenlegen wollt, würde ich keine der beiden Lösungen empfehlen, falls man auch ohne leben kann. Es sauber zu implementieren, wäre mir für eine Übergangslösung wahrscheinlich zu aufwändig. Eine Bridge ist manchmal recht schnell gebaut, kann von Fall zu Fall aber auch in elendes Gefrickel ausarten. Auch abhängig davon, in welche Richtungen sie funktionieren soll. Auskunft ohne Gewähr - am besten vielleicht nochmal jemanden fragen, der sich sehr gut mit dem Thema auskennt. Ich hab sowas erst einmal gemacht, eine unidirektionale vom CMS Contenido zu OSCommerce.

[opcode]

Erstmal danke für Eure schnellen Antworten. Werde dann mal schauen ob wir das gebacken bekommen. Falls ja werde ich das hier mal posten..

Gruß
Andreas

[Flex]

Es ist auch relativ einfach möglich Contao dazu zu bringen die Benutzer zu übernehmen. Du solltest dir die Hooks "checkCredentials" und "importUser" mal anschauen.

[althoffc]

Hallo,

bei uns wird es doch längerfristig zwei getrennte Seiten geben, die dann aber mit Single-Sign-On arbeiten sollen.

Für uns wäre eine Anmeldung im Contao wichtig, und dann eine "Weiterleitung" auf eine externe Seite, wo dann gleich der Login automatisch ausgeführt wird.

@Flex:
Was ist damit gemeint, dass Contao relativ einfach die Benutzer übernehmen kann?
Was erreiche ich mit User-Import.

Wichtig für uns ist die Richtung Login in Contao, dann Weiterleitung auf zweite Seite.

Gruß
Carsten

[Flex]

In Contao gibt es für genau diesen Fall zwei Hooks:

importUser greift, wenn der Benutzer aus dem Login nicht in Contao vorhanden ist und man kann dann den Benutzer in die Datenbank einfügen.

checkCredentials greift, wenn es den Benutzer gibt, das Passwort aber nicht stimmt.

Mit dem ersten importierst du den Benutzer und ignorierst das Passwort, der zweite Hook erlaubt es dir den Benutzer mit dem Passwort aus der anderen Datenbank abzugleichen.

[althoffc]

@flex:

So ganz habe ich das noch nicht ganz verstanden bzw. kann es auf unsere Sitation gedanklich noch nicht übertragen.

Wir haben in Contao Mitglieder eingepflegt. Die gleichen Mitglieder gibt es auch auf einer anderen (von einem anderen Vereinsmitglied selbst mit PHP gestrikten Homepage).

Die Usernamen sowie die Passwörter in Contao stimmen nicht mit den Usernamen/Passwörtern auf der anderen Homepage überein, auch wenn es sich um denselben User handelt.
Ein Mapping der User-IDs (Contao und externe Homepage) wäre durch Hinterlegen der externen User-ID in Contao möglich.

Durch ein iframe-Element habe ich testweise die externe Seite in die Contao-Webseite eingebunden. Jedoch ist ein expliziter Login erforderlich.

Meine Idee:

• User-ID aus externer Homepage in Contao als Mapping-Feld aufnehmen (eindeutige Zuordnung Contao-User zu User aus externer Homepage)
• Externe Seite über iframe in Contao-Seite einbinden (bereits erfolgt, jedoch zweiter Login noch erforderlich)
• Nach Login in Contao über externe User-ID den entsprechenden User der externen Homepage suchen und diesen als aktuellen User für die externe Homepage einstellen
• externe Homepage in die Contao-Session aufnehmen, so dass bei einem Contao-Logout auch der User aus der externen Homepage abgemeldet wird
• expliziter Login für externe Homepage entfällt. Login soll nur noch über Contao möglich sein

Wäre so etwas in der Art denkbar?

Gruß
Carsten

[soweit_ok]

Ich will damit flex Antwort nicht vorgreifen - aus meiner Sicht denke ich dazu, machbar wäre das sicher, doch der ganze Aufwand nur dafür, dass identische Benutzer verschiedene Passwörter in den Applikationen führen? Wo es doch zwei Hooks gibt, mit denen die Usertabellen direkt sychronisiert werden können. Da das Login des externen Scripts sowieso wegfallen soll, wäre es da nicht eigentlich logischer, dieses Passwort einfach mit dem Contao-Passwort zu überschreiben, statt irgendwas zu mappen. Oder habe ich da irgendwas nicht richtig verstanden?

Ansonsten ... soll das externe Script auf Dauer mittels IFrame eingebunden werden oder war das nur zum Testen und Du willst es per include() machen? Falls ersteres, macht dieses Script denn nur statische Ausgaben? Anderenfalls müsstest Du den Einbindungsbereichen der verschiedenen Scriptseiten entweder präventiv eine für alle Fälle ausreichende Höhe zuweisen. Was z. B. bei dynamischen Listenausgaben garnicht möglich wäre und mindestens den Nachteil hätte, dass Du auf den betroffenen Seiten darunter nicht nahtlos auch Contao-Inhaltselemente darstellen könntest. Der andere Punkt wäre, dass Du ja wohl bei einem komplexeren eingebundenen Script auch dessen Navigation per CSS ausblenden solltest und dafür sorgen, dass die Scriptnavi komplett von der Contao-Navi gesteuert wird - sofern vorhanden, auch parametrisiert. Sähe anderenfalls ja ein bisschen seltsam aus und erschiene den Seitenbesuchern inkonsistent.

Falls also per IFrame und evtl. vorstehende Anforderungen bestehen, hast Du sie denn bereits gelöst? Wenn nicht, kannst Du mich mal dezent danach fragen, wenn Du willst. ;-)

[althoffc]

@soweit_ok:
In beiden Systemen (Contao und extern) sind eigentlich die gleichen User erfasst, so dass eine Synchronisation der User im eigentlichen Sinne nicht erforderlich ist.
(Historisch bedingt sind alle User doppelt gepflegt; haben jedoch leider verschiedene Benutzernamen und Passwörter in den beiden Umgebungen.)

Im Idealfall werden die Login- bzw. Login-Daten nur in Contao geführt und der bisherige explizite Login für die externe Seite würde entfallen. Ein Login für beide Seiten erfolgt dann nur über den Contao-Login.
Bisher (und auch zukünftig) werden/sollen einige Ausgaben auf der externen Homepage user-bezogen dynamisch erzeugt und userbezogene Daten gespeichert.

Mir fehlen zu zwei grundlegenden Punkten noch ein guter Ansatz/Idee zur Herangehensweise:

• vorhandene userbezogene Daten (in der externen Datenbank) mit den Contao-Login-Daten korrekt ansprechen
  Idee: einmalig die userbezogenen Daten in der externen DB mit der Contao-User-ID versehen
• die externe Website in die bestehende Contao-Layout integrieren/anpassen
  Das mit dem iframe ist, wie Du schon beschrieben hast, bezgl. der Darstellung (Seitenhöhe) problematisch bzw. nicht zufriedenstellend.
  Wie würde das prinzipiell mit einem include gehen?

Ich habe leider mit PHP noch nicht so viel Erfahrungen gesammelt, so dass mir grundsätzliche Ideen/Vorgehenswiesen zu diesen Problemen nicht geläufig sind.

Gruß
Carsten

[soweit_ok]

Hi Carsten,

dann am besten mal eins nach dem anderen ...

Zunächst gehe ich davon aus, Dein einzubindendes externes Script befindet sich auf demselben Server oder könnte zumindest dort in einem Ordner bzw. Verzeichnisbaum unterhalb des Document Root platziert werden. Domainübergreifend ginge es per include() sowieso nicht und per iFrame auch nur eingeschränkt, weil die Browser-Sicherheitspolicies nicht alle für eine funktional vollwertige Integration nötigen Operationen über entfernte Server hinweg erlauben.

Was die Userdaten von Contao vs. Drittapplikation betrifft, gibt es keine "grundsätzliche" Vorgehensweise. Die genannten Hooks sind Funktionen, welche den Zugriff auf die benötigten Daten vereinfachen und im Fall der genannten können sie auch eine bidirektionale Synchronisation erledigen. Aber das ist nicht unbedingt von allzu großer Bedeutung, denn oft reicht das nicht aus. Man muss sich anschauen, was das einzubindende Script eigentlich mit den Userdaten verarbeitungstechnisch anfängt und ob die Formate kompatibel sind. Anderenfalls müssen sie kompatibel gemacht werden. Je nachdem, wie die Verarbeitung der Userdaten im externen Script erfolgt und ob die Formate passen, ist vielleicht auch garkeine redundante Speicherung der Userdaten nötig, sondern man könnte u. U. auch gleich direkt auf die Contao-Userinformationen zugreifen. Dafür wären freilich spezifische Anpassungen im Scriptcode nötig, doch ohne solche geht es eh auf keine Weise. Denn Login/Registrierung erfolgen schließlich nicht "einfach so", sondern sind Bestandteil der Ablauflogik. Ansonsten kommt es auch darauf an, in welchen Bereichen und wie bzw. in welchen Situationen die Loginaufforderung präsentiert werden soll. Manche Programme speichern in der Usertabelle auch neben den primären Benutzerinformationen weitere zugeordnete Daten. Einen Hinweis darauf gibt die Datensatzstruktur. In dem Fall müsste der Code des einzubindenden Scripts vollständig darauf überprüft werden, denn es ist ja nicht egal, wie auf die Tabellen zugegriffen wird. Man kann keine Redundanz beseitigen, die nicht vollständig aufgelöst werden kann. Auch dafür sind ggf. in irgendeiner Form Anpassungen nötig. Auch den Sessions und soweit gesetzt, Session-Cookies ist Aufmerksamkeit zu widmen. Soweit das Grobe dazu. Man muss es sich einfach im Code ansehen, eine pauschale Aussage ist nicht möglich. Je nach Anforderungen und tatsächlichen Gegebenheiten ist die Lösung des Problems im günstigen Fall recht einfach zu realisieren, es kann aber auch sehr aufwändig werden.

Zur Einbindungsaufgabe

include() ist eine PHP-Funktion, mit der eine im Paramter bezeichnete Datei eingebunden werden kann. Dasselbe kannst Du contaoseitig auch mit mittels Inserttag vom Typ "file" machen. Ganz allgemein schafft Contao mit den verschiedenen Inserttags eine erweiterte Flexibilität, die an vielen Stellen nützlich sein kann. Du kannst aber nicht einfach PHP-Code irgendwo im BE hinpflanzen. Das geht nur in den Templates. Allerdings sind Templates lediglich zur Datenübernahme von den verbundenen Modulen und HTML-Ausgabe im FE da. Für direkte Zugriffe auf die Datenbank oder auf Dateien sind die Templates aber nicht gedacht. Wo auch immer Inserttags platziert sind - sie werden von der Contao-Funktion replace_inserttag() aufgelöst. Du könntest also beliebig viele include()-Funktionsaufrufe in kleinen PHP-Dateien im Ordner /templates speichern und diese dann per Inserttag aus einem HTML-Modul im FE aufrufen. Der Speicher-Ordner ist im Grunde egal, aber nur in /templates ist es updatesicher.

Ein kleiner Test kann es ratzfatz klären - resultierende Probleme bei der Einbindung komplexer Scripte auf diese Weise müssen nicht, aber können sein:

1. CSS-Namenskonflikte wie z. B. gleichnamige Selektoren für unterschiedliche HTML-Elemente. Das CSS der meisten PHP-Applikationen einschl. Contao ist so aufgebaut, als seien sie allein auf der Welt. Bspw. haben sich Bezeichnungen wie #main, #header, #footer, #left, #right als Quasi-Standard eingebürgert und das kann dann so nicht bleiben. Die Anpassung kann wegen diverser Abhängigkeiten und Verknüpfungen recht aufwändig sein.
2. Abhängig von den vorhandenen CSS-Skills mögliche Verständnisprobleme beim Angleichen von Contao- und Script-Layout, z. B. wenn das eingebundene Script per Grid formatiert wurde und Contao per klassischem Container-Layout. Das kann bei Ungeübten vor allem dann für eine gewisse Verwirrung sorgen, wenn die Anwendungsbereiche/Unterseiten des Scripts auf verschiedene Contao-Seiten aufgeteilt werden sollen und die Scriptnavigation von der Contao-Navigation übernommen werden soll.
3. Doppelte CSS Id´s auf derselben Seite. Das ist nicht erlaubt und bewirkt einen Fehler, da in der HTML-Ausgabe die einbindende und die eingebundene Seite zu einer Gesamtseite zusammengefasst werden.
4. Doppelte Head-Sections im HTML-Code. Mit include kann nur der Body-Teil eingebunden werden. Man kann die zu entfernende Head-Section der eingebundenen Seite aber nicht einfach ersatzlos wegwerfen, sondern muss darin enthaltene nötige Teile konfliktfrei in den Aufrufer übernehmen und das geht logischerweise nicht per include(), sondern man muss das händisch anpassen.
5. Namens- und/ oder Verarbeitungskonflikte bei globalen Variablen
6. Mögliche Software-Bibliothekskonflikte, die einer Sonderbehandlung bedürften. Bspw. zwischen MooTools und Jquery.
7. Zum Schluss die gute Nachricht - Datenbankkonflikte sind sehr unwahrscheinlich, weil alle Contao-Tabellen mit einem Präfix versehen sind. :-)

Es geht also, kann aber ziemlich aufwändig sein und setzt ausreichende Sachkenntnis voraus.

Die Alternativen

Du hast recht, bereits die Einbindung statischer Inhalte ist mit diversen Nachteilen und Crossbrowser-Problemen behaftet. Dynamische Ausgaben in IFrames werden standardmäßig garnicht unterstützt. Du irrst aber mit der Annahme, die automatische Anpassung an dynamische Ausgaben sei deshalb nicht möglich und die sonstigen Nachteile ließen sich nicht aus der Welt schaffen. Kann ich Dir mit Sicherheit sagen, weil ich vor einiger Zeit ein Modul entwickelte, das die Einbindung beliebig komplexer externer Scripte automatisiert. Der einzige nicht änderbare Nachteil: Die Seiten sind nur mit dem Doctype transitional valide. Der wird allerdings von Contao ebenfalls unterstützt. Dazu dupliziert man am besten das Layout, wählt in der Kopie den Doctype transitional und weist diese Layoutkopie jeweils den Contao-Seiten mit Einbindungsbereichen zu. Damit kann man gut leben.

Alternativ geht auch die Einbindung per Object-Tag. Derzeit jedoch nur mit einigen Einschränkungen, die teilweise nur mit recht unschönen Hacks umgangen werden können. Kann das Modul ebenfalls, aber für diese Methode sind noch nicht alle Crossbrowserprobleme befriedigend gelöst.

Generelle Vorteile beider Methoden

Vollständige Kapselung von Scriptcode, CSS und verwendeten Bibliotheken. Daher u. a. nur geringer Aufwand mit Layoutanpassungen. Der Anwender muss nichts weiter tun, als ein Inserttag pro Einbindungsbereich auf der betreffenden Seite in ein Inhaltselement zu platzieren. Das ist an sich alles, für eine intelligente, perfekte Einbindung der Anwendungslogik eines komplexen Scripts ist allerdings noch etwas mehr nötig und ein gewisses Verständnis für das Zusammenwirken der beteiligten Elemente von Vorteil. Für die gesamte Steuerung ist keinerlei Anpassung des Scriptcodes erforderlich. Falls gewünscht lediglich zur Implementierung eines Datenaustausches zwischen Contao und eingebundenem Script, wie beispielsweise zur Realisierung Deiner Login-Anforderung.

Gegenüberstellung der Besonderheiten beider Einbindungsmethoden des Moduls

A. Einbindung per Object-Tag
Vorteile - Die Seiten sind auch bei Doctype Strict valide. Diverse Datentypen möglich - neben PHP-Scripten z. B. auch Java-Applets, Flash, Bilder oder Dokumentdateien. Wird spätestens mit endgültiger Ablösung des IFrame-Tags wahrscheinlich besser unterstützt.
Nachteile - In allen Browsern noch immer unzureichend unterstützt, daher verschiedene mit teils nicht sehr sauberen Workarounds zu umgehende generelle Darstellungs- und Crossbrowser-Probleme.

B. Einbindung per IFrame-Tag
Vorteile - Erheblich bessere Browserunterstützung
Nachteile - Wird möglicherweise irgendwann in Zukunft als deprecated eingestuft. Das kann aber evtl. auch noch Jahre dauern bis dahin. Die Seiten sind nur mit Doctype transitional valide (wird allerdings ebenfalls von Contao unterstützt).

C. Gegenüber dem Standard erweiterterte Features beider Methoden
1. Eventgesteuerte automatische Höhenanpassung des Einbindungsbereichs an dynamische Inhalte wie z. B. Ausgabe generierter Listen.
2. Manipulation sämtlicher Attibute und Werte, sowohl der W3C-standardisierten wie auch der proprietären.
3. Bedingt auch Generierung standardmäßig nicht vorhandener Attribute.
4. Beseitigung aller Crossbrowser-Probleme.
5. Ausblendung der Scriptnavigation und Übernahme durch die Contao-Navigation. Auch parametrisierte Requests möglich.
6. Verteilung der Scriptseiten und Applikationsbereiche auf beliebige Contao-Seiten und -positionen.
7. Vollständige Integration der Einbindungsbereiche ins Contao-Layout ohne störende Scrollbars und mit nahtlosem Anschluss von Contao-Inhaltselementen und -Modulen.
8. Datenaustausch zwischen Contao und eingebundenen Scripten.
9. Fallback bei abgeschaltetem Javascript

-----------------------

Deine Frage klang so, dass Du eine Lösung dieses Problems am liebsten selbst raustüfteln willst. Ja, ist auch meine Erfahrung, dass man so auf Dauer am weitesten kommt. Zusammenfassend kann ich Dir etwa folgende Strategie empfehlen ...

Eine ungekapselte Einbindung komplexer Third Party Scripte verursacht meistens unverhältnismäßig hohe Aufwände. Ich würde es mal kurz testen und sollte es total zerschossen ausschauen, auf der Stelle vergessen. Es gibt aber die beschriebenen, sehr gut funktionierenden anderen Lösungsmöglichkeiten, auch wenn das CMS kein Interface für solche Anforderungen anbietet. Du musst dafür garnicht megagut PHP und Javascript beherrschen, mach Dir da mal keine Sorgen. Kenntnis der grundlegenden Sprachelemente und wie Variableninhalte zwischen PHP und JS ausgetauscht werden, reicht. Daneben brauchts noch Verständnis, wie Client/Server-Kommunikation funktioniert und in dem Zusammenhang auch, was man tun kann, überflüssige Requests zu vermeiden. Ansonsten DOM komplett.

Ich hoffe, der kleine Fahrplan hilft etwas.

HG Andreas

[althoffc]

Hallo Andreas,

erst mal super danke für Deine ausführlichen Erläuterungen.
Ich denke, dass ich mit Deinen Ausführungen und den darin erwähnten Aspekten mir schon mal ein besseres Bild zu einem möglichen Fahrplan machen kann. (Contao und externe Skript liegen auf gleichem Server; dass externe Skript kann auch unterhalb des Document Root verschoben werden.)

Habe mit einem IFrame das externe Skript eingebunden. Dazu habe ich im Contao ein eigenes Seitenlayout erstellt, in welchem ich den Main-Bereich "maximiert" habe, um dort das externe Skript bzw. dessen Inhalte anzuzeigen.
Das Layout ist soweit ok (habe bisher keine Abweichungen festgestellt). Funktional ist auch alles im Lot. Das Skript-Eigene Navi-Menü ist aktiv, das von Contao in dem Seitenlayout entfernt. (Durch einen Link im Kopfbereich kann man aber nach Contao zurück.)

Offene Punkte:

• externes Skript soll ausschließlich über eine Contao-Seite/Link im geschützten Mitgliederbereich erreichbar sein (ein Aufruf des externen Skriptes unter Umgehung eines Contao-Logins soll nicht möglich sein)
• entfernen des expliziten Logins für das Skript
• Benutzername (besser: Benutzer-ID) des eingeloggten Contao-Users an das Skript übergeben, damit benutzerbezogene Daten angezeigt/verarbeitet werden können
• externe DB-Tabellen können in Contao-DB aufgenommen werden (würde hier einen eigenen Präfix für Tabellennamen einsetzen)
• Angleichen der Benutzer-ID in "externer" Datenbank an Contao-Benutzer-ID (in allen Tabellen mit benutzerbezogenen Daten)
• Lösung zur Steuerung der Anzeigehöhe für dynamische Inhalte

So eine Lösung würde mittelfristig reichen. Bis dann iframe nicht mehr unterstützt wird, fließt noch viel Wasser den Rhein herunter ...

Ich werde die Punkte mal angehen und hier berichten.

Danke bis hierher für Deine Hilfe.

Gruß
Carsten

[soweit_ok]

Hallo Carsten,

na ja, so wie Du das Script jetzt abweichend von meiner Empfehlung einbindest, ist es die unflexibelste Form der Möglichkeiten. Vermutlich erschien es Dir als der bequemste Weg, aber es ist der falsche. Weil Du eben nicht die Scriptnavigation ausblendest, um die Navi mit Contao zu übernehmen, sondern genau umgekehrt die Einbindung nur in einem einzigen IFrame machst. In einem leeren Layout ohne Contao-Navi.

Ich schrieb Dir nicht ohne Grund, mach Dir zu Anfang erstmal die Möglichkeiten des Zusammenwirkens der verschiedenen Komponenten klar und leite dann daraus das bestmögliche Konzept ab. So wie jetzt gehen Dir jegliche strukturelle Bezugspunkte zu Contao verloren und Dein "Zurück"-Link ist dafür einfach nur eine schwache Notlösung, sorry. Und Du kannst auch nicht das Nötige für SEO tun, weil das eingebundene Script nicht über Contao gesteuert wird und die Suchmaschinen-Bots so nicht folgen können.

Lies Dir am besten nochmal den kleinen "Fahrplan" von gestern richtig durch, da steht alles drin. Auch wenn Du vielleicht alles Enthaltene umsetzen willst, es ist die strategisch korrekte Vorgehensweise und Du könntest dann sukzessive alle Features einbauen, die Du für nötig hältst. Richtig wäre, eine Seitenstruktur in Contao anzulegen, welche die Scriptseiten und ggf. sonstige logische Bereiche des Scripts widerspiegelt. Diese Seitenstruktur findet sich ja dann auch automatisch in der Contao-Navi und den URLs wieder und die Suchmaschinen wie Google können alles indizieren. Stattdessen turnen so die Seitenbesucher irgendwo in den Untiefen des Scripts herum, die URL bleibt währenddessen immer dieselbe, nämlich die der Aufruferseite und die Navi ist völlig losgelöst. Besucher wissen nicht, wo sie eigentlich sind, Suchmaschinen folgen nicht, und Browser-Reload oder Browser-Backbutton führen zu unerwarteten Reaktionen. Wie beim "Mensch-ärgere-Dich-nicht-Spiel" - alles zurück auf Anfang. Und wenn Du weiterdenkst, so kannst Du auch keine sinnvolle Datenkommunikation zwischen Script und Contao implementieren.

Um den Nachbau der Scriptstruktur in Contao zu machen, deklarierst die zugehörigen IFrames natürlich nicht direkt in Contao, sondern in einem Modul, das Du im Ordner /templates speicherst. Dieses Modul wertet die GET-Parameter aus, die Du contaoseitig mittels Inserttag vom Typ "file" übergeben hast. Zur Veranschaulichung ein kleiner Codeauszug aus meinem Einbindungsmodul mit der beispielhaften Wertzuweisung an die IFrame-Attribute "name", "scrolling" und "src". Schau Dir dazu noch in der Contao-Doku Syntax und Funktionsweise des file-Inserttags an, dann weißt Du Bescheid ...

echo ......   'name="'.$_GET['id'].'"'.' scrolling="'.$_GET['scroll'].'" src="'.$_GET['path']. ............

Außer der Parameterauswertung codierst Du in dem Modul auch alle Features, die Du der Einbindungsmethode geben willst (siehe gestrige Liste). Im einfachsten Fall wäre das einfach nur die in das HTML-Tag integrierte Wertzuweisung an die Standard-IFrame-Attribute, wie als Mini-Beispiel in dem Sniplet. Du kannst aber auch dynamische Einbindung mittels DOM inkl. vollständiger Crossbrowser-Kompatibilität und weitere Einbindungsmethoden per Object-Tag oder include() in das Modul einbauen.

Aber so weit musst Du es ja garnicht treiben. Entscheidend ist bloß, dass Du über Inserttags und ein Parameterverarbeitungsmodul eine ganze Struktur mit einer einzigen Routine aufbauen kannst. Alternativ könntest Du natürlich ebensogut für jeden Aufruf einen Iframe in HTML-Inhaltselementen auf den Seiten platzieren. Aber das wäre zum einen etwas umständlich und Du hättest dann auch nicht die Möglichkeit, dem Ganzen zusätzliche Features zu verpassen. Deshalb empfahl ich Dir einen dafür passenden flexiblen Weg.

Um der eventuellen Frage vorzubeugen ... nein, ich poste den Modulcode momentan nicht im Forum. Falls ich demnächst die Zeit finde, noch die weiteren dafür nötigen Arbeiten zu erledigen inkl. Testen für 2.10, veröffentliche ich es vielleicht als Contao-Extension.

Soweit jedenfalls erstmal zu einer SEO- und besucherfreundlichen Form.

HG Andreas

[andreasisaak]

Um der eventuellen Frage vorzubeugen ... nein, ich poste den Modulcode momentan nicht im Forum. Falls ich demnächst die Zeit finde, noch die weiteren dafür nötigen Arbeiten zu erledigen inkl. Testen für 2.10, veröffentliche ich es vielleicht als Contao-Extension.

Wenn du sie veröffentlichst, dann verwendest du hoffentlich nicht $_GET in der Extension

[soweit_ok]

Wenn du sie veröffentlichst, dann verwendest du hoffentlich nicht $_GET in der Extension

Nee, natürlich nicht. Dann entfällt auch die Verwendung von Inserttags und es gibt stattdessen ein Formular, in das der Anwender die Vorgaben einträgt/auswählt.

[althoffc]

Hallo Andreas,

Du hast recht. Werde meine Vorgehensweise noch mal komplett überdenken und mich an dem Fahrplan orientieren.
Werde aber in den nächsten Tagen nicht daran weitermachen können, da nur bedingt/keine Zeit.

Gruß
Carsten

[althoffc]

Hallo,

konnte jetzt für einige Wochen gar nicht an meinem Problem weiterarbeiten. Werde das Thema aber bald angehen können und hier über die sich hoffentlich einstellenden Fortschritte berichten.

Gruß
Carsten

[althoffc]

Hallo,

@soweit_ok:

Ich habe mir das alles noch mal durch den Kopf gehen lassen.

• Ich möchte die externen PHP-Skripte ins Contao integrieren und dazu den PHP-Include bzw. das Insert-Tag {{file::*.php}} verwenden. Die grundsätzlichen Funktionalitäten sollen erhalten, aber an das Contao-Umfeld angepasst werden.
• Eine Lösung über iFrames möchte ich nicht mehr angehen, sondern dann über die angesprochenen Objects-Tags gehen.
• Die bisherige Navigation der externen PHP-Skripte möchte ich über eine entsprechende Seitenstruktur in Contao umsetzen. Diese Navigation ist dann ausschließlich für angemeldete Mitglieder im geschützten Bereich erreichbar. (Login allein über Contao; keine weitere Zugriffskontrolle erforderlich.)
• Die externen Datenbanktabellen möchte ich in die Contao-Datenbank aufnehmen. Die User werden allein in den Contao-Tabellen (tl_member) gepflegt. (Einmaliger Datenabgleich).
• Die externen PHP-Skripte erzeugen zwar dynamische, aber von der Struktur/Aufbau her rechte einfache HTML-Ausgaben; überwiegend tabellarische Listen und einfache Formulare zur Datenerfassung und Änderung.

Das als grobe Richtung.

Was ich bisher gemacht habe:

• Erstellen einer Seitenstruktur, die der ursprünglichen Navigation der externen Website entspricht.
• Beispielhaft für einzelne dieser Seiten das entsprechende externe PHP-Skript über das Insert-Tag "FILE" eingebunden. Ausgabe des PHP-Skriptes erfolgt in dem bestehendem Contao-Layout.
• Ein paar grundlegende Geh-Versuche mit PHP im Zusammenhang mit MySQL und Contao.

Mir ist es noch nicht gelungen, in dem mit {{file::*}} eingebundenen PHP-Skript den eingeloggten Contao-User zu ermitteln. Dazu muss ich doch wahrscheinlich die Contao-Objekte ansprechen.

Mir ist aber nicht klar, wie ich das konkret machen kann.
Es müsste doch so etwas wie "object->contao_user->get_username()" geben, mit dem ich auf Datenelemente eines eingeloggten Contao-Benutzers zugreifen kann.

Ich vermute, dass hierzu das Object-Tag ins Spiel kommt.

Kann mir hierzu jemand Tipps geben?

Danke und Gruß
Carsten

[soweit_ok]

Ich verstehe das Problem nicht. Wenn Du bereits die verschiedenen Programmteile des ext. Scripts verteilt über Inserttags erfolgreich eingebunden hast und nun alles über die Contao-Navi steuerst, dann brauchst Du doch jetzt nur noch die Seiten in der Seitenstruktur schützen, der/den entsprechenden Gruppe(n) zuweisen, das Login-Modul auf einer Vorschaltseite einbinden und fertig.

Falls ich das nicht überlas, geht jedenfalls aus Deinen Anforderungen nicht hervor, wozu Du dafür ermitteln musst, welches Mitglied angemeldet ist.

[althoffc]

Hallo soweit,

die Seiten zu schützen ist der eine Punkt. Damit kann ich die Erreichbarkeit der eingebundenen PHP-Skripte auf bestimmte Mitgliedergruppen einschränken. Das funktioniert auch wie gewünscht.

Ein zweiter Aspekt ist, das ich aus der zweiten Datenbank bzw. Tabellen, welche von den externen PHP-Skripten genutzt werden, benutzerbezogenen Daten auslesen muss. Dazu benötige ich die Infos über den aktuell im Frontend angemeldeten User (Mitglied).

Gruß
Carsten


PS: Sorry, dass meine Antworten zur Zeit so lange dauern. Habe viele verschiedene Dinge um die Ohren.