[jsonapi]

Eigentlich habe ich die Erweiterung für mein "AppProjekt" geschrieben. Da die erste Version meiner eigenen API im laufe der Entwicklung einfach zu viele Schwachstellen hatte, habe ich die API neu geschrieben.

Es wird einmal eine Newsliste zur Verfügung gestellt und zum anderen folgende Inhaltselemente:

• Überschrift
• Text
• Bild
• Gallery
• Liste
• Youtube

Anleitung:

1. Download jsonapi von Github

2. Optional: Es bietet sich an, dafür eine neue Subdomain anzulegen, z.B.: api.meinedomain.tdl.

3. Ordner "jsonapi" nach /system/modules kopieren.

Seitenstruktur

4. Eine neue Seite mit dem Seitentyp, Startseite einer Webseite, anlegen. Dort unter Domain dann die Subdomain eingeben, z.B. api.meinedomain.tdl

4.1. Eine neuen Seite mit dem Seitentyp, JsonApi auswählen und anlegen.

Die API ist jetzt Einsatzbereit:

5. Um auf die API zuzugreifen einfach per Browser:

http://api.meinedomain.tdl/?modul=Element

oder

http://api.meinedomain.tdl/?modul=NewsList

aufrufen.

Welches Nachrichtenarchiv z.B. aufgerufen werden soll, kann über GET Parament gesteuert werden. Es stehen folgende Parameter zur Verfügung:
modul, id, pid, limit, page

Als Beispiel:

Nachrichten aus Archiv 1 und 2 mit GET-Paramenter pid abrufen:
http://api.meinedomain.tdl/?modul=NewsList&/pid=1,2

Mit dem GET-Parameter "page" kann man auf weitere Nachrichten zugreifen:
http://api.meinedomain.tdl/?modul=Ne...pid=1,2&page=2

Um das Anzeigelimit der Beiträge pro Seite zu verändern (default ist 5), kann man den GET-Parameter "limit" nutzen:
http://api.meinedomain.tdl/?modul=Ne...age=2&limit=10

Mit dem Parameter "id" kann gezielt auf Elemente zugreifen:
http://api.meinedomain.tdl/?modul=NewsList&id=1,2,5,6

Ich habe heute die Erweiterungen mal in das ER hinzugefügt.

https://contao.org/de/erweiterungsli...r/reldate.html

Sehr vielversprechend. Eine fehlende (externe) API ist m. E. einer der Schwachpunkte von Contao. Hast du eine Beispielseite, bei der man mit der API rumspielen kann?

Wenn ich mir den Code so anschaue, hast du ziemlich viel "handgestrickt". Das führt zum einen zu potenziellen Sicherheitslücken (z. B. hier – du solltest unbedingt query parameters benutzen anstatt die Variablen direkt im String einzusetzen!!), zum anderen machst du es dir unnötig schwer. Schau dir doch mal die Models an, z. B. NewsModel, das solltest du relativ leicht wiederverwenden können. Wenn dort was fehlt bzw. du die nicht direkt einsetzen kannst, empfehle ich eigene Models zu erstellen, die von diesen Models ableiten. Möglicherweise kannst du damit auch schon eine RPC-API basteln, also dass du von den API calls hauptsächlich nur auf Methoden-Aufrufe der Model-Klassen übersetzen musst. Damit würdest du mit wenig Aufwand bereits viele der Contao-Schnittstellen unterstützen können.

Folgende Idee noch: Erstelle doch einen eigenen Seitentyp, den man dann anstatt "Startpunkt einer Website" einsetzt (kannst die zugehörige Klasse ja einfach kopieren und anpassen). Dann hängt es davon ab, ob du das Routing unterhalb dieses Punktes übernehmen kannst (wahrscheinlich geht das erst ab Contao 4/Symfony) – wenn ja, würde ich darunter eine feste Baumstruktur schaffen, sodass man nicht mehr eigene Module und Seiten erstellen muss, sondern das automatisch vom Modul gehandelt wird (es somit auch immer fixe "Unterseiten" bzw. Endpoints gibt, die man nicht mehr ändern kann). Wenn nicht, könntest du auch einen eigenen Seitentyp für die "Unterseiten" erstellen, der dann auf die JSON-API angepasst ist (dann wäre die Header-Fummelei auch nicht mehr nötig bzw. an der richtigen Stelle) – hier gilt auch wieder, dass es damit, je nachdem, wie du es umsetzt, nicht mehr nötig ist einzelne FE-Module zu erstellen.

Hallo FloB,

danke für dein Feedback. Ich habe das zum Anlass genommen um die API mal "kurz" zu Überarbeiten (wird wahrscheinlich auch nicht das letzte mal gewesen sein). Die neue Version ist auf Github, sowie im ER verfügbar.

