Sind Overrides des Backends möglich?

    Um den "Seminarmanager" (der erst kürzlich von der deutschen "OSG GmbH" an die Schweizer "Webtribute GmbH" übergeben wurde) an spezielle Kundenwünsche anzupassen, zu erweitern und flexibler zu gestalten, die im Wesentlichen das Backend betreffen ( Zusatzfunktionen und Tabellenerweiterungen für Kurse und Buchungen), möchte ich Overrides im Backend (ISIS) erstellen.

    Ein kleiner Teil der für das Backend verantwortlichen Dateien wird unter Template ISIS zum overriden angeboten. Da aber nicht nur das Aussehen angepasst werden soll, sondern auch etliche Funktionen hinzugebaut oder geändert werden sollen, müsste ich auch an Dateien heran, die nicht von vornherein als Override-Dateien angeboten werden.


    Entscheidet eigentlich der Entwickler, was overridet werden können soll, oder macht das Joomla automatisch?


    Mein im Unfrieden ausgeschiedener Vorgänger hatte sich vor etlichen Jahren ein richtig komfortables Backend ausgedacht. Das war wohl zugleich sein Hobby oder Baby. Aber dazu hat er leider gnadenlos in 29 verschiedene Coredateien eingegriffen - natürlich ohne die Stellen mit geändertem Code zu kennzeichnen und schnell auffindbar zu machen. Er hat sie in den Dateien gar nicht gekennzeichnet. Dass er Veränderungen vorgenommen hat, erkenne ich daran, dass er sich wenigstens konsequent daran gehalten hat, zusätzlich zur jeweils geänderten Coredatei eine gleichnamige "orig"- und eine "angepasst"- Datei erstellt und in den Verzeichnissen abgelegt hat.


    Natürlich können diese angepassten Coredateien der Version 2 nach 3 Jahren ohne Update nicht einfach wieder an die Stelle der demnächst neuen Dateien der Seminarmanager-Version 4 gesetzt werden. Dafür wird sich viel zu viel im Code geändert haben.

    Ich will von dem ganzen Coregedöns komplett weg und nur noch das anpassen, was sich mittels Overrides anpassen lässt. Bei allem anderen muss die Geschäftsstelle dann in Zukunft auf so manche Komfortfunktion verzichten und sich mit dem Standard zufrieden geben. Das wird dann zwar etwas weniger elegant und vielleicht etwas umständlicher, aber dafür sind dann wieder regelmäßige Standard-Updates möglich.

    Überschrieben soll im Idealfall im Template nur der View werden (die Ausgabe ohne oder fast ohne eigene Logik), auch wenn hier viel nachholen kann.


    Alle Templates in Joomla können Overrides haben, auch Backend Templates wie das Isis.


    Anzuraten ist, sich erst eine Kopie des Templates zu erzeugen, um Aktualisierungen am Template auf eigenen Änderungen zu vermeiden.


    Joomla macht das Überschreiben von Komponenten- und Modul-Layouts ("Templates") automatisch


    Mit requires_once können auch in Joomla PHP Dateien jeder Art hart überschrieben werden, was bei Aktualisierungin diese Dateien natürlich zu Probleme führen wird.

    Zum Thema eigen Funktionen und Kram.


    Zumindest der alte Seminarmanager 2 hatte viele eigene Plugin-Events dabei. Findet man im Code an Stellen, die alle so oder so ähnlich aussehen:

    Code
    $dispatcher=JDispatcher::getInstance();
