OAuth für Adapter

OliverIO

also ich würde das in einem node project erst mal nur in vs code testen.
da hast du viel besser debugging möglichkeiten.
du musst ja nicht gleich irgendwelche datenpunkte beschreiben, da reicht ja erst mal das bekannte console.log

du willst ja erst mal die grundlegende kommunikation testen und was dann da von bosch wieder zurückkommt,
du hast jetzt einen single ke id, das wurde in dem einen issue auch irgendwo mal erwähnt.
interessant wäre jetzt der nächste schritt. das müsste das sein, wo jetzt diese chrome extenstion zum einsatz kommt. da ist mir die funktionsweise noch nicht ganz klar.
besonders viel code ist da nicht drin, 2 relevante dateien

background.js
hier wird wohl der netzverkehr gescannt und dann, wenn es um eine bestimmte url geht, wird einfach der header "Location" entfernt. der enthält ein redirect, so das die Anmeldung zu einer bestimmten Seite geht. also hier wird entfernt

const CUSTOM_RULE_ID = 1

chrome.declarativeNetRequest.updateDynamicRules({
    removeRuleIds: [CUSTOM_RULE_ID],
    addRules: [
        {
            id: CUSTOM_RULE_ID,
            priority: 1,
            action: {
                type: "modifyHeaders",
                responseHeaders: [ {
                    operation: "remove",
                    header: "Location"
                } ]
            },
            condition: {
                "urlFilter": "|https://prodindego.b2clogin.com/prodindego.onmicrosoft.com/oauth2/authresp|",
                "resourceTypes": ["main_frame"]
            },
        }
    ],
});

und
constent-script.js
Im contentscript wird dagegen der seiten inhalt nach der regex gescannt und wenn es ein treffer gibt, dann wird die seite https://my.home-assistant.io/redirect/oauth aufgerufen, so kommt das token dann dort an. wie zuvor schon mal geschrieben weiß ich nicht was das für eine seite ist, lokal oder bei home-assistant in der cloud, keine ahnung. ich vermute es ist lokal und so kommt dann der token im "adapter" an und kann dort weiterverwendet werden.

const urlRegex = /"com\.bosch\.indegoconnect%3a%2f%2flogin(.*)"/;

let result = document.body.innerHTML.match(urlRegex);
if (result) {
    redirectUrl = "https://my.home-assistant.io/redirect/oauth" + decodeURIComponent(result[1]);
    console.log("Redirecting to HA", redirectUrl);
    window.location.href = redirectUrl;
}

und ein manifest.json

{
    "name": "HomeAssistant Indego authentication helper",
    "version": "1.0",
    "description": "Handles the Bosch SingleKey ID OAuth response when adding the Indego component to HomeAssistant.",
    "manifest_version": 3,
    "action": {
        "default_popup": "popup.html"
    },
    "permissions": [
        "declarativeNetRequest"
    ],
    "host_permissions": [
        "https://prodindego.b2clogin.com/*"
    ],
    "background": {
        "service_worker": "background.js"
    },
    "content_scripts": [ {
        "matches": ["https://prodindego.b2clogin.com/prodindego.onmicrosoft.com/oauth2/authresp"],
        "js": ["content-script.js"]
    } ]
}

Codierknecht

@oliverio
Klingt alles ein bisschen nach "von hinten durch die Brust ins Auge"

OliverIO

@codierknecht

genau
mit node kannst du ja ebenso browser spielen
und den redirect abfangen und das übermittelte token dann entsprechend weiter verwenden

apollon77

@codierknecht Ja, nein vllt

Am Ende gibt es zwei verschiedene Varianten bezüglich OAuth. Bei Netatmo ist es so das jeer User einen eigenen Account hat und damit nen eigenen Client Secret und so. Hier ist es generisch gelöst und keine Dienste der ioBroker GmbH aktuell dabei.
Bei OAuth springst Du zu einer Seite des Anbieters zum Login und dann zurück auf einen eigenen Server. Das Problem ist dieser "eigene server" den jeder Adapter auf machen müsste. Um das zu vermeiden haben wir etwas generisches in Admin eingebaut das man einen Link bekommen kann und wenn diese Seite aufgerufen wird dann wird der inhalt per Message an den Adapter gesendet der dann die Daten prüft. Am Ende funktioniert das weil das Redirect Ziel nicht aus dem Internet erreichbar sein muss, sondern nur dein Browser es können muss.