Sicherheitslücke:
Ich verwende eigentlich duchgängig \Input::get(), damit sollte eigentlich ein SQL-Inject nicht möglich sein, ich habe aber zusätzlich noch eine Prüfung eingebaut, welche nur Zahlen, bzw. Zahlen und Kommata, erlaubt.

Models:
Ich fand es einfacher, die paar Abfragen kurz selber zu schreiben, zumal ich halt ganz gezielt nur "Nutzdaten" abgreifen wollte, ich werde mir das aber die Tage, nachdem ich für die APP ein RC habe, mal genauer angucken.

RPC-API:
Steht erstmal nicht auf meinen Arbeitsplan.

Seitentyp:
Ich hatte das in der Version 0.1 noch drin - hatte es dann aber wieder verworfen, weil ich irgendwie - naja ich machs kurz - gefailed habe :). Ich habe das ganze jetzt wiede entsprechend in den letzten 8 Stunden, neben vielen Kleinigkeiten umgebaut.

Demo-API zum testen:

http://api.marq.one/
http://api.marq.one/?modul=NewsList&pid=1,2
http://api.marq.one/?modul=NewsList&id=12
http://api.marq.one/?modul=Element&pid=12

Zitat:

---

Zitat von marq

Ich habe das zum Anlass genommen um die API mal "kurz" zu Überarbeiten (wird wahrscheinlich auch nicht das letzte mal gewesen sein). Die neue Version ist auf Github, sowie im ER verfügbar.

---

Wie ändert sich dadurch die Benutzung für den Admin? Wenn ich den Code richtig interpretiere, legt man nun weder Module noch Unterseiten für den Startpunkt an, oder?

Zitat:

---

Zitat von marq

Sicherheitslücke:
Ich verwende eigentlich duchgängig \Input::get(), damit sollte eigentlich ein SQL-Inject nicht möglich sein, ich habe aber zusätzlich noch eine Prüfung eingebaut, welche nur Zahlen, bzw. Zahlen und Kommata, erlaubt.

---

OK, dennoch bist du mit prepared statements auf der sichereren Seite (also mehr von diesem Typen von SQL-Statements mit '?'). Soweit ich das sehe schützt dich Input::get() auch nicht vor SQL-Injections!

Zitat:

---

Zitat von marq

Models:
Ich fand es einfacher, die paar Abfragen kurz selber zu schreiben, zumal ich halt ganz gezielt nur "Nutzdaten" abgreifen wollte, ich werde mir das aber die Tage, nachdem ich für die APP ein RC habe, mal genauer angucken.

RPC-API:
Steht erstmal nicht auf meinen Arbeitsplan.

---

Fair enough – würde trotzdem, grade aus Gründen der Zukunfts- und Anwendungs-Sicherheit, dringend raten auf die Models zurückzugreifen, du kannst da auch schrittweise deine get*Element-Methoden mit Aufrufen einzelner Model-Methoden (anstatt der SQL-Statements) ergänzen. Ich gehe davon aus, dass diese dann mit z.T. deutlich weniger Code-Zeilen auskommen, und andersrum eine Erweiterung der Funktionalität massiv vereinfacht wird.

Zitat:

---

Zitat von marq

Seitentyp:
Ich hatte das in der Version 0.1 noch drin - hatte es dann aber wieder verworfen, weil ich irgendwie - naja ich machs kurz - gefailed habe :). Ich habe das ganze jetzt wiede entsprechend in den letzten 8 Stunden, neben vielen Kleinigkeiten umgebaut.

---

Darf ich fragen, was schief gelaufen ist?

Zitat:

---

Zitat von marq

Demo-API zum testen:

http://api.marq.one/
http://api.marq.one/?modul=NewsList&pid=1,2
http://api.marq.one/?modul=NewsList&id=12
http://api.marq.one/?modul=Element&pid=12

---

Danke! Interessanterweise wurden bei mir Backend-Cookies gesetzt – weißt du, wie das zustande kommt?

Zitat:

---

Was ändert sich für den Admin?

---

Der Admin legt jetzt nur noch ein Endpoint in Contao fest - das kann der innerhalb einer Seite machen oder innterhalb eines neuen Startpoints. Also quasi Seitentyp JsonApi auswählen, ggf. das dazugehörige Bildformat - fertig.

Zitat:

---

Darf ich fragen, was schief gelaufen ist?

---

- Eigentlich weiß ich es selber nicht mehr, irgendwann hatte ich das mal rausgenommen, weil ich durcheiannder gekommen :-)

Zitat:

---

Models:

---

Wie gesagt, ich schau mir das die Tage mal an.

Zitat:

---

Backend-cookies:

---

So aus dem Stehgreif weiß ich das jetzt auch nicht, werde mir das aber im im Zuge der Models angucken.

