UniFi Controller API WLAN

[jentz1986]

Sooo, sorry, ich brauchte erstmal ein bisschen Ruhe um das zu sortieren. Also, um was gehts: Ich brauche die URLs die "die neue UniFi-Controller-Website" aufruft, um die Daten über die Anlage zu sammeln. Das PlugIn tut nämlich einfach so, als würde an Deiner statt, die Web-Oberfläche bedienen. Das funktioniert natürlich nicht mit Zwei Faktor Authentifizierung und ein Cloud-Login zu UniFi hin ist ebenfalls nicht vorgesehen.

1. Schritt: Login:
Öffne die Seite deines Controllers, wo Du Dich einloggst. Mit den F12 Entwickler-Tools kannst Du nun wieder sehen, was die Website für Calls macht. Bei mir passiert nach dem Abschicken der Login-Daten folgendes: Ein Request geht an "htt ps://unifi:8443/api/login", im Bauch (= Request Payload, ganz unten) kann man bei mir User-Name und Passwort lesen. Ich vermute, dass bei Dir die URL eine andere ist. Wenn UniFi da nun was ganz anders gemacht hat, dann wirds schwierig.

2. Schritt: Verschiedene Abfragen:
Als Browser-User auf dem Dashboard angekommen, werden Zustände abgefragt. Das passiert bei mir über "htt ps://unifi:8443/api/s/default/stat/sta"
Schreibzugriffe gehen z.B. per PUT gegen "htt ps://unifi:8443/api/s/default/rest/device/{deviceID}", wobei default der Site-Name ist und {deviceID} eine Ansammlung von Buchstaben und Zahlen. Wenn das auch anders aufgebaut ist, dann müssen wir da im Einzelfall schauen.

Ich vermute, dass die Login-URL nun ein anderes Schema hat, als die eigentliche api "/s/". Dann müsste man das nur entsprechend im Plugin konfigurierbar machen und gut ist. Alles andere ... tjaaaa ... Schonmal überlegt, den CloudKey zugunsten des Docker-Images zu beerdigen? ;-) Nee, das ist keine echte Option...

[artner]

Schritt 1:

Request URL:
https://192.168.1.3/api/auth/login

unten steht

password: "hierdaspasswort"
rememberMe: false
username: "hierusername"

Schritt 2:

die erste url heißt anscheinend
https://192.168.1.3/proxy/network/ap...fault/stat/sta

die Schreibzugriffe (put) dürften über

https://192.168.1.3/proxy/network/api/s/default/rest/device/{deviceip}

gehen

schaut zumindest jetzt mal nicht komplett anders aus (alle adressen (ausgenommen {device-ip}) sind komplett original abgeschrieben und nichts verändert)

[jentz1986]

Danke fürs rausfinden der URLs!

Ich hab mal auf die Schnelle eine Datei umgeklimpert - (ungetestet! EDIT: habs mal bei mir so eingebunden, bis jetzt drehts)

Hier kannst Du sie finden:
https://github.com/jentz1986/smartho...quiti/unifi.py

Die Datei musst Du in den Ordner plugins/unifi/ubiquiti/ als unifi.py einspielen (Die Alte vorher sichern) und dann dort die Zeile 63 von

self._url_flavor = UNIFI_URL_FLAVOR_DEFAULT

auf

self._url_flavor = UNIFI_URL_FLAVOR_CLOUDKEY

ändern.

Für die echte Version brauche ich Dein Testergebnis, und dann muss ich das Ganze auch echt parametrierbar machen. Schön fänd' ich wenn Du noch kurz beschreiben könntest, welche Version des CloudKey-Updates der "Breaking Change" war...

Viel Erfolg, Feedback erwünscht!

[artner]

Hi - Danke schonmal für die Arbeit - leider noch nicht von Erfolg gekrönt

als Controller URL hab ich jetzt mal

https://192.168.1.3

angegeben

item Generator gibt folgendes aus:

Traceback (most recent call last): File "/usr/local/smarthome/plugins/unifi/ubiquiti/unifi.py", line 104, in _get_url
raise LoggedInException("Invalid login, or login has expired")
lugins.unifi.ubiquiti.unifi.LoggedInException: Invalid login, or login has expired

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/smarthome/plugins/unifi/ubiquiti/unifi.py", line 104, in _get_url
raise LoggedInException("Invalid login, or login has expired")
plugins.unifi.ubiquiti.unifi.LoggedInException: Invalid login, or login has expired

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/smarthome/plugins/unifi/__init__.py", line 239, in get_item_hierarchy
hr = self._api.get_device_hierarchy()
File "/usr/local/smarthome/plugins/unifi/ubiquiti/unifi.py", line 216, in get_device_hierarchy
dvcs = self.device_stat("")
File "/usr/local/smarthome/plugins/unifi/ubiquiti/unifi.py", line 203, in device_stat
return self._get_url(url_addr)
File "/usr/local/smarthome/plugins/unifi/ubiquiti/unifi.py", line 112, in _get_url
return self._get_url(url, True)
File "/usr/local/smarthome/plugins/unifi/ubiquiti/unifi.py", line 110, in _get_url
raise DataException("Unable to log in or get data for url {}".format(url))
plugins.unifi.ubiquiti.unifi.DataException: Unable to log in or get data for url https://192.168.1.3/proxy/network/api/s/default/stat/device/

wenn ich mich am webinterface anmelde und dann die Seite https://192.168.1.3/proxy/network/ap...t/stat/device/ im Browser eingebe bekomme ich die ganzen Informationen - es liegt also irgendwo am login

[jentz1986]

Wenn Du die Seite mit den Details direkt aufrufst, gibst Du dann irgendeinen Key oder Code mit, oder kommt das über nen Cookie?

[artner]

Nope, nur den Link, müsste also ein keks sein

[jentz1986]

Verdammt, das ist alles in der Session die in requests verarbeitet wird. Kannst du mal schauen, was du für Kekse hast, nach dem Du dich eingeloggt hast, wieder über die F12 Tools? Ich verstehe dann zwar nicht warum, das im Browser "implizit" klappt, aber nicht mit der Session-Funktionalitä im requests-Modul von Python, aber vielleicht entdeckst Du ja noch was...

[artner]

schaut bei mir so aus

image_109391.png

achja - um eine Vorfrage noch zu beantworten: Breaking Change dürfte von Firmware Version 1.x auf 2.x gewesen sein (derzeit 2.0.27)

gerade getestet: wenn ich "TOKEN" lösch dann geht nichts mehr - wieder angemeldet --> "TOKEN" wieder da --> läuft

[jentz1986]

Ha, XSRF Header, die OpenHabs haben das gelöst. Ich versuchs am WE mal zu portieren...

[jentz1986]

Hmmm, artner , kannst Du mal schauen, welche HTTP-Header Deine Unifi-Oberfläche an das Backend schickt? Kann es sein, dass der Wert im Cookie "TOKEN" der Wert ist, der im Header "x-csrf-token" an den Server geschickt wird?Screenshot 2021-02-20 154535.png

[artner]

gerade gecheckt: Request Headers-cookie ist der token der selbe wie im cookie, respone headers sind die letzten (73) Stellen teilweise unterschiedlich, x-csrf-token passt leider zu gar nix dazu

cookie.png sta.png