Bei den meisten anderen - ich bin ehrlich ich habe nicht alles hier gelesen - ist es aber so as es EINEN zentralen client-id/secret gibt und nicht pro user. Der Fall ist komplexer und benötigt - um nicht die sicherheit komplett zu torpedieren - einen server der das managed. Je nach Adapter kann man sicher mit Bluefox reden ob er soetwas zentral aufsetzen kann, aber das sind immer Detailfragen.

OliverIO

@apollon77 sagte in OAuth für Adapter:

Ja, nein vllt

@Codierknecht

Ich hab hier so das Gefühl, das es auch ohne Server geht.
Aber codierknecht hat ein Account und kann das nur ausprobieren.

Die erste Stufe ist schon geschafft und aus den Login-Daten wurde ein Single Key ID gemacht.
Wenn ich es recht sehe muss in der nächsten Stufe aus dem Single Key ID ein Authorisierungstoken gemacht werden, was man dann speichern kann und dann im Anschluss für Abruf/Zugriff als verwendet werden kann.

Codierknecht

@oliverio
Offenbar regelt Bosch das alles über Azure AD.
Ich habe mich mal an den Kommentaren zum Issue #171 orientiert.

Klappt noch soweit.
Rufe ich das auf, komme ich zum Login für SingleKey ID. Dort melde ich mich mit meinem Account aus der Indego-App an.
Zurück erhalte ich eine augenscheinlich leere Seite, die erst im Quelltext einiges offenbart.
An Schritt 2) komme ich dann bereits nicht mehr weiter.
Wenn ich - wie beschrieben - den "code" aus der Login-Antwort einsetze, erhalte ich

{
    "error": "invalid_grant",
    "error_description": "AADB2C90090: The provided JWE is not a valid 5 segment token.\r\nCorrelation ID: 5799103e-f219-4d2d-a06f-f2e2177ecd0c\r\nTimestamp: 2023-10-31 14:08:37Z\r\n"
}

Der "code" hat offenbar nicht das erwartete Format.
Was bei der Antwort in "state" zurückkommt ist Base64 codiert und hat schon eher das gewünschte Format.

{
  "SID": "x-ms-cpim-rc:1d213be5-7a8a-4689-b67b-9c2478254443",
  "TID": "9028d52d-a722-4a1e-a508-6881ddfd0e5e",
  "TOID": "b8113681-aef4-474b-9ba2-25294caa48fc"
}

Funzt aber genau so wenig

Ich persönlich wäre durchaus bereit, einmalig bei der Inbetriebnahme des Adapters den "code" aus dem Quelltext der Login-Antwort auszulesen und im Adapter zu hinterlegen.
Wenn der dann läuft, kann er sich ja regelmäßig ein neues Token besorgen (sobald man herausbekommen hat wie).

Mühsam ernährt sich das Eichhörnchen ...

OliverIO

@codierknecht

was passiert wenn du den loginprozess im browser normal fortsetzt?
also, erst die developer tools des browser mit f12 öffnen

diesen link im browser wählen
https://prodindego.b2clogin.com/prodindego.onmicrosoft.com/b2c_1a_signup_signin/oauth2/v2.0/authorize?redirect_uri=com.bosch.indegoconnect://login&client_id=65bb8c9d-1070-4fb4-aa95-853618acc876&response_type=code&scope=openid offline_access https://prodindego.onmicrosoft.com/indego-mobile-api/Indego.Mower.User
dann auf single key klicken
auf der folgeseite deine login daten eingeben

-> theoretisch müssten dann eine antwort kommen(im networktab der developer tools schauen), aber der browser macht nix mehr weiter,
weil in der antwort im response header sich eine Anweisung befindet, die sich

Location com.bosch.indegoconnect://login/?code=ABCDEFG

nennt. Der browser stoppt deswegen, weil er die Adressierung com.bosch.indegoconnect://login/?code=ABCDEFG
nicht versteht. normalerweise steht da eine http-adresse drin und der browser versucht dann die seite aufzurufen.
wenn aber der rasenmäher diese antwort erhält, dann weiß er, das er seine Mäher-Software aufrufen muss und übergibt dann den code.
ABCDEFG müsste dann das token für die Datenabfrage des Rasenmähers sein.

kannst du das nachstellen?
Wenn das so funktioniert, dann bauen wir den Kommunikationsablauf in node nach und brauchen dann kein chrome-extension

Codierknecht

@oliverio

Wenn man diesen Code Bas64-dekodiert, scheint es sich um etwas gepacktes zu handeln:

Ich könnte mal die Redirect-Uri auf ein Script auf meinem Webserver legen.
Wenn ich das Konzept richtig verstanden habe, sollte die Antwort ja dann dahin gesendet werden.
Nur um zu sehen, ob da etwas sinnvolleres ankommt.

