Contao Inhalte als JSON/XML o.ä. ausgeben

Hallo zusammen,

ich habe aktuell die Aufgabe das ich die Inhalte einer bestehenden Contao-Seite auf andere Seiten (unter anderme mit anderem CMS) live darstellen soll. Hierfür bräuchte ich die Möglichkeit das ich mir per Schnittstelle die Daten ausgeben lassen kann. Eingefallen sind mir da spontan ganz einfach die Daten als JSON ausgebe, oder das ich mir solch eine WSDL/SOAP Geschichte bastel. Gibt es für solch eine Problematik evtl. schon vorgefertigte Lösungen? Ich bin Dankbar für jede Hilfe bei diesem Problem, da eine Eigenenwitklung aufgrund des Zeitaufwands hier kaum in Frage kommt und ich mich mit Contao bisher null auskenne.

Der Bandyt arbeitet scheinbar gerade an sowas:

Management interface

Zitat:

---

Management-Schnittstelle für Contao
Management-Schnittstelle, die Informationen über interne Objekte abrufen lässt und diese als JSON oder XML-Antwort zurück gibt.

---

Vielleicht solltest du dich mit ihm mal deswegen kurzschließen.

Gruß
Nikolas

Oder nutzt die ctoCommunication Extension:

https://contao.org/de/extension-list...010009.de.html

Zitat:

---

Zitat von andreasisaak

Oder nutzt die ctoCommunication Extension:

https://contao.org/de/extension-list...010009.de.html

---

Gibt es da ein Beispiel Code? Die Erweiterung hört sich vielversprechend an.

Zitat:

---

Zitat von leo.unglaub

Die hier genannte Extension sollte auf keinen Fall verwendet werden. Die enthällt unfassbar schlechten code und sollte noch mal ganz von Vorne angefangen werden. Frage am besten mal bei xat nach, wenn ich mich recht erinnere hatte der eine XML-Schnittstelle, welche solche dinge erlaubt hat.

---

Steht ja auch dabei, dass es noch eine sehr frühe Alpha ist ;)

Gesendet von meinem PadFone 2 mit Tapatalk 2

Das ist doch egal. Entweder ist eine sehr frühe Alpha bereits mit einem sauberen Fundament gebaut oder nicht. Es kann nicht sein das solch eine Extension bewusst ins ER gestellt wird obwohl der Entwickler weiß das sie ein herbes Sicherheitsrisiko ist. Wir haben damals wegen ctoCommunication und syncCto extremen Stress bekommen und mussten von Null anfangen. Da gibt es nichts zu retten was zwischen der Alpha und Beta besser werden könnte!

Ich würde bandyt bitten die Dateien in der Extension zu löschen und neu anzufangen. Und dieses mal ohne konzeptionelle Schwächen, denn die Idee der Extension ist zu gut um sie nun als unsauberen Schrott im ER verschmoren zu lassen. Man müsste sie lediglich sauber aufbauen.

Zitat:

---

Zitat von andreasisaak

Das ist doch egal. Entweder ist eine sehr frühe Alpha bereits mit einem sauberen Fundament gebaut oder nicht. Es kann nicht sein das solch eine Extension bewusst ins ER gestellt wird obwohl der Entwickler weiß das sie ein herbes Sicherheitsrisiko ist. Wir haben damals wegen ctoCommunication und syncCto extremen Stress bekommen und mussten von Null anfangen. Da gibt es nichts zu retten was zwischen der Alpha und Beta besser werden könnte!

Ich würde bandyt bitten die Dateien in der Extension zu löschen und neu anzufangen. Und dieses mal ohne konzeptionelle Schwächen, denn die Idee der Extension ist zu gut um sie nun als unsauberen Schrott im ER verschmoren zu lassen. Man müsste sie lediglich sauber aufbauen.

---

Da hast du natürlich Recht. Ich selber hatte mir den Code aber auch gar nicht angesehen, dazu würde mir auch die Expertise irgendwann fehlen.
Ich wollte nur daraufhinweisen da ja eine Zusammenarbeit zwischen TO und Bandyt hätte stattfinden können.

Ob die Codebasis dazu qualitativ ausreicht oder nicht könnt ihr eh besser beurteilen.
Danke dafür im Übrigen ;)

Gruß
Nikolas

Zitat:

---

Zitat von andreasisaak

Das ist doch egal. Entweder ist eine sehr frühe Alpha bereits mit einem sauberen Fundament gebaut oder nicht. Es kann nicht sein das solch eine Extension bewusst ins ER gestellt wird obwohl der Entwickler weiß das sie ein herbes Sicherheitsrisiko ist. Wir haben damals wegen ctoCommunication und syncCto extremen Stress bekommen und mussten von Null anfangen. Da gibt es nichts zu retten was zwischen der Alpha und Beta besser werden könnte!

