Druckbare Version
ich habe heute bei einem Projekt, die atuelle 3.3er Version getestet.
Leider gehen seit dem keine Ajaxrequests mehr, die über das ajax plugin von Andreas Schempp liefen, kann das eventuell jemand bestätigen oder weiss abhilfe.
Ich weiss das etwas an den Klassen geändert wurde, laut Fehlermeldung gibt es ein Problem mit \contao\controller::frontendmodule wenn ich es richtig im Kopf habe
in der Fehlermeldung stand etwas von Fatal error: Cannot make static method
Hallo,
ich stehe nach einem update auf die 3.3.3 vor dem selben Problem mit der selben Fehlermeldung.
Wurde schon eine Lösung gefunden?
Danke
Timon
Von meiner Seite aus nicht, ich bin mit dem Projekt wegen dieses Problems bei der 3.2er geblieben.
Updates sind ja etwas schönes aber bei der Menge an Änderungen die neuerdings mit jeder Version kommen, kommt doch keiner mehr hinterher,
wer hat da schon lust, seine Plugins jedesmal neu in die Hand zu nehmen.
Es ist schon schlimm genug, dass man in der heutigen Zeit noch immer, externe Module benötigt um Ajax Abfragen zu machen.
Kann ich bestätigen, funktioniert auch bei mir nicht mehr.. :(
Offensichtlich wurde da etwas geändert.
Ich würde das mal auf Github reporten: https://github.com/aschempp/contao-ajax/issues
Es hat nicht den Anschein, dass dort noch etwas passiert
https://github.com/aschempp/contao-ajax/issues/13
Wenn ich mir die vorhandenen Hooks für Ajax anschaue, dann sieht es für mich nicht so aus, als ob diese im Frontend nutzbar sind, Meine Tests sagen auch das es nicht geht und Sie nicht angesprochen werden.
Ich hab die Methode getFrontendModule einmal für meine Zwecke umgebaut und an die Version 3.3.3 angepasst... Hoffe es ist nicht zu sehr Dirty Programming.
Funktioniert so aber bei mir...
Die Änderungen:
Und aufgerufen wir sie dann oben (Zeile 177 bei mir) anstelle vonPHP-Code:public static function getFrontendModule($intId, $strColumn='main')
{
if (!strlen($intId) || $intId < 1)
{
header('HTTP/1.1 412 Precondition Failed');
return 'Missing frontend module ID';
}
$objModule = \Database::getInstance()->prepare("SELECT * FROM tl_module WHERE id=?")
->limit(1)
->execute($intId);
if ($objModule->numRows < 1)
{
header('HTTP/1.1 404 Not Found');
return 'Frontend module not found';
}
// Show to guests only
if ($objModule->guests && FE_USER_LOGGED_IN && !BE_USER_LOGGED_IN && !$objModule->protected)
{
header('HTTP/1.1 403 Forbidden');
return 'Forbidden';
}
// Protected element
if (!BE_USER_LOGGED_IN && $objModule->protected)
{
if (!FE_USER_LOGGED_IN)
{
header('HTTP/1.1 403 Forbidden');
return 'Forbidden';
}
$user = \FrontendUser::getInstance();
$groups = deserialize($objModule->groups);
if (!is_array($groups) || count($groups) < 1 || count(array_intersect($groups, $user->groups)) < 1)
{
header('HTTP/1.1 403 Forbidden');
return 'Forbidden';
}
}
$strClass = \Controller::findFrontendModule($objModule->type);
// Return if the class does not exist
if (!class_exists($strClass))
{
$this->log('Module class "'.$GLOBALS['FE_MOD'][$objModule->type].'" (module "'.$objModule->type.'") does not exist', 'Ajax getFrontendModule()', TL_ERROR);
header('HTTP/1.1 404 Not Found');
return 'Frontend module class does not exist';
}
$objModule->typePrefix = 'mod_';
$objModule = new $strClass($objModule, $strColumn);
return $_GET['g'] == '1' ? $objModule->generate() : $objModule->generateAjax();
}
mitPHP-Code:if ($this->Input->get('action') == 'fmd')
{
$this->output($this->getFrontendModule($this->Input->get('id')));
}
PHP-Code:if ($this->Input->get('action') == 'fmd')
{
$this->output(self::getFrontendModule($this->Input->get('id')));
}
Die Entwicklung des Moduls wurde schon vor längerem, aus Sicherheitsgründen, eingestellt.
Soweit ich weiß gibt es aber noch keine Alternative und auch eine Diskussion auf GitHub, die Funktionen in den Core zu übernehmen, sah nicht sehr viel versprechend aus...
Ja so in der Art habe ich es auch verstanden, was natürlich mehr als ungünstig ist,
gerade an dieser Erweiterung hängen sehr viele andere Erweiterungen.
Ich bin noch nicht zum Testen von der Webworker Lösung gekommen, hoffe aber das es klappt, ein CMS ohne richtige Ajax unterstützung ist ja schon ein wenig.......anders.
Vielleicht wird ja die SimpleAjax Extension mal in den Core übernommen. Dort muss man halt "alles selbst bauen" - dadurch stellt die Schnittstelle an sich auch kein Sicherheitsrisiko dar (das Sicherheitsrisiko programmiert man sich dann selbst ;)).
... verstehe nicht, warum man die Sache nicht "saven" kann/könnte..??
Ein Ajax-Zugriff ist doch keine Conto-Erfindung und schon einige Jahre auf der Welt.
Als Alternative könnte man sich mal das Zusammenspiel mit https://contao.org/de/extension-list...rvices.de.html oder https://contao.org/en/extension-list...es_lib.en.html als "Lieferadresse" ansehen.
Ich sehe Ajax als ein "must have" Baustein für ein modernes CMS.
ja ich verstehe das auch nicht, jedes vernünftige CMS hat auch vernünftige Ajax Lösungen,
aber bei diesem scheint das niemanden zu jucken oder niemand braucht das......komisch.
Die bereitgestellte Lösung läuft jedenfalls bei mir wenn ich eigene Module damit anspreche.
Vielen Dank dafür.
Klugscheiss: Es geht ja nicht um den Zugriff (=Request) sondern um die Erstellung des Response.Zitat:
Zitat von zonky
Und mit Leo Unglaubs simple_ajax kannst Du das alles umsetzten. Natürlich musst Du dazu Code schreiben, aber auch nur Du weißt, welche Daten als Antwort zurückgegeben werden sollen. Das lässt sich wohl schwer "duch zusammenklicken" machen.
Das ist bei dem von Andreas Schempp nicht anders, dass spricht (so wie ich es nutze) "mein" plugin an und ich prüfe in "meinem" plugin, wenn es sicherheitsrelevante oder geschützte Daten sind, ob diese gezeigt werden dürfen.
@fiedsch: so unsicher sieht der Quelltext eigentlich nicht aus - es werden m.E. "alle" die Userberechtigungen abgefragt... was fehlt hier?
Das Problem ist, dass "dein" Plugin keine Ahnung hat, ob auf sicherheitsrelevante Informationen zugegriffen wird. Das Modul hat nämlich keine Ahnung, ob es in einer geschützten Seite sitzt. Richtig wäre es, wenn der Ajax-Request auf die aktuelle Seite abgeschickt wird, dass Modul beim rendern erkennt, dass es diesmal ein Ajax-Aufruf ist, und den entsprechenden Response ausgibt. Leider müssen dafür alle Entwickler ihre Module dafür anpassen. Andreas Schempp tut das schon und entwickelt daher seine Ajax-Extension nicht weiter.Zitat:
Zitat von css-umsetzung
Bis alle anderen nachgezogen haben, muss man entweder auf Contao 3.2 bleiben oder eben die Ajax.php anpassen :D
Ich habe das Gefühl das läuft auf die gleiche Diskussion wie schon im oben indirekt referenziertenZitat:
Zitat von css-umsetzung
https://github.com/contao/core/issues/4415
hinaus. Wir sollten vielleicht die Begrifflichkeit oder das Ziel klären um nicht aneinander vorbei zu reden:
(beliebiger) AJAX-Request vs. AJAX-Request, der ein Contao-Content-Element oder Modul zurück gibt.
Zweiteres ist ein Spezialfall von ersterem und nach meinem Verständnis das Hauptziel von Andreas Schempps Extension.
Ich hatte zunächst hauptsächlich an AJAX Requests gedacht, wie z.B. ein Autocomplete bei der Suchfunktion oder etwas "Postleitzahl eingegeben und dann per AJAX den Ort aus der Datenbank nachladen". Solche Request können schützenswerte Daten enthalten -- dann muss sich der Endpunkt des AJAX Requests darum kümmern -- oder wie bei den Ortsnamen vielleicht eher nicht.
Wenn Du ein Content Element oder Modul von Conto als Response haben willst, könnte das Modul selbe geschützt sein, oder die Seite, in der es eingebaut ist. Beides führt ohne AJAX zum gleichen Ziel. Da ein Modul aber nicht weiß, wo es eingebaut ist (werden könnte) sieht die Sache hier bei AJAX anders aus. Soweit ich es verstehe, versucht sich die AJAX-Erweiterung von Andreas Schema soweit möglich um die Rechteprüfung zu kümmern.
Ich bevorzuge eher etwas wie simple_ajax, das mir einen Startpunkt gibt, in den ich mich einklinken kann um dann die Anfrage dann mit Mitteln des Conto Frameworks beantworten zu können. Ich kann mir z.B. den FrontendUser holen und abhängig von seinen Rechten weiter verfahren.
@zonky: keine Ahnung, ich habe nicht behauptet, daß es unsicher ist und es auch noch nie eingesetzt.Zitat:
Zitat von zonky
Ok ich habe das getestet, bisher bin ich davon ausgegangen dass er das in seiner ajax.php berücksichtigt, nachdem ich aber geschaut habe, was wirklich übergeben wird und dass dann die zuständige Seiten ID fehlt, ist alles klar.Zitat:
Zitat von Thraile
Das ist aber ein Problem dass sich ja auch irgendwie lösen lassen muss, sei es durch das schreiben der aktuellen Seiten ID in der Session oder was auch immer.
Klar, ich kann das auch als Seitenaufruf starten über Ajax und bei Ajax-Requests dann nur den mainbereich und nur meinen inhalt ausgeben, was ich teilweise bei anderen Sachen, gezwungener maßen mache aber das ist Pfusch, weil ja von Contao, alles gerendert wird was normal auf der Seite vorhanden wäre und (absolute ressourcenverschwendung) weil ich dann einfach mittendrin, wenn mein Bereich gerendert wird, Contao stoppe und eine Ausgabe mache.
- Schön ist das nicht, normal muss der Entwickler eine solche Funktion zur Verfügung stellen (ja ich weiss das Contao kostenlos ist, aber man hat ja eine gewisse Erwartungshaltung).
- Ständig werden in dem CMS Sachen integriert, die eigentlich mehr nerven als nutzen (Composer usw.) aber an diesem "für einige wichtigen Punkt scheint irgendwie kein Interesse vorhanden zu sein.
... so habe ich das Modul von Andreas auch verstanden und so habe ich das im Einsatz - der Vorteil der Variante ist m.E. das man nicht darauf angewiesen ist, das ein Modul mitspielt bzw. erst den Entwickler bitten muss, das "Feature" mit einzubauen - mit einem "JavaScript-Dreizeiler" ist aus einem "Kalender-neuer-Monat=>neue-Seite" eine schöne Ajaxgeschichte geworden.Zitat:
Zitat von fiedsch
@CSS-U: vielleicht können wir nachher mal telefonieren - ich glaube ich hab´s noch nicht ganz geschnallt...
Ja gerne, Ich bin da.Zitat:
Zitat von zonky
Eigentlich ist es nun klar und theoretisch, je nachdem ob man sensible Bereiche hat, wirkliche eine extreme Sicherheitslücke (ich bin bisher davon ausgegangen, dass der Zugriff vom Ajax.php geprüft wird),
denn wenn du beispielsweise bei deiner "thorsten" Seite einfach als fmd eine x-beliebige ID übergibst, bekommst du grundsätzlich die Ausgabe vom Modul (ich hab da smal probiert bei dir :) ), so lange da keine sensiblen Daten in Modulen stecken, ist die Welt noch toll aber wehe wenn nicht (ich denke da an beispielsweise eine im frontend befindliche Adressliste die Über ein Modul verwaltet wird, bei der der Admin denkt alles ist sicher, weil das Modul ja in einer geschützen Seite eingebettet ist).
o.k. - habs begriffen...
wenn man ein FE-Modul direkt schützt, funktioniert der Schutz auch - wenn das FE-Modul aber über ein CE (z.B. Typ Modul) eingebunden und der Schutz im CE eingestellt wird, juckt das natürlich den (direkten) Ajax-Aufruf des FE-Moduls nicht...
Aber die simpleAjax enthebt einem ja nicht von der (selben) Aufgabe ;-)
Du kannst sogar die Seiten-Id mit übergeben, dann steht dir $objPage sogar zur Verfügung. :DZitat:
Zitat von css-umsetzung
Das war auch meine erste Reaktion, aber wenn man etwas genauer drüber nachdenk, geht es einfach nicht anders. In Contao könnte theoretisch jedes Element dafür sorgen, dass dein Modul/CE nicht mehr angezeigt werden darf. Sicher sein, dass die Ausgabe für den Request berechtig ist, kannst du also erst, wenn das entsprechende Element auch wirklich gerendert wird.Zitat:
Zitat von css-umsetzung
Bei der simple Ajax ist das Problem auch vorhanden, allerdings muss hier jeder Entwickler erst einmal Ajax-Funktionalitäten bereitstellen damit überhaupt irgend etwas geladen werden kann. Die Extension nimmt ja nur den Request entgegen und bietet Hooks an um darauf zu reagieren. Man kann nicht per default jedes Element ansprechen. Das ist sicherlich besser, aber das Grundproblem besteht weiterhin und ist wohl nur über irgendwelche Sicherheitstokens zu lösen.
ich guck gerade nach dem Thema... z.B. http://stackoverflow.com/questions/1...my-own-websiteZitat:
Zitat von Thraile