RFC: Kommende XML-API CCU Addon 2.0 Version

[jmaus]

Kann ich mit der neuen Version wohl beides vergessen?

Noch ist die neue v2 Version ja nicht offiziell draussen. Ist ja bis jetzt nur eine RFC/alpha version. Ich nehme die ganzen Hinweise und aufgezeigten Nutzungsszenarien hier natürlich schon mit. Und so wie es aussieht werde ich wohl doch nochmal etwas tiefer über statische auth tokens nachdenken und schauen wie ich die am besten/einfachsten umsetzen kann. Dann würde ein Login/Logout bzw. sessionid doch nicht notwendig sein, sondern man eben z.B. jedem call einen statischen "&token=XXXXXX" (oder so ähnlich) mitgeben. Kann aber eben nur etwas dauern bis ich das umgesetzt habe weil ja erst noch irgendeine verwaltung dieser auth tokens implementiert werden muss.

[Silverstar]

[...] weil ja erst noch irgendeine verwaltung dieser auth tokens implementiert werden muss.

Ich stelle mir das so vor, dass die xml-api v2 eine eigene Webseite außerhalb der webui bekommt (so wie z.B. ccu-jack oder cuxd), welche nur mit gültiger webui Session aufrufbar ist (das geht doch afaik?).
Dort eine simple Tabelle: token, comment, [remove button], und irgendwo einen [add token button].
Ich sehe keine Notwendigkeit, das in die Webui einzubauen, außer vielleicht einen Button in der Systemsteuerung, der auf diese seperate Seite führt.

[jmaus]

Sowas in der Art wird es vmtl werden, ja. Scheue nur den Aufwand diese Webseite zu generieren. Könnte mir aber auch vorstellen einfach zwei zusätzliche funktionen "genAuthToken" und "revokeToken" zu machen mit denen man mit gültiger sessionID dann sich token anlegen bzw zurückziehen kann. Dann könnte ich mir solch eine Webseite mit Webelementen sparen und ein nutzer müsste die nur von hand aufrufen und gut ist… mal sehen.

[GoSh]

Und so wie es aussieht werde ich wohl doch nochmal etwas tiefer über statische auth tokens nachdenken und schauen wie ich die am besten/einfachsten umsetzen kann.

Vielen Dank - das hört sich gut an. Auch die Begrenzung auf lokale IP-Adressen wäre sinnvoll - ggf. mit einer config-Datei?

[jmaus]

Hallo Zusammen,

es hat zwar etwas gedauert bis ich die Zeit gefunden haben die hier vorgeschlagene stateless token basierte Authentifizierung in das XML-API CCU Addon aufzunehmen. Nun habe ich das aber in einer neuen 2.0b2 Betaversion des XML-API CCU Addon wie folgt umgesetzt:

1. Es existieren jetzt drei neue Funktionen "tokenregister.cgi", "tokenrevoke.cgi" and "tokenlist.cgi" welche nun für die verwaltung der stateless tokens verantwortlich sind. Wie die Namen dieser neuen API Funktionen schon verraten kann man sich mit entsprechender Authentifizierung nun ein neues stateless token anlegen und löschen lassen und auch eine Auflistung aller Tokens durchführen.
2. Die in der 2.0b1 ursprünglich eingeführten "login.cgi" und "logout.cgi" habe ich nun wieder entfernt da diese nicht mehr gebraucht werden.

Wenn man nun nach einer frischen/initialen XML-API CCU Addon 2.0b2 Installation sich seinen ersten Token anlegen lassen will, so kann man das einfach über die Einstellungsseite des XML-API-CCU Addons erledigen die man ja unter "Systemsteuerung -> Zusatzsoftware -> XML-API -> Einstellen" erreichen kann. Hier muss man dann nur einmalig auf "tokenregister.cgi" in der Auflistung der XML-API Funktionen klicken und schon wird ein neues token angelegt und die tokenID dort dann ausgegeben. Dieses Token kann man dann einfach in einer xml-api url wie

Code: Alles auswählen

http://homematic-raspi/addons/xmlapi/devicelist.cgi?sid=XXXXXXXX

anstelle der "XXXXXXXX" einsetzen und dann sollte in diesem Falle die devicelist.cgi entsprechend ausgeführt werden und die Ergebnisse zurückgeben.

Heruntergeladen werden kann diese neue Betaversion von folgender Seite:

https://github.com/homematic-community/ ... /tag/2.0b2

Wie immer würde ich mich freuen wenn Interessierte sich diese neue 2.0b2 Version und die darin umgesetzte token-basierte Authentifizierung einmal genauer anschauen würden und vor allem die Personen die in den vorherigen Diskussionen berechtigterweise Kritik an der vorherigen session-basierten Authentifizierung gegeben hatten. Ich denke mit der neuen Token-basierten Authentifizierung sollte nun im Grunde der alte komfortable Anwendungsfall weiterhin möglich sein da man ja lediglich existierende URL dann um den "?sid=XXXXXXXXX" Parameter mit der statischen token ID ergenzen muss damit XML-API wie vorher dann die angeforderten Funktionen ausführt und XML Daten zurückgibt.

Bitte also mal ein Auge drauf werfen und entsprechendes Feedback geben ob das nun so besser passt und was eurer Meinung nach noch drin fehlen würde bevor man an einen public v2 release gehen kann.

[Baxxy]

Schön das du nun doch den einfacheren komfortablen Weg gewählt hast.
Und auch schön das du die v2.0 durch das mergen der ganzen PR's nun noch schmackhafter machst.

Hab jetzt mit der 2.0b2 auf einem der Testsysteme ein bisschen "gespielt" und bisher nichts zum meckern gefunden.
Läuft.

[jmaus]

Und auch schön das du die v2.0 durch das mergen der ganzen PR's nun noch schmackhafter machst.

Ja, dachte ich mir auch das es eine gute Idee ist Allerdings werden diese Dinge erst mit der nächste 2.0b3 mit dabei sein. Ich will/wollte erst einmal hier nur Erfahrung einsammeln mit der neuen token API und ob das hier auf Zuspruch trifft oder jemand noch irgendwas hat was dann vielleicht wieder ein Umbau der grundsätzlichen API benötigen würde. Denke zwar das das jetzt in der Tat runder aussieht, aber wer weiss welche Ideen oder Hinweise es zu der neuen v2 und dessen neuer Sicherheitsstruktur noch so gibt

[jmaus]

Ok, da zu der letzten 2.0b2 Version mit der token-basierten Authentifizierung bis jetzt kein Widerspruch kam habe ich gerade wie schon angedeutet die 2.0b3 als neue beta version hier freigegeben:

https://github.com/homematic-community/ ... /tag/2.0b3

In dieser Version habe ich einige neue Features integriert die als PullRequests eingereicht wurden und die nun entsprechend Teil des kommenden v2 Releases werden sollen. Wäre also schön wenn der Eine oder Andere die 2.0b3 bitte auch noch auf Herz und Nieren prüfen könnte damit der finale v2 Release des XML-API Addon dann hoffentlich bald raus kann. Und wer natürlich noch hier+da Hinweise oder Anmerkungen auch zur neuen token-basierten Auth hat kann die natürlich hier gerne auch vorbringen.

[Henke]

Die Performance der XML-Api könnte bei vielen genutzten Aufrufen - Beispiel state.cgi - um den Faktor 4 verbessert werden, wenn das Script nicht über TCL, sondern direkt über den Port 8181 ausgeführt wird.
Test mit 100 Durchläufen und Abfrage eines Datenpunktes:
RPC: 1.15 sec
XML-Api v2.0b3 state.cgi: 6.35 sec
http port 8181 mit Script aus state.cgi: 1.39 sec

[jp112sdl]

War

direkt über den Port 8181

nicht genau jene Sicherheitslücke, um ohne gültige Session alles machen zu können?