Gewünschte ServerID (Nur kleingeschriebene Buchstaben) + Name (Sprechender Name) + Redirect URLs mir per PN schicken.
Ich sende euch das benötigte Client Secret
Ihr richtet alles bei eurem Dienst ein
Sofern sich ein Kunde authentifizieren will, wird er nach seiner Lizenz-Email gefragt und an diese ein Code gesendet
Wir leiten den Kunden auf den Dienst (Redirect URL) weiter und übermitteln den geheimen Schlüssel
Der Dienst muss seine Daten an die Daten URL per POST senden und wir leiten diese an den Endkunden per Symcon Connect an das OAuth Modul weiter
Dokumentation:
Authorize URL: h t t p s ://oauth.ipmagic.de/authorize
AccessToken URL: h t t p s ://oauth.ipmagic.de/access_token
Grant Type: Auth Code Grant
Scope: none
Daten URL: h t t p s ://oauth.ipmagic.de/forward
Sicherheit:
Das ganze Ping Pong verfahren ist laut OAuth2 Protokoll und somit entsprechend den RFCs sicher. Die Anfrage an die /connect Adresse wird anhand des Authorization Tokens im Header verifiziert. Anhand dieses Tokens ist auch der Kunde eindeutig identifizierbar, sodass die Daten an die korrekte Symcon Connect Adresse weitergeleitet werden. IP-Symcon 4.2 lässt über das OAuth Control nur Daten direkt vom Connect Server durch. Sollte also jemand von extern (ipmagic.de) versuchen die /oauth/clientID Adresse aufzurufen, wird dies verweigert. Die oauth Subdomain hat ein gültiges Zertifikat und kann nur über SSL genutzt werden!
Standalone Variante (Client)
Bei der Standalone Variante wird der Client für jeden Nutzer konfiguriert und somit muss ClientID/ClientSecret im Modul eingegeben werden. Außerdem muss die im Modul angezeigt RedirectUri beim API-Provider hinterlegt werden. Dadurch wird auch klar, dass der Client an genau eure Connect-Adresse gebunden wird und ihr jeder beim Standalone Modul sich für die API beim API Provider selber registrieren muss. Bei der normalen Variante (welche präferiert werden sollte) halten wir ClientID/ClientSecret vor und können die RedirectUri generisch halten, da wir das Routing zu euch über den Connect-Dienst vornehmen. Für Prototyping und Sonderfälle (z.B. Mercedes Benz, welche für die API viel Geld wollen) kann die Standalone Variante aber eine gute Wahl sein.
Ihr findet die Referenz Implementation (welche ihr natürlich anpassen müsst) hier:
Oft wird beim OAuth auch eine Privacy Policy verlangt. Bei Amazon ist das z.B. Vorraussetzung. Nur auf das Impressum zu verweisen ist da wohl zu wenig.
Gibt es von IP-Symcon eine Privacy Policy auf die man Verlinken kann?
Da bräuchte man also so was in der Art was am besten von einem Rechtsanwalt aufgesetzt wurde. Da müsste drinnen stehen das IP-Symcon die Email Adresse erfasst um damit die Lizenz zu prüfen und die zugehörige IP-Symcon Connect IP zu ermitteln an die die Daten des Dienstes gesendet werden. Das sich IP-Symcon an den Deutschen Datenschutz hält und mit dem OAuth Endpunkt die Daten zwischen dem Dienst und dem Kunden mit seiner IP-Symcon Installation über IP-Symcon Connect weitervermittelt. Wie auch immer das dann eben im geltenden Rechtsgebrauch formuliert sein muss.
Das ist google_nest. Wenn das aber nicht „deine“ ClientID ist, dann solltest du dich lieber melden, damit du eine eigene bekommst. Ansonsten könnte dein Problem mit dem aktuellen Google Nest Modul bekommen, wenn beide gleichzeitig in Verwendung sind.
Ich habe soeben im ersten Beitrag eine neue Variante hinzugefügt, womit ihr zum Testen/Prototyping einen vollständigen OAuth2 Client direkt in IP-Symcon über den Connect Dienst abbilden könnt. Ihr seid dann nicht darauf angewiesen, dass ich einen Client-Endpunkt erstelle, sondern könnt direkt loslegen. Oder für APIs bei denen wir rechtlich keinen Client-Endpunkt anbieten können, kann damit jeder User selbst seinen eigenen OAuth2 Endpunkt haben.
Sofern ihr ein Modul im Store veröffentlichen wollt, und alle User es „einfach“ bei der Einrichtung haben sollen, empfiehlt sich weiterhin die normale Client Variante bei der wir die ClientID/ClientSecret serverseitig pflegen
@paresy
Ich teste gerade die Variante mit Mercedes. Komme da aber gerade nicht weiter.
Wir haben einen Smart der auch über die app und das Mercedes Portal abrufbar ist.
Projekt ist auf der Developer Seite eingerichtet. Die Redirect-Uri ist bei Mercedes eingetragen.
Wenn ich im Modul „REGISTER“ anklicke kommt im Browser auch die Meldung " Success! You can now close this window. und bei Token steht Yes.
Wenn ich als Test-Uri z.B. diese URL verwende https://api.mercedes-benz.com/vehicledata/v2/vehicles/WXAX533911KXXXXX/resources/soc/ (mit korrekter Vehicle ID natürlich)
bekomme ich nur folgende Meldung „{„errorMessage“: „Internal Server Error“, „statusCode“: „500“}“
Ist jemand weiter gekommen, ich stehe vor derselben Fehlermeldung wie da8ter {„errorMessage“: „Internal Server Error“, „statusCode“: „500“} mit dem Standalone-Modul von parsey?
Den Quellcode editieren übersteigt meine Fähigkeiten
Es geht auch um die Mercedes Me Abfrage…
Habe mich nun auch einmal an dem OAuth System versucht. Ich möchte mit der „Client-Variante“ die sonos API verwenden. Das anfordern des Token funktioniert soweit, allerdings bringe ich es nicht fertig Daten abzufragen.
Hier mein angepasster Code:
Schau dir das mal an: GitHub - symcon/Sonos: Sonos for IP-Symcon Da haben wir damals schon was angefangen - vielleicht hilft es dir. Das Problem wird langfristig aber sein, dass du die Events nicht eingesammelt bekommst - da ist Sonos sehr eigen, wie Sie das implementiert haben.
ich frage mit der Standalone Variante meine Nibe Wärmepumpe ab. Funktioniert gut, das Token ist jedoch nur eine Stunde gültig. Ich würde mit refresh_token gerne ein neues Token abfordern.
Gibt es im Modul dafür eine fertige Funktion?
Hallo,
ich habe ja mittlerweile einen Endpunkt über Symcon Connect, beim Hersteller einen API Zugang beantragt und den auch entsprechend verbinden können. Jetzt verstehe ich nur nicht, wie kann ich Daten an den Anbieter senden und wie der zu mir.
WebHooks gehen so nicht, da dies bei OAuth2 nicht fest definiert ist. Dort gibt es dann normalerweise die Server Variante wie bei Alexa oder Google Assistant. Oder du kannst optimaler Weise einen WebHook pro Client definieren, sodass quasi jeder den WebHook auf seine persönliche Connect Adresse setzen kann. Wenn es nur einen „globalen“ Hook gibt, dann müsstest du einen Online Server anbieten, der die Anfragen verteilt. (Wir können dies nicht wirklich machen, da dies dann je Hersteller Schnittstellenspezifisch ist)
Ich habe offenbar endlich verstanden, dass der oAuth Server NUR die Authentifizierung, nicht aber die Datendurchleitung (in keine Richtung) macht. Erste Tests waren bei mir mittlerweile erfolgreich. Hat jemand ebenfalls Geräte von Wahoo und würde sich zu einem späteren Zeitpunkt für Tests zur Verfügung stellen?