In der Version 0.1.2 sind neben ein paar unwesentlichen Änderungen noch eine größere Änderung dazu gekommen.

Um jetzt auf Elemente oder Elementlisten zugreifen zu können, muss jetzt die ptable mit angegeben werden... z.B.

Ausgabe eiens Einzelelements:
http://api.meinedomain.tdl/?modul=El...ptable=tl_news

Ausgabe aller Elemente mit der Parent-ID: 11 mit:
http://api.meinedomain.tdl/?modul=El...ptable=tl_news

Achtung, wieder eine potenzielle SQL-Injection-Lücke! Ich rate dir dringenst auf SQL Prepared Statements oder besser die Models zurückzugreifen!

Zitat:

---

Zitat von FloB

Achtung, wieder eine potenzielle SQL-Injection-Lücke! Ich rate dir dringenst auf SQL Prepared Statements oder besser die Models zurückzugreifen!

---

Schick ihm halt einfach einen Pull-Request auf GitHub :-)

Habe vor diesem Post bereits den Commit kommentiert. Die zweite Nachricht hier war als Warnung an potenzielle Nutzer der Erweiterung gedacht.

PS: Mir geht es hier nicht darum irgendwas schlecht zu machen, im Gegenteil. Ich mahne nur zur Vorsicht, es werden zu viele vermeidbare Fehler gemacht, die wirklich massive Konsequenzen für die Anwender haben können.

Servus,

danke für das Feedback - auch die Nachricht Github - mir ist bewusst, dass die letzte Änderung nicht ganz "sauber" war - aber zu min. erst einmal ein Problem gelöst hat, welches entsteht, sobald mal die API mit mehr als nur tl_news betreiben will. Ein Element konnte vorher nicht einen Elternelement (ptable) zugeordnet werden. Ich werde dort allerdings noch Einschränkungen vornehmen [A-Z,a-z,_-].

Da ich mit GET-Parametern arbeite, ist es eigentlich egal ob ich halt mit Models arbeite oder nicht - weil die entsprechenden Models eigentlich auch nichts anderes als ich, nur das ich den Umgang in den speziellen Fall einfach zu kompliziert finde und aus eine Zeile Abfrage würde dann halt ein halbes Buch werden. Ggf. habe ich da auch einfach nur an nen schlechten Beispiel getestet.

Für den kommerziellen Einsatz würde ich zu min. stark dahin tendieren, die API noch mit einen KEY zu schützen.

Zitat:

---

Zitat von FloB

Die zweite Nachricht hier war als Warnung an potenzielle Nutzer der Erweiterung gedacht.

---

Ich habe gerade ein patch eingespielt, der das Sicherheitsloch stopft.

Und wie greif man auf Content Elemente zu
Wenn die Page Id 15 ist und das Text Element die Id 56 hat?

Kommt nur "ERROR"

Evtl. auch interessant:
https://github.com/DieSchittigs/cont...ent-api-bundle

Code:

---

<br><strong>Recoverable error</strong>: Argument 1 passed to Contao\Image::__construct() must be an instance of Contao\File, null given, called in /var/www/clients/client32/web52/web/system/modules/core/library/Contao/Image.php on line 896 and defined in <strong>system/modules/core/library/Contao/Image.php</strong> on line <strong>107</strong>
<pre style="margin:11px 0 0">
#0 system/modules/core/library/Contao/Image.php(107): __error(4096, 'Argument 1 pass...', '/var/www/client...', 107, Array)
#1 system/modules/core/library/Contao/Image.php(896): Contao\Image->__construct(NULL)
#2 system/modules/core/library/Contao/Controller.php(1555): Contao\Image::create(NULL, Array)
#3 system/modules/jsonapi/classes/ContaoJsonApiHelper.php(68): Contao\Controller::addImageToTemplate(Object(Contao\FrontendTemplate), Array)
#4 system/modules/jsonapi/classes/ContaoJsonApiNewsList.php(56): ContaoJsonApiHelper->image2json('\xF5\x8B\xDCH\xD9:\x11\xE4\xB8\xCBRT\x96\xE2\x94...', '', 'a:3:{i:0;s:0:""...')
#5 system/modules/jsonapi/classes/ContaoJsonApi.php(40): ContaoJsonApiNewsList->NewsList('a:3:{i:0;s:0:""...', NULL, NULL, NULL, NULL, NULL)
#6 system/modules/core/controllers/FrontendIndex.php(285): ContaoJsonApi->generate(Object(Contao\PageModel), true)
#7 index.php(20): Contao\FrontendIndex->run()
#8 {main}
</pre><br />
<b>Fatal error</b>:  Call to a member function exists() on null in <b>/var/www/clients/client32/web52/web/system/modules/core/library/Contao/Image.php</b> on line <b>110</b><br />

---

Kann hier jemand helfen?