Password based authentication no longer supported by March 2018

**svethi** · 29.09.2017, 15:03

Das habe ich mich ehrlich auch gefragt. Keine Ahnung, doch im Grunde macht das ja eh nur bei Dauerverbindungen Sinn. Wenn ich jetzt auch noch vor jedem WebREST eine Tokenabfrage machen muss, dann hat der MiniServer aber auch wieder viel mehr zu tun.

**Christian Fenzl** · 29.09.2017, 15:18

...außer ich speichere den Token ab und verwende ihn immer wieder...

Ich hab mir eh einen Punkt in die loxberry-Issues gesetzt. Es wäre eigentlich ganz witzig, wenn der LoxBerry eine einzige Websocket-Verbindung aufbaut, und alle Plugins kommunizieren darüber. Man könnte den Status aller (visualisierten) Bausteine für die Plugins am LB (über ein Modul) bereitstellen. Jedes Plugin hätte Echtzeitzugriff, ohne jedesmal selbst eine neue Verbindung aufzumachen.

**svethi** · 29.09.2017, 15:22

Ja, das wäre nicht schlecht, daher habe ich jetzt auch schon was über node-red bei mir gemacht, da das auch schon ne Verbindung auf hat.
Nee, der Token verfällt ja wie da steht. Den also zu speichern und immer wieder zu verwenden, geht nicht.

**Christian Fenzl** · 29.09.2017, 15:48

Verfällt nach 4 Wochen oder so.
Also Token speichern und wiederverwenden, und wenn mit Token 401 oder sowas zurückkommt, dann neuen Token anfordern. So hätt ich mir das gedacht.
Ich frag aber nicht nach bei Loxone, weil dann bauen sie‘s bei REST erst recht aus.

**Gast** · 29.09.2017, 16:30

Ich habe mich noch nie mit "token based authentication" beschäftigt.

Würde das beuten, dass einfache Aufrufe wie
http://Benutzer:Passwort@AdresseMini...Wohnzimmer/all
zukünftig (v9) nicht mehr funktionieren?

Ich schreibe momentan mittels solcher Aufrufe meine Temperatur-Werte der Loxone-Heizung-Steuerung in die mySQL-Datenbank.

Wie müsste man die Abfrage denn dann aufbauen?

Edit:
Ich habe die Loxone API gefunden, mit dem Link "Kommunikation mit dem Miniserver".
Ist das dahinter liegende 21-Seiten Dokument "COMMUNICATION WITH THE LOXONE MINISERVER - Loxone Config 9.0" für dieses Thema Pflichtlektüre?

**Christian Fenzl** · 29.09.2017, 17:33

Das Dokuemtn ist das, was ich oben verlinkt hab.
Ich glaube nicht, dass es fürs normale Webservice eingeführt wird, weil RESTful ist es dann nicht mehr.

Du müsstest vorher den Public Key und einen Salt abholen, dann das Passwort und Salt mit SHA1 hashen, mit dem User und Key HMAC verschlüsseln und an den MS senden. Zurück bekommst du den Token, den du dann an den Command (der wiederum verschlüsselt werden muss) anhängst.

Für einen Command, wenn du noch keinen Token hast, sind das dann drei HTTP-Requests.

**preslmayer** · 19.11.2017, 10:17

Hallo!
Hat jemand von euch schon erfolgreich mit der neuen Token Authentifizierung einen HTTP request zum MS absetzen können?
Welche Schritte sind dazu nötig?
Das Dokument von Loxone ist sehr verwirrend.

**topoff** · 19.11.2017, 10:27

Hi,
Da hätt ich auch noch eine Verständnissfrage zu ->

Token (keine dynamischen) kenn ich von FHEM das bei einem http befehl neben benutzer : passwort@IP noch hinten &fwcsrf=token angehängt werden müsste <- dieser token läuft nicht ab und kann einfach bei den Befehlen dazugesetzt werden und erledigt.

Wenn ich das Dokument oben richtig verstehe wechselt Loxone ab März 2018 auch auf Token - aber einen der 4 Wochen lang gültig ist und danach vom System gewechselt wird somit dynamisch.