JPluginHelper::importPlugin('seminarman');
$extData = $dispatcher->trigger('onGenerateSPEmail', array(array($queryResult->course_id, $msgSubject, $msgBody, $queryResult->attendees)));

    Es werden also Events/Methoden in Plugins der Plugin-Gruppe "seminarman" aufgerufen. Im obigen Beispiel Methode

    Code
    onGenerateSPEmail

    Kannst also schon mal eigene Plugins verwenden.


    Es sollte aber auch funktionieren, ein eigenes Joomla-System-Plugin zu verwenden, in dem die Methoden enthalten sind. Im Normalfall werden die dann auch durch obige Zeilen aufgerufen.


    Aber, ich weiß natürlich nicht, ob was dabei ist, was dir direkt hilft. Oft, wie z.B. bei JoomShop, das auch jede Menge so eigene Trigger drin hat, muss man noch einiges an HirnSchmalz aufbringen, in Controllern und Models rumwühlen, wenn man echt erweitern will, weil bestimmte Daten, auf die man eigentlich aus ist, gar nicht ans Plugin geschickt werden...


    Meist ende ich in einem mehr oder weniger wüsten Konglomerat aus eigenem Plugin, Overrides, JavaScript mit AJAX (was ja dann auch via Plugin "verwaltet" werden kann). Aber wenigstens updatefähig ;) Vom Grundprinzip her ;) Wenn der Erweiterungs-Core sich deutlich ändert, muss man leider trotzdem nacharbeiten und -korrigieren.


    Jedenfalls sollte man vorher abreißen, was "Kunde" eigentlich wirklich dringend benötigt und nichts vorschlagen, was "Kunde" vielleicht haben können wollte. Erfahrungswert ;)

    Hallo Re:Later,


    vielen Dank für Deine Tipps!


    Im Gegensatz zu Dir bin ich kein Profi in Sachen "eigene Scripte / eigene Plugins" schreiben. Meine PHP-Kenntnisse reichen nur dazu, bestehende Scripte zu analysieren, abzuändern und in beschränktem Maß zu erweitern. Aber flüssig codieren kann ich nicht.


    Demnächst soll ja die Version 4 erscheinen. Für diese hatte bereits die OSG-GmbH (möge sie irgendwer selig haben) erhebliche Erweiterungen angekündigt, nachdem sie jahrelang meine Kundenwünsche hinsichtlich grundsätzlicher/allgemeiner Flexibilisierung ignoriert hat. Dafür kam immer wieder der Hinweis, dass sie natürlich jederzeit gern spezielle Kundenprogrammierungen durchführen. Genau das hat mein Vorgänger, der vor etlichen Jahren mit großem Engagement daran gegangen war, offenbar in Anspruch genommen - aber weil ihn dann vermutlich die Kosten abgeschreckt hatten, wurden 3 Jahre lang keine Updates mehr vorgenommen. Die hätten ja auch immer wieder von OSG-GmbH individuell angepasst werden müssen.


    Ich bin wirklich gespannt, wie die Schweizer Webtribute GmbH jetzt mit dem Seminarmanager umgehen wird und will abwarten, was sie in Version 4 bereits standardmäßig integriert. Schon der Sprung von V2 auf V3 brachte so viele Codeänderungen mit sich, dass ich die (für V2 geschriebenen) geänderten Kerndateien nicht mehr ohne erhebliche Nacharbeit - inklusive aufwendiger detektivischer Suche nach den geänderten Zeilen - weiternutzen könnte. Einiges, was unter V2 noch mit Plugins gamacht wurde, ist ja schon in V3 bereits in der Komponente enthalten.

    Etwas Ähnliches (bzw. noch deutlich mehr Codeänderungen) erwarte ich jetzt für V4.


    Mit dem Kunden bin ich bereits im Gespräch in Sachen "back to the roots", d. h. weitgehend zurück zu den Standardfunktionen. Dafür ist er durchaus aufgeschlossen. Vielleicht lässt sich das seit 3 Jahren bestehende "Updateverhinderungsproblem" ja durch die Kombination von beidem (V4 in Tateinheit mit Verzicht auf etwas Komfort - bzw. mit etwas mehr manueller Arbeit beim Verwalten und Verbuchen) lösen.


    Nebenbei eine Frage - wenn ich darf: Seit ich die Betreuung übernommen habe, attackiert irgendein unfreundlicher Mensch (ich vermute kein Bot) regelmäßig die betroffene Webseite und dort den Seminarmanager. Kannst Du ganz grob erkennen, was damit wohl bezweckt werden soll? Solche bzw. sehr ähnliche Attacken hatte ich in den letzten 2 Wochen mehrere hundert Mal. Glücklicherweise ist da die RSFirewall sehr aufmerksam.


    https://www.#######/component/seminarman/day/2020/06/20.html?Itemid=623&ccid=242+and+1%3d(%2f**%2f%2f**%2fsElEcT+1+%2f**%2f%2f**%2ffRoM(%2f**%2f%2f**%2fsElEcT+count(*)%2c%2f**%2f%2f**%2fcOnCaT((%2f**%2f%2f**%2fsElEcT+(%2f**%2f%2f**%2fsElEcT+%2f**%2f%2f**%2fuNhEx(%2f**%2f%2f**%2fhEx(%2f**%2f%2f**%2fcOnCaT(0x7e%2c0x413936313543373834333044%2c0x7e))))+%2f**%2f%2f**%2ffRoM+information_schema.%2f**%2f%2f**%2ftAbLeS+%2f**%2f%2f**%2flImIt+0%2c1)%2cfloor(rand(0)*2))x+%2f**%2f%2f**%2ffRoM+information_schema.%2f**%2f%2f**%2ftAbLeS+group+by+x)a)+and+1%3d1-- Kein Referer Versuch der Einbindung einer lokalen Datei!

    Debug-Informationen

    URI: Itemid=623&ccid=242 and 1=(/**//**/sElEcT 1 /**//**/fRoM(/**//**/sElEcT count(*),/**//**/cOnCaT((/**//**/sElEcT (/**//**/sElEcT /**//**/uNhEx(/**//**/hEx(/**//**/cOnCaT(0x7e,0x413936313543373834333044,0x7e)))) /**//**/fRoM information_schema./**//**/tAbLeS /**//**/lImIt 0,1),floor(rand(0)*2))x /**//**/fRoM information_schema./**//**/tAbLeS group by x)a) and 1=1--
    Übereinstimmung: ./

    Ich betreue ungefähr 20 Webseiten. Deren RSFirewalls melden mir zuverlässig alle gemeinen Versuche per Email. Ja, 99,x% davon kommen von Bots. Das sind die sog. "Gießkannenangriffe". Meist sind dann in zeitlich engem Zusammenhang praktisch alle Webseiten davon betroffen. Die in der Sache gleichen Angriffe kommen von unterschiedlichen IP-Adressen und sind unspezifisch bzw. versuchen, ins Backend einzudringen (mit äußerst primitiven Passwörtern).


    Hier in diesem Fall aber ist das anders: 1.) wird die Injektion immer im Zusammenhang mit dem Seminarmanager versucht. 2.) Ist genau dieser Seminarmanager die vulnerabelste Erweiterung in dieser Webseite, weil sie seit 3 Jahren nicht upgedatet wurde. 3.) Kommen die Angriffe blockweise immer von derselben IP. 4.) Zur Zeit ist keine meiner anderen Webseiten von diesem speziellen Angriff - oder überhaupt so massiv - bedroht. Eigentlich ist allgemein betrachtet z. Z. sogar ziemliche Ruhe an der Hackerfront.


    Mein Verdacht: Jemand, der intime Kenntnis davon hat, was mit dem hier speziell programmierten Seminarmanager los ist, versucht, den Betreibern bzw. mir als neuem Dienstleister, Knüppel zwischen die Beine zu werfen. Vielleicht weil er verärgert ist, denn in diesem Zusammenhang wurden im Lauf des letzten Jahres mehrere Verträge im Bereich der IT gekündigt und ein Verantwortlicher beim Betreiber - nicht einvernehmlich - "ausgeschieden". Im Gegensatz zu meinen anderen Installationen/Kunden, kann ich mir vorstellen, dass es da möglicherweise "Böses Blut" gibt.


    Übrigens hat die RSFirewall (seit vielen Jahren) eine beruhigende Wirkung auf mich - nachdem ich im ersten Jahr natürlich auch immer erschrocken war. Aber man gewöhnt sich daran. Aber so sehe ich zuverlässig, ob eine der Webseiten zur Zeit besonders auf dem Kieker von irgendwem ist oder ob er nur im ganzen Internet "herumfuhrwerkt" - und vor allem sehe ich, ob die Eindringversuche ins Backend Kinderkacke oder ernstzunehmen sind - z. B. weil die Passwortversuche recht nahe an der Realität dran sind. Letzteres ist aber in den letzten 8 Jahren nur zweimal passiert. In solchen Fällen mache ich den Kunden darauf aufmerksam. Einer der beiden hatte tatsächlich eine plausible Erklärung dafür, denn er wurde zeitgleich auch in der realen Welt von einem unliebsamen Zeitgenossen "genötigt".


    Früher wollte ich es nie wahrhaben, aber seit der Beschäftigung mit Web & Co ist mir klar: "Der Mensch ist durch und durch böse! Und wenn er das mal nicht ist, dann nur deshalb, weil er sich nicht traut, böse zu sein. Dann setzt er sich die Maske des Guten auf."

    Ja, ich stehe zu meiner Paranoia, denn in einer vom Wahnsinn regierten Welt ist gesunde Paranoia überlebenswichtig. Paranoia hilft mir, nie nachlässig zu reagieren - eher übervorsichtig. Aber damit bin ich bisher gut gefahren.

    Zitat von Elwood

    Denn der Seminarmanager ist ja aktuell

    Man muss dazu wissen, dass der Seminarmanager ab Version 3 kostenpflichtig wurde. Daher dümpeln noch einige 2-er im Netz. (Unabhängig von der Tatsache, dass TE noch dazu eine bereits gehackte Version verwendet, so nenne ich das zumindest, die nicht geupdatet werden kann/darf/whatever.).


    Sicherheits-Updates gab es auch für den SM in den letzten x Jahren immer mal.


    Es ist stocksimpel für einen Hacker-Bot zu ermitteln, ob Seminarmanger überhaupt installiert ist bzw. auf eine harmlose Anfrage "reagiert". Wenn ja und wenn irgendwelche Vulnerabilitäten bekannt sind, egal, ob lange im Core gefixt, ballert man halt erweiterungsspezifisch weiter. Mal sofort, mal etwas später, mal forciert, mal dezent. Andere Bots ballern nur auf gut Glück vor sich hin.


    Da hilft dann nur ein intensives Studium der Server-Access-Logs, die natürlich ausreichend vorliegen müssen, um die Linie des/der Bots zu erforschen.

    Wie schon gesagt: Der SM ist nicht aktuell 2.13.5. Man konnte die auch schon als kostenpflichtige "Pro"-Version erhalten, und für diesen umfassenden Hack (in 29 PHP-, 2 CSS- und 2 XML-Dateien) wird der Kunde damals sicher ein Heidengeld bezahlt haben.

    *****************

    Ich finde, die detaillierten Systemprotokolle der RSFirewall sind da schon sehr aussagekräftig.

    Na, dann lass' ich ihn mal weiterballern und schau mal, was noch so alles passiert. Nervös würde ich dann werden, wenn die Firewall das Etikett "Kritisch" davorsetzt ... hmm

    Zitat von Sieger66

    Meiner Meinung nach ist derlei vor allem Schlangenöl siehe z.B. auch:


    https://www.joomla.de/wissen/j…1x1-der-joomla-sicherheit

    Mag sein. Aber so wie ich davon überzeugt bin, dass auch der sog. Placeboeffekt eine echte selbstheilende Wirkung auslöst - wenn man an ihn glaubt, so nutze ich auch das "Schlangenöl" namens "Norton Security" seit schätzungsweise etwa 20 Jahren auf allen Rechnern und die RSFirewall auf allen Webseiten. Und da, wo sie nicht integrierbar ist, also Nicht-Joomla und Nicht-WP, weiche ich auf die Standalone-Firewall Ninjaproplus (Nintech) aus.

    Hier in meinem Homeoffice bin ich gerade dabei, den nächsten Schritt zu gehen und arbeite mich in eine "Next-Gen-Hardware-Firewall" von Lancom ein. Ich war immer schon ein Bekloppter und zugleich Sicherheitsfanatiker und stehe dazu.


    Es kann ja sein, dass mir und meinen Webseiten auch ohne den ganzen Krempel in den 20 Jahren nichts Böses passiert wäre. Da ich das aber nicht wissen kann, halte ich mich an die zugegeben wirklich primitive Regel "Was miteinander korreliert, hat oft auch einen Kausalzusammenhang - zumindest aber einen sinngemäßen." Also: Sicherheitssysteme installiert => Nix is passiert die ganze Zeit => Sicherheitsmechanismen funzen! Und da - mal abgesehen von meinem neuesten Ausflug in die Welt der hochsicheren Hardware-Firewalls - weder Norton Security noch RSFirewall mich bisher ernsthaft arm gemacht haben, bleibe ich dabei. an irgendetwas MUSS man doch glauben, wenn man schon den Weltreligionen abgeschworen hat ...


    Ich schätze ja bereits den Aufmerksamkeitseffekt, den die Firewalls mit ihren Emailbenachrichtigungen bei mir auslösen. Sie lassen mich wachsam bleiben.

    Hier ein Gegenbeispiel: Jahrelang hatte ich eine Gesellschaft mit ihrer Joomla-Webseite betreut. Nichts Böses ist passiert. Dann hat sich der Kunde von WP begeistern lassen und ich bin (auf meine alten Tage) sofort ausgestiegen. Noch ein CMS tu' ich mir mit 70 nicht mehr an, denn mit 80 werde ich mich wohl zur Ruhe setzen. Da lohnt sich der Aufwand nicht mehr. Also hat eine andere Agentur den Auftrag bekommen, die wohl auch eher vom Schlangenöl überzeugt war.

    Aber es hat nicht lange gedauert, und der Webprovider machte den Kunden zweimal innerhalb weniger Monate darauf aufmerksam, dass sich kritische Dateien auf dem Webspace befinden, die schnellstens entfernt werden müssen. Solche Nachrichten kannte ich bis dahin gar nicht. Also ist mein Credo: Schlangenöl hin, Schlangenöl her: Hauptsache schön glitschig und flutschig! (Hab' ich in jüngeren Jahren mal beim Tantra gelernt vain.)

    Zitat von Re:Later

    Man muss dazu wissen, dass der Seminarmanager ab Version 3 kostenpflichtig wurde. Daher dümpeln noch einige 2-er im Netz. (Unabhängig von der Tatsache, dass TE noch dazu eine bereits gehackte Version verwendet, so nenne ich das zumindest, die nicht geupdatet werden kann/darf/whatever.).


    Dann kann ich es nachvollziehen:


    Zitat von Kallle

    Nein, es ist dort noch die 2.13.5. von März 2018.