Das wäre ja dann auch die Stelle, an der ggf. Bluefox ins Spiel kommt. Natürlich könnte ich das für den Adapter auch auf meinem Server belassen - so denn etwas sinnvolles zurückkommt. Aber dann gibt's ja wieder das Problem, dass Daten an dem Anwender unbekannte Stellen gesendet werden. Der eine oder andere wird sich möglicherweise wundern.

Und ich befürchte, dass über kurz oder lang auch andere Hersteller nachziehen.

OliverIO

@codierknecht

hast du mal einen request, für die api, wie man daten zu einem rasenmäher dann abfragen kann?

Codierknecht

@oliverio
Noch nicht. Müsste im Code des Adapters zu finden sein. Bis dahin hatte ich mich noch nicht vorgearbeitet, da ja zunächst die Verbindung zustande kommen muss.

Codierknecht

@OliverIO
Müsste in etwas sowas hier sein:
https://api.indego-cloud.iot.bosch-si.com/api/v1/alms/22460xxxx/predictive/lastcutting

Ich probier mal Punkt 2) mit dem ellenlangen Code aus der Antwort ...

Codierknecht

@codierknecht sagte in OAuth für Adapter:

Ich probier mal Punkt 2) mit dem ellenlangen Code aus der Antwort ...

Das dürfte passen

{"error":"invalid_grant","error_description":"AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: 1698770380, Grant issued time: 1698768768, Grant expiration time: 1698769068\r\nCorrelation ID: 5dd96960-a86e-4c4a-8c68-030f230e784f\r\nTimestamp: 2023-10-31 16:39:40Z\r\n"}

Sieht also so aus, als könnte das durchaus funktionieren.
Fehlt also noch ein Weg, die Antwort mit dem Code auch in den Adapter zu bekommen, damit der sich dann ein Access-Token holen kann.

Werde in den nächsten Tagen mal weiter testen. Für heute muss ich erstmal Schluss machen.

Danke Dir erstmal für Deinen Input

OliverIO

@codierknecht

hab mir mal den ha code angeschaut. sind noch ein paar schritte notwendig

login -> single key ID
single key id -> application token
application_token -> session token
session_token -> daten abrufen

1+2 muss man nur einmalig machen
3) immer dann wenn die session abgelaufen ist, da find ich die methode noch nicht
4) ist dann der konkrete abruf. das ist ein normaler webrequest, bei der im Header dann Bearer <Session-token> steht

die ganze datenlogik steht dann auch in einer anderen bibliohtek
hier bspw die logik für abruf aller mäher im account
https://github.com/jm-73/pyIndego/blob/cf45b9cfd7c2e56edfe5d3a8e2f2a6b0ad007c23/pyIndego/indego_client.py#L35

Codierknecht

Hab's gerade doch noch mal versucht.
Wäre ja auch zu simpel, einfach die redirect_uri umzubiegen.

The redirect URI 'https://boschindego.dev2dev.de/authenticate.php' provided in the request is not registered for the client id '65bb8c9d-1070-4fb4-aa95-853618acc876'.
Correlation ID: 9b66ddb5-8aa9-465c-88a3-efdb3c003a2b
Timestamp: 2023-10-31 22:00:19Z

Läuft das dann tatsächlich darauf hinaus, dass der Anwender über den Link die Anmeldeseite besucht und dann in den Developer-Tools des Browsers den Code herausfummelt?

Bosch sagt zu meiner Frage, ob's ein angepasstes API geben wird:

Unsere digitalen Anpassungen an Google Home sind abgeschlossen und somit betriebsbereit, wir warten derzeit auf die Freigabe von Google Home, diese liegt leider nicht in unserem Einflussbereich.

Solange Google noch nicht betriebsbereit ist können Sie auch IFTTT nutzen.

Wenn Sie die Plattform nutzen möchte, gehen Sie einfach auf www.ifttt.com/indegoconnect und erstellt ein kostenloses IFTTT-Konto. Angezeigt werden dann sofort eine Reihe vordefinierter Applets, die man einfach ein- und ausschalten kann. Über das Einschalten der gewünschten Applets kann der Verwender diese einfach mit seinem Bosch Smart Gardening-Konto verknüpfen, indem Sie dieselbe E-Mail-Adresse für beide Anwendungen verwenden. Ist das gewünschte Applet nicht vorhanden, lässt sich dieses nach den entsprechenden Regeln kurzerhand selbst erstellen. So kann jeder sein Zuhause und die Gartenpflege individuell automatisieren.

Der Service ist kostenlos, ein Software-Update ist für die Nutzung nicht erforderlich.