Ich würde bandyt bitten die Dateien in der Extension zu löschen und neu anzufangen. Und dieses mal ohne konzeptionelle Schwächen, denn die Idee der Extension ist zu gut um sie nun als unsauberen Schrott im ER verschmoren zu lassen. Man müsste sie lediglich sauber aufbauen.

---

Hast du dir den Code angesehen? Wenn ja: Wo genau steckt denn die konzeptionelle Schwäche in der Erweiterung (Außer, dass solche Erweiterungen grundsätzlich ein Sicherheitsrisiko darstellen)?

Aktuell bin ich nicht bereit die Erweiterung zu löschen, aber natürlich lasse ich mich überzeugen, dass es ein zu hohes Risiko darstellt und werde dann entsprechen aktiv. Dazu benötige ich aber erst einmal mehr Informationen als "unfassbar schlechten Code".

Ja den habe ich mir angesehen. Sonst würde ich sowas ja nicht schreiben. Ich schick dir später die Liste.

PS: Ich bin nicht der einzige der so denkt!

https://contao.org/de/extension-list/view/mi.en.html

Programmierstyle:

• Nicht immer Kommentiert.
• Keine Leerzeile zum Formatieren.
• Keine gute Einrückung.

Programmierung:

• Fehlercodes => Besser Konstanten, die aussagekräftig sind. (Bsp.: $outputgenerator->generateErrorData('00D','0003'))
• Benutzen von XmlWriter => valides XML.
• Benutzen von json_encode($value) wenn keine Besonderheiten im JSON sind.
• Am Contao Framework vorbei.
  
  • mi_processor.php, Line ~ 74 => Anstelle von substr, trimsplit benutzten.
  • extensions.php, Line ~ 70 => scandir von Contao benutzen
• Keinerlei Logging der Aktivitaet

Datenschutz:

• Members können mit Email und Geburtstag ausgelesen werden.
• Extensions können abgerufen werden, mit Versionsnummer.
• Durchprobieren von Loginnamen/ID für das BE möglich.
• Ausgabe der Backendbenutzer mit email und Login Name.
• Ausgabe aller Admins einer Seite.

Allgemein:

• Token im Klartext => Key Exchange wäre besser
• Keine Verschlüsselung der Daten möglich => Siehe Datenschutz
• Anfragen können Mitprotokoliert werden und erneut ausgeführt werden.
• Man-in-the-middle-Angriff
• Token ist nicht eindeutig und hat keinen Komplexitaetsminimum. Er ist nur mandatory. (dca/tl_mi_user.php)
• Es gibt keinen automatisch generierten, mit einem vernnünftigen Komplexitätsgrad
• Deshalb kann man schon durch einfachen BruteForce die Benutzer ausprobieren.
• Da die Token nicht eindeutig sind, kann es passieren, das mehrere gleiche Tokens vorhanden sind, somit ist nicht trennbar zw. den Benutzerrechten.
• Fehlende allg. Zeitstempel in der Ausgabe, wenn ein Modul z.B. den $data['request']['datetime'] nicht befuellt.

mi.php:

• Verbesserung: ob_clean => um vorherige Ausgaben zu löschen und valide json, xml Ausgaben zu bekommen.
• Verbesserung: switch/case => default hoch ziehen über case 'XML':.
• Fehler: Function: run || $apiGroup, not initialized. (~78)

mi_usermgr.php:

• Fehlerhafte Prüfung auf Ablaufzeit. Endzeit wird nie geprüft. Function: checkToken || $currenttime, never used.

@bandyt : Kannst Du mit den Anmerkungen etwas anfangen ?

Mit den meisten Punkten ja, wenn auch nicht mit allen (Was aber eher an einer unterschiedlichen Idee dahinter als am reinen verstehen des Punktes liegt).

Wo laufen unsere Ideen auseinander?

Deine Aussagen gehen in Richtung ganz wenig Daten raus geben, während ich den kompletten Datensatz ausgeben möchte.

PS: Danke für die Analyse. War ja wesentlich ausführlicher als ich es erwartet hatte.

Alle Daten ausgeben oder nur einen Teil hat doch gar nichts mit Andreas Aussage zu tun, da ging es doch ausschließlich um Sicherheit.
Ich glaub du hast da was missverstanden.

Du kannst über deine Erweiterung durch Übergabe von ein bzw. zwei Parametern dir so ziemlich alles ausgeben lassen und das darf nicht sein. Hier musst du einfach nur die Sicherheit erhöhen z.B durch die Verwendung eines API-Keys.
Vor allem aber solltest du versuchen das Contao-Framework zu verwenden und nicht es an jeder möglichen Stelle umgehen :-)

Gesendet von meinem Nexus 7 mit Tapatalk 4