Kerninstanz - WebOAuth - Was kann die? Wie verwendet man diese?

Hallo Zusammen,

ich habe schon an anderer Stelle im Forum eine Frage zu OAUTH (V1) und zur Discovergy-API gestellt (https://www.symcon.de/forum/threads/34064-Discovergy-API). Hier möchte ich ganz explizit wissen, was die „WebOAuth“-Instanz im IPS kann und tut und wie man es anwendet. Idealerweise mit einem leicht verständlichen Beispiel.

Konkret wäre da auch noch die Frage: Wenn man in WebOAuth-Instanz einen Eintrag macht und ein Skript damit verbindet, was hat man dann erreicht? Hat man in diesem Skript dann über bestimmte Variablen Zugriff auf sonst nicht vorhandene Eigenschaften,…?

Ist es richtig, dass es dazu keine offizielle Doku gibt?

Bei OAuth handelt es sich um ein Authentifizierungsverfahren das es einer Software ermöglicht sich mit den individuellen Kontodaten des Nutzers bei einem Dienst anzumelden. Dabei ist die Software IP-Symcon fest als vertrauenswürdig Software beim Anbieter des Dienstes hinterlegt. Du als Nutzer meldest Dich direkt beim Anbieter an und authorisierst damit die vertrauenswürdige Software IP-Symcon, die beim Anbieter als bekannt hinterlegt ist, mit Deinem Konto bei dem Anbieter eine sichere Verbindung aufbauen zu dürfen. IP-Symcon kann entweder als OAuth Server oder auch als OAuth Client auftreten.

Im Symcon Test findest Du ein Beispiel. OAuth dient dabei der Modulentwicklung. Wenn jemand also Bedarf hat einen OAuth Dienst zu nutzten kann er ein Modul schreiben, die notwendigen Einstellungen erhältst Du vom OAuth Anbieter und teilst diese dann IP-Symcon per Email mit. Daraufhin bekommst Du die notwendigen Daten zugeschickt die Du bei dem Anbieter hinterlegen must damit sich IP-Symcon bei dem Anbieter authentifizieren kann. Wenn Du dann so ein Modul fertig gestellt hast ist es für jeden Nutzer möglich seine eigenen Kontodaten zu nutzten und damit IP-Symcon zu authorisierte mit dem Dienst zu kommunizieren.

Beispiel wäre z.B. eine spezieller Amazon Skill für IP-Symcon, oder Spotify was auch immer Du für einen Dienst nimmst.
Wenn müstest Du also konkret fragen für was Du Oauth benutzten willst und in welches Modul das z.B. eingebunden werden soll, dann kann man Dir auch konkret Hilfestellung geben. Die WebOAuth Instanz dient einfach als Endpunkt von IP-Symcon über die Daten dann von IP-Symcon Connect empfangen werden oder über die Instanz verschickt werden.

Ein Eintrag macht in der Regel ein Modul, in dem Fall sollte Axel37 bereits Daten der Discovery API haben und auch Daten von IP-Symcon bekommen haben. Es liegt also ein OAuth Identifier vor. Mit diesem Identifier ist es möglich eine Verbindung zur API aufzubauen und einen individuellen Sicherheitstoken anzufordern. Bevor Du also jetzt seperat einen eigenen Identifier beantragst solltest Du einfach den Identifier der Axel37 zu geschickt worden ist benutzten, da die Software IP-Symcon mit einer API einmal verknüpft wird. Also hier Kontakt zu Axel37 aufnehmen. Als Grundlage zum Testen kannst Du das Modul im Symon Test (s.o.) nutzten, dort muss einfach der zugeteilte Identifier ersetzt werden. Dann kannst Du zumindest schon mal eine Authentifizierung durchführen. Die Daten der API müssen dann individuell pro Anbieter und Modul ausgewertet werden.

Ja das kann sein, da es aber der Sinn ist dann eine Lösung für alle in Form eines Moduls zu erstellen ist das auch ein Ansatz für PHP Module, daher kann das im PHP Modul Bereich diskutiert werden oder Du fragst konkret zu dem Dienst der eingebunden werden soll.

Danke Fonzo,
jetzt habe auch ich es verstanden.:banghead: -> :wink:

… eine ordentliche Doku macht IMHO aber trotzdem Sinn.
Am liebesten so wie in der Vergangenheit mit entsprechend relevanten Codezeilen.
Weiters gibt auch noch Leute welche mit Modulen nix am Hut haben und ganz old school mit Scripten arbeiten.

bb

Das stimmt, es gibt ja aber die Möglichkeit einen Webhook zu nutzten im Fall von OAuth wäre ein PHP Modul schon sinnvoll, da Oauth dann ja grundsätzlich von allen Nutzern genutzt werden kann die diese Schnitstelle nutzten.
Aber wenn Du ein Simples Beispiel hast für einen Dienst der OAuth nutzt und an IPS angebunden werden soll, dann kann man da auch ein paar Zeilen Doku zu schreiben. Locative gibt es ja wohl nicht mehr an dem Beispiel war das gut nachvollziehbar.

Die relevanten Codezeilen findest Du hier.

Servus
Nein, ich habe kein Beispiel und soweit (zum Glück) auch keinen Bedarf.
Dieses OAuth Dingens ist nur nach Installation der diversen Alexa Module aufgetaucht, da wollte ich mich natürlich schlau machen für was das Ding denn nun ist und was man damit machen kann.
Ganz grob konnte ich es mir ja vorstellen, etwas genauer hast du es dann ja oben erklärt.

  • Schönen Dank dafür übrigens.-

Bleibt aber das die offizielle IPS Doku leer ist.
Das sollte für von IPS zur Verfügung gestellte Module die Referenz sein. Auch wenn es gut gemeint ist, Links nach irgendwo ersetzen keine Doku.

gruß
bb

Ich habe Axel37 danach gefragt; er hat keinen Identifier erhalten.

Was muss man jetzt bei Discovergy erfragen/einreichen damit die wiederum wissen, was gebraucht wird und richtig antworten können?

Und… wie/wo explicit wird das dann in IPS eingetragen?

Die Daten die notwendig sind stehen in der Regel in der Dokumention der OAuth Schnittstelle des Anbieters. Hierbei ist es auch davon abhängig ob dann IP-Symcon als OAuth Server oder als OAuth Client auftritt.

Bei dem OAuth Verfahren existiert eine feste Verbindung zwischen dem OAuth Anbieter und dem IP-Symcon Server so das klar ersichtlich ist das es sich hier um IP-Symcon handelt. Jede OAuth Anwendung hat eine eigene Redirect URL, diese wird von IP-Symcon vergeben und Dir dann per Email mitgeteilt.

Die Funktionsweise von OAuth ist unter So funktioniert OAuth 2 ausführlich beschreiben.

Die Daten sind immer gleich, diese müssen beim Anbieter hinterlegt werden


EndpointURL (HTTPS): https://oauth.ipmagic.de/forward
Deine ClientID: <individuelle ClientID pro OAuth Anbieter, diese wird von IP-Symcon mitgeteilt>
Dein ClientSecret: <persönliches ClientSecret, wird von IP-Symcon mitgeteilt>
AuthURL: https://oauth.ipmagic.de/authorize
TokenURI: https://oauth.ipmagic.de/access_token
GrantType: Auth Code Grant

Die Daten werden einerseits auf Anbieterseite hinterlegt wie EndpointURL, AuthURL usw.
Wichtig das ClientSecret ist streng geheim und wird beim Anbieter hinterlegt, dies dient der Authentifizierung von IP-Symcon als Software. Dies ist also sonst niemand bekannt außer dem Anbieter, IP-Symcon und dem der dies eingerichtet hat.

Deine individuelle ClientId dient dazu von IP-Symcon einen Session Token anzufordern. Diese Client ID ist öffentlich einsehbar weil ja auch in deinem Quellcode hinterlegt, ist aber für jeden anderen der kein IP-Symcon benutzt vollkommen nutzlos, da nur IP-Symcon autorisiert ist Anfragen an den Server zu schicken und auch nur IP-Symcon einen Antwort durch die API an die Redirect URL erhält, die dann an Dein System durchgereicht werden. Somit ist dann also jeder IP-Symcon User, der dieses Modul mit diesem ClientID nutzt in der Lage mit IP-Symcon seinen für ihn spezifischen Sicherheit Token beim Anbieter anzufragen um mit IP-Symcon mit der Schnittstelle zu kommunizieren.

Wie dies funktioniert siehst Du im OAuth Test Modul, dies kann als Vorlage benutzt werden. Du musst fürs erste nur die GUID in module.json durch eine eigene GUID ersetzten wenn Du das als Vorlage für ein eigenes Modul nimmst. Siehe hierzu Beschreibung in Bibliotheken. Eine GUID kannst Du selber generieren indem Du einen GUID Generator nutzt. Im GUID Generator müssen die Optionen „Braces“, „Uppcase“ und „Hyphens“ aktiviert sein.

Anschließend tauscht Du den Indentifier in Zeile 7 des OAuth Moduls durch den von Dir zugewiesenen Identifier, der Dir von IP-Symcon der Email zugesandt worden ist, aus.

Als Beispiel wenn Du z.B. einen Custom Skill bei Amazon erstellen würdest mit einem angebundenen PHP Modul, den Du dann für alle IP-Symcon Nutzer per Account Linking nutzbar machen willst müstestet Du Dich bei Amazon als developer registrieren und dann auf der entsprechenden Seite die Daten eintragen. Wo die Daten dann im Detail eingetragen werden ist von OAuth Anbieter zu Anbieter unterschiedlich.

Ich habe mich direkt an api@discovergy.com gewendet und auf meine Fragen folgende Rückmeldung und einen Beispiel-Client erhalten ( -> kann mir jemand sagen, wie man den Beispiel-Client benutzt? Scheint Java zu sein).

DiscovergyAPIClient.zip (228 KB)

· Benötigt man von Ihnen eine Freischaltung zur Nutzung der API? – Wenn ja, dann möchte ich diese hiermit erfragen.
A: Keine Aktivierung erforderlich

· In der API-Doku (Beispiele) wird ein Client-Name „myOwnClient“ als Beispiel verwendet. Ist das ein statischer Eintrag oder ist dieser beliebig oder muss den die Clientsoftware (in diesem Fall IPS) berechnen?
A: Beliebiger Wert

· In der API-Doku (Beispiele) sieht man sehr oft den identischen TimeStamp. Bedeutet dies, dass man den TimeStamp der ersten Abfrage immer wieder verwenden muss? (Sie merken mir fehlt es hier noch etwas an Hintergrundwissen).
A: Identische Zeitstempel werden nur zum Beispiel verwendet.
· Ich habe mit einem befreundetem PHP-Programmierer bereits ein Skript geschrieben. Wir bekommen auch einen Token, aber bei der Abfrage der „avaliable METERs“ stoßen wir auf eine Fehlermeldung „unauthorized“. Leider können wir uns nicht erklären, was die Ursache dafür ist
A: Verwenden Sie Beispiel-Client und vergleichen Sie die generierten Anfragen.
· Ich habe mein Skript und die Frage nach dem og. Problem auch im Forum von IPS (Discovergy API) eingestellt. Wäre es möglich das Ihre API-Kollegen in diesem Forum ebenfalls auf Fragen antworten?

· Haben Sie ein Programmbeispiel für den Zugriff auf die API? (idealerweise PHP, aber .NET oder C#,…. Helfen auch).
· In welcher Frequenz darf man auf die API zugreifen? Hintergrund: Zur Erstellung einer Verbrauchskurve in IPS würde ich gerne jede Sekunden Verbrauchsdaten abfragen. Oder kann man das geschickter auslesen (Verbrauchsdaten über einen Zeitraum als z.B. JSON)?