IFTTT zu nutzen um im ioBroker auf den Mäher zugreifen zu können ist aber irgendwie auch 3x um die Ecke.

Codierknecht

Aber prinzipiell funktioniert der Salat dann

Codierknecht

@OliverIO
Ich habe jetzt den folgenden funktionierenden Weg herausgefunden:

Über den Link in 1) rufe ich die Login-Seite für SingleKey ID auf.
Dabei aktiviere ich die Developer-Tools im Browser.
Kommt die Antwort zurück, kopiere ich mir aus den Developer-Tools den zurückgelieferten Code.
Dieser Code könnte dann vom Anwender im Adapter als primärer Login hinterlegt werden.
Im Script verwende ich diesen Code, um ein access_token und ein refresh_token zu erhalten.
Mit dem access_token als bearer kann ich das API abfragen.
Zu gegebener Zeit muss das Token aktualisiert werden.
Dazu verwende ich das oben erhaltene refresh_token und erhalte dadurch sowohl ein neues access_token als auch ein neues refresh_token.
Läuft der Adapter, sollte er also zyklisch seine Token aktualisieren.

Jetzt muss ich das nur noch in Code gießen

Codierknecht

@apollon77
Nur der Vollständigkeit halber:

@codierknecht sagte in OAuth für Adapter:

Hab's gerade doch noch mal versucht.
Wäre ja auch zu simpel, einfach die redirect_uri umzubiegen.

The redirect URI 'https://boschindego.dev2dev.de/authenticate.php' provided in the request 
is not registered for the client id '65bb8c9d-1070-4fb4-aa95-853618acc876'.           
Correlation ID: 9b66ddb5-8aa9-465c-88a3-efdb3c003a2b
Timestamp: 2023-10-31 22:00:19Z

Ihr seid damit natürlich raus.
Wenn man das Redirect nicht umbiegen kann, sind die Server der ioBroker GmbH natürlich aus dem Rennen.

OliverIO

@codierknecht

also grundsätzlich kann man alle webrequests mit node durchführen.
man könnte axios verwenden oder wenn man es sich noch einfacher machen möchte fetch
fetch ist ein befehl, der im browser zur verfügung steht.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

mit dieser bibliothek steht die auch in node, also im adapter zur verfügung
https://www.npmjs.com/package/node-fetch

wenn du im browser auf einen request rechts-klickst, gibt es diverse kopier-optionen
unter anderem auch als node-fetch.
darüber kannst du dann den web-request 1:1 als befehl kopieren und in deinem skript einfügen.
klar muss man natürlich die parameter mit variablen ersetzen. ein bisschen logik drum rum und sicherlich auch ein paar von den headers wegstreichen, die nicht wirklich sinnvoll sind.
da muss man allerdings ein wenig experimentieren, da der server natürlich alles auswerten könnte und dann feststellen könnte, das das kein original request von der webseite ist.
auch sollte man definitiv dem fetch einen aktuelle user-agent-string mitgeben, das ist meist das stärkste kriterium, an dem man feststellen kann, das das kein browser ist.
was node da überhaupt standardmäßig sendet, weiß ich nicht.

OliverIO

@codierknecht said in OAuth für Adapter:

Wenn man das Redirect nicht umbiegen kann

wenn ich es richtig verstanden habe, wird der redirect nirgendwo anders funktionieren als im rasenmäher selbst.

wie schon mal geschrieben, steht in der location anweisung ja auch keine webseite drin,
sondern eine technische anweisung, die im rasenmäher dazu führt, eine applikation (die interne rasenmäher applikation) aufzurufen.

Location com.bosch.indegoconnect://login/?code=ABCDEFG

den redirect müssen wir aber nicht folgen, wir müssen aus diesem wert ja nur den code extrahieren und haben dann alles. der rest müsste dann so wie früher funktionieren

Codierknecht

@oliverio sagte in OAuth für Adapter:

den redirect müssen wir aber nicht folgen, wir müssen aus diesem wert ja nur den code extrahieren und haben dann alles. der rest müsste dann so wie früher funktionieren

So ist der Plan

Ich versuche gerade, das irgendwie in den Code des Adapters zu bekommen.
TS/JS ist allerdings nicht meine Kernkompetenz und das Objektmodell eines Adapters muss ich mir auch erst erschließen. Könnte also 'ne Weile dauern. Man lernt halt nie aus.

NEWS

OAuth für Adapter

Support us

775
Online

31.6k
Users

79.6k
Topics

1.3m
Posts

NEWS

OAuth für Adapter

Support us

775Online

31.6kUsers

79.6kTopics

1.3mPosts

775
Online

31.6k
Users

79.6k
Topics

1.3m
Posts