Contao und Ajax... again

[*igi*]

Einen schönen guten Abend zusammen,

das Thema Ajax und Contao wurde sicher schon das ein oder andere Mal behandelt, dennoch habe ich eine Frage zum Grundlegenden Status Quo.
Mein bisheriges Vorgehen, um Ajax-Requests innerhalb der Contao Welt abzusetzen, ist wie folgt:

Ich verwende die jQuery Ajax Funktion um meine Daten an den Server zu senden.

$.ajax({
	method : "GET",
	url : document.URL,
	data : {
		"action" : "bla"
	}
}).done(function(result)
{
	// Do Stuff
}).fail(function()
{
}).always(function()
{
});

Da ich in der URL "document.URL" angebe, wird der Aufruf natürlich an die selbe Seite gesendet, auf der das Modul eingebunden ist; sprich das Modul selbst "fängt" den Ajax-Requests auf.
Das habe ich wie folgt realisiert:

 
public function generate()
{
	if ($this->Environment->get('isAjaxRequest'))
	{
		switch (\Input::get('action'))
		{
			case "bla":
				echo json_encode(array(
					"result" => "blubb));
				break;
		}
		exit();
	}
	...

Das Modul selbst prüft also ob es sich bei einem Aufruf um einen Ajax-Requests handelt oder ob es die compile Funktion aufrufen soll um das Template zu erstellen und co.
Das Ganze funktionierte bisher auch recht gut, bis ich angefangen habe auf einer Seite mehrere Module einzubinden, die alle eigene Ajax-Requests versenden (und sich damit nun natürlich gegenseitig behindern bzw. sich die Requests "wegnehmen").

Jetzt wo ich festgestellt habe, was für einen Quatsch ich hier eigentlich betreibe, beschäftige ich mich etwas mehr mit der Frage "wie macht man sowas bei Contao eigentlich richtig?".
Auch um die Sicherheit der Webseite nicht zu gefährden.

Gelesen hatte ich zuvor bereits etwas über die Erweiterungen "ajax" von Andreas Schempp (https://contao.org/de/erweiterungsli...010069.de.html) und "simple_ajax" von Leo Unglaub (https://contao.org/de/erweiterungsli...e_ajax.de.html).

Letztere scheint den Ajax-Request einfach über einen Hook in eine eigene Klasse zu leiten, in der dieser dann verarbeitet werden kann.
Im Detail habe ich beide noch nicht untersucht. Ich möchte auch nicht, dass mir jemand eine mögliche Lösung tutorialmäßig vorkaut, da ich nur zu faul bin dies selbst zu erledigen
Ich wollte hier nur grundlegend die Meinung der Experten hören, ob beide Varianten (oder evtl. auch eine völlig andere) bedenkenlos zu nutzen sind oder wie der aktuelle Stand, auch in Punkto Sicherheit, im Moment ist.

Auch wenn es bereits zahlreiche Fragen und Antworten zu diesem Thema gibt, ist das Wissen bzw. sind die verschiedenen Techniken ja auch schnell überholt und ich hab ehrlich gesagt gerade ein paar Probleme den Überblick zu behalten, was durchaus machbar ist und was zwar funktioniert aber lieber nicht gemacht werden sollte


Viele Grüße, schönen Dank und einen angenehmen Abend
*igi*

[tl_richard_user]

Hi!

Ich habe mich auch schon mit der Thematik auseinandergesetzt und setze das für mich so um.
Wenn ich im FE Ajax-Requests machen muss, verwende ich tatsächlich die SimpleAjax extension. Macht was es soll. Ich habe aber leounglaubs Version geforked und Kleinigkeiten geändert, die ich für mich wichtig fand (z.B. den Token-Check nicht zu umgehen…) https://github.com/richardhj/contao-simple-ajax
Wenn du die Extension verwendest musst du dich auch selber um die Sicherheit kümmern (permission checks).
Die Extension ajax "darf" nicht mehr verwendet werden. Es ist auch offiziell von den Entwicklern kommuniziert, dass JEDER bei installierter ajax.php JEDES Content-Element, Modul oder Formular OHNE Permission-Check laden kann.

Im Backend verwende ich den Contao-eigenen Hook (processPostAjaxAction oder so ähnlich). Dabei läuft der Ajax-Request an die aktuelle Seite (wie von dir beschrieben). Permission check übernimmt Contao.

[Jayster]

Ich bin kein Experte, aber mit simple_ajax habe ich ebenfalls gute Ehrfahrungen gemacht.

[Wusch]

Du müsstest doch bei deinem Modul nur noch eine ID einfügen und beim Request dann überprüfen ob das Modul verantwortlich für den Request ist. Ggf. in deiner Funktion prüfen ob diese ausgeführt werden darf oder nicht.

[*igi*]

Hallo zusammen,

vielen Dank für die Beiträge. Ich habe mit der simple_ajax Erweiterung jetzt auch etwas herumgespielt. Funktionierte auf Anhieb und scheint seinen Zweck völlig zu erfüllen.
In Sachen Sicherheit frage ich in der Klasse, die den Request entgegennimmt, dann die gleichen Dinge ab, wie ich es auch in einem normalen Modul machen würde.
Also ob das Member eingeloggt ist und für die jeweilige Anfrage überhaupt legitimiert ist und so weiter.

Oder sollten hier noch andere spezielle Abfragen oder sonstige Sicherheitsmechanismen eingesetzt werden?

@ tl_richard_user: Ich habe meinen jQuery Ajax-Request jetzt auch von GET auf POST umgestellt. Der Request-Token dient doch in erster Linie dazu, eine abgesendete Form nicht erneut zu verarbeiten oder?
Funktioniert das bei dir in der Erweiterung bzw. in der Contao-Ajax-Welt generell dann vom Prinzip her genauso? Also prüfst du auf der Serverseite den Token, der vom Client übermittelt wird?
Oder ist diese Token Sache bei einem Ajax Request nicht sowieso obsolet?

@ Wusch: Da könntest du tatsächlich recht haben. Ich müsste das exit(); entfernen, so dass das Skript nicht abgebrochen wird und der Request sozusagen durch alle auf der Seite eingebundenen Module gereicht wird.
Getestet habe ich dies noch nicht. Ich bin im Moment auch eher bei der Variante mit der separaten Ajax-Klasse, da ich dann alle Ajax Funktionen sauber in einer eigenen Klasse habe.

[eknoes]

Der Request-Token dient doch in erster Linie dazu, eine abgesendete Form nicht erneut zu verarbeiten oder?

Nein, es geht - soweit ich weiß - primär um CSRF-Attacken:

Eine Cross-Site-Request-Forgery ist ein Angriff auf ein Computersystem, bei dem der Angreifer eine Transaktion in einer Webanwendung durchführt. Dies geschieht nicht direkt, sondern der Angreifer bedient sich dazu eines Opfers, das bei einer Webanwendung bereits angemeldet sein muss. Dem Webbrowser des Opfers wird ohne dessen Wissen ein arglistiger HTTP-Request (‚Anforderung‘) untergeschoben. Der Angreifer wählt den Request so, dass bei dessen Aufruf die Webanwendung die vom Angreifer gewünschte Aktion ausführt.
[...]

Abwehrmaßnahmen
Jede Transaktion der Webapplikation muss mit einer weiteren – dem Browser und der Webanwendung – gemeinsamen geheimen Information versehen werden. In der Regel ist dies ein sogenanntes Page-Token, meistens eine Zahl oder eine Zeichenkette, die in einem Hidden-Field auf der Seite eingebunden ist. Ohne weitere Lücken in der Webanwendung ist dieses Hidden-Field für den Angreifer nicht auslesbar