Also ein Befehl aus HAbridge (Alexa) welcher aktuell mit benutzer : passwort@IP per http an /dev/sps/io/ entweder an virtuellen Eingang mit trigger pulse oder UUID mit Szenenummer bzw on/off gesendet wird wäre hiervon betroffen?!? Das oben mit dem RESTful versteh ich jetzt nicht so ganz.....

Wäre ziemlich aufwändig dann immer die Tokens händisch wechseln zu müssen....

-> kann man die Token Authentifzierung vorab in der Konfig aktivieren um zu testen ob diese bei den http requests an /dev/sps/io/ greift?
-> alternativ habe ich hier wo gelesen das node-red die token based authentication unterstützt - wenn ich das richtig sehe müsste ich im worst case falls o.g. http request nicht greift das HAbridge signal an node-red senden und dann erst an loxone oder nach einem connector alexa - node-red suchen und die HAbridge in die Tonne treten ......

Gibt es da schon sachdienliche hinweise - wollte mir eigentlich weitere Echo Dots bestellen (nächste Woche im Angebot wg. black Friday) aber wenn das am Schluss nicht mehr funktioniert steh ich blöd da.....

Gruß
Tom

**preslmayer** · 19.11.2017, 10:33

Das hier wird dann anscheinend nicht mehr funktionieren!

Zitat von topoff

....benutzer : passwort@IP per http an /dev/sps/io/ entweder an virtuellen Eingang mit trigger pulse oder UUID mit Szenenummer bzw on/off
....

Is eh gut so, da dies mit einer "Man in the Middle"-Attacke angreifbar ist!
Das Node-red loxone plugin habe ich mir auch schon angesehen. Dieses arbeitet aber mit websockets und nicht mit HTTP requests.

**topoff** · 19.11.2017, 10:38

und das Node-red könnte aber den http befehl von HAbridge empfangen und auf die bereits angelegten Config Routinen definierten VIs und UUIDs ansprechen?
Müsst ich eben den extra weg gehen und hoffen dass das delay nicht lange ist.......

**preslmayer** · 19.11.2017, 10:50

Der Weg über Node Red kommt bei mir nicht in Frage! Noch ein Ding das laufen und gewartet weden muss. Außerdem möchte ich nicht permanent einen websocket offen haben.
Meine Applikation setzt nur ab und zu einen Befehl an Loxone ab. Dies möchte ich secure per HTTP request erledigen.

**topoff** · 19.11.2017, 10:58

Der "Umweg" freut mich auch nicht wirklich da für HAbridge wohl aber kein passendes Update speziell für Loxone zu erwarten ist wird mir wohl nichts anderes übrig bleiben als eine der beiden Lösungen a) über Zwischenstück (Node-red) oder b) Alexa Befehle anders auszulesen bleiben...... mal schauen ggf. hat hier wer ne ähnliche installation und eine bessere Idee - ist ja noch 3 monate hin... Auf jeden Fall gut dass es zumindes die Möglichkeit gibt mit so etwas wie bspw. Node-red auf Loxone weiter per Raspi zuzugreifen....

**Christian Fenzl** · 19.11.2017, 11:22

1. Die Token-Based Auth ist jetzt schon aktiv (ab V9) und kann sofort getestet werden.

2. Niemand weiß, ob das für REST auch abgedreht wird. Die vom Support kennen selbst den Unterschied nicht und deswegen bekommt man nur sinnlose Antworten.

3. Wenn für REST die Token-based Auth kommt, werden wir das sofort in LoxBerry einbauen, und wenn es Nächte dauert, und dann auch ein entsprechendes Gateway machen.

Die REST-Schnittstelle darauf umzustellen ist meiner Ansicht nach sinnlos. Richtig wäre, Websocket mit Token auf einem anderen Port zu fahren, sodass der MS extern nur token-based läuft, und intern weiterhin normal per Basic funktioniert. Es wird dazu führen, dass schlecht implementierte Auth dann drei HTTP-Requests durchführt, wo jetzt nur einer erforderlich ist.

**topoff** · 19.11.2017, 12:19

Oki

Wie üblich super Erklärung - dann wart ich einfach mal ab was alles so im März passiert - ein gateway das meine internen http commands durchschleust wäre natürlich der Hit !

Gruß und noch schönnen Sonntag!
Tom

Password based authentication no longer supported by March 2018