tester gesucht: alexa-fhem reverse proxy & offizieller skill

Begonnen von justme1968, 16 Januar 2018, 17:47:54

Vorheriges Thema - Nächstes Thema

justme1968

hallo zusammen,

der test wird sich leider noch etwas verzögern da mir zwei dinge dazwischen gekommen sind. ein mal etwas privates und zum anderen eine mail von amazon dazu beta test das notifikation api.

mit dem notification api ist es möglich nachrichten an einen echo zu schicken. vermutlich wird nur das vorhandensein angezeigt und man muss dann zurück fragen. aber immerhin.

die notifications möchte ich gerne noch in den test mit einbauen. leider funktioniert es noch nicht und ich weiss nicht ob ich etwas falsch mache, die doku fehlerhaft ist, oder ob noch etwas freigeschaltet werden muss.

die echo show und spot können scheinbar zumindest text nachrichten direkt anzeigen. das kann ich aber nicht testen da ich die nicht habe.

ich melde mich sobald es mehr gibt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Groej

Hallo,

super Idee das Ganze. Ich hab meinen Smarthome Skill zwar im Moment nicht in Betrieb weil ich vor kurzem den Raspi gewechselt habe aber wollte ihn wieder in Betrieb nehmen.

Hab einen Echo Dot und der Spot ist bestellt und soll ja bald kommen.

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Kai-Alfonso

Hallo,

ich würde mich auch gerne zum testen anbieten. Ich selber nutze schon recht lange den Alexa Smarthome Skill und für meine Rollladen den Custom Skill. Zu Hause habe ich ein Dot und ein normales Echo. Gute Idee übrigens - ich bin jetzt nicht so der Fan von Smarthome Komponenten, die eine Cloud benötigen und Alexa war da eine riesige Ausnahme, die ich gemacht hat. Ich mach halt nicht gerne Port Forwarding :-)
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

flipkill

Hallo,

auch ich kann gerne als Tester dienen :) Kann sowohl eine feste IPv4 als auch eine feste IPv6 bieten :)

Gruß Jan

steve6502

Ich wäre auch dabei. Anbindung ist ip4&6 bei Fritzbox mit täglich wechselnder IP.

Einen Echo Spot zum Anzeigen von Nachrichten habe ich auch hier stehen. Übrigens tauchen beim "normalen" Echos dann nicht einfach "Cards" in der Alexa App auf? Oder sind Cards und Notification zwei verschiedene Dinge?

Gruß S.

steve6502

@justme1968 btw wäre es nicht am einfachsten, die bestehende Lambda Funktion zu lassen und nur um einen db basierten lookup für Host und Port zu erweitern?

Wenn die Persistenz dafür eine z.b. eine DynamoDB von AWS ist, dann brauchst Du nur noch eine Seite hosten, die die Verknüpfung des Amazon-Kontos mit der Host-Port-Angabe abfrägt und persistiert. Diese Seite selbst nutzt Oauth naheliegender Weise LWA dann hast direkt die Identität um den Lookup zu machen.

Was in der Tat immer noch gemacht werden müsste ist die Port Freigabe.

Gruß S.

justme1968

abgesehen davon das ich nicht sicher bin ob es wirklich einfach wäre... es hätte die folgenden nachteile:

- port forwarding immer noch nötig
- ipv4/ipv6 problem immer noch da
- zentrale datenhaltung
- irgend eine art von user registrierung/abmeldung nötig
- zusätzliche kosten durch DynamoDB

die angedachte proxy lösung hat dagegen den vorteil:
- kein port forwaring nötig
- keine registrierung nötig
- keine persistente datenhaltung
- der benutzer startet bei sich zuhause den dienst wenn er ihn verwenden möchte und stoppt ihn wieder
  wenn er das nicht mehr möchte.

das es weder eine registering noch eine permanente datenhaltung gibt halte ich aus mehreren gründen für wichtig:
- gebot der datensparsamkeit
- was nicht gespeichert ist kann nicht missbraucht werden
- wenn nichts gespeichert ist gibt es auch keine Verantwortlichkeit für gespeicherte daten

im übrigen geht das ganze im prinzip schon. ich hatte meine lokale instanz schon so laufen. d.h. das forwarding
   problem (inklusive ipv6) ist gelöst. ich muss nur noch schauen wie das skaliert.


die eigentliche herausforderung ist der oauth teil und der ist bei beiden varianten mindestens gleich aufwändig.

ich warte aktuell immer noch auf eine vernünftige antwort von amazon wegen dem notification api. die rückmeldung die ich bisher bekommen habe ging leider komplett am thema vorbei.


notification und cards sind erst mal zwei verschiedene dinge. ein skill kann aktuell nur aktiv werden wenn der benutzer per sprache irgend eine interaktion startet. die antwort darauf kann dann eine gesprochene ausgabe sein oder ein card die dann bei passendem device oder in der app angezeigt wird.

die notification erlauben es einem skill von sich aus (ohne das der anwender die interaktion gestartet hat) aktiv zu werden und dem benutzer anzuzeigen das es 'etwas neues gibt'.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

steve6502

#22
Hi,

kann gut sein, dass ich nicht komplett verstanden habe wie deine Lösung genau funktioniert, aber ich sehe zwei Herausforderungen:

1. Skalierung: der RProxy muss viel incoming Connections halten, das skaliert viel schlechter als eine Lambda Funktion die dipatched.

2. Zuordnung der Connections zu einem Alexa Request ohne zentrale Datenhaltung. Wie soll das denn gehen. Wenn der Skill installiert wird erhält
das Alexa System ein Access Token des jeweiligen OAuth Providers z.B. LWA. Den Token kann man validieren (egal wo in der Aufrufkette) und zum
Abrufen bestimmter Profil Informationen benutzen (Amazon UserId bei LWA). Alexa-Fhem kennt aber das Access Token aber nicht und dem lokalen alexa-Fhem die Amazon ID mitzugeben reicht nicht, weil die ja nicht sicher ist. Die bekommt jeder, der auch LWA nutzt. Vielleicht sogar noch einfacher.

Wie also soll die zuordnung eines bestimmten Connects von aussen zu eine request vom Alexa Backend (lambda) funktionieren?

Gruß S.

justme1968

um 1. mache ich mir gedanken wenn es ein paar hundert oder tausend anwender gibt. bis dahin sollte das problemlos skalieren.

2. also.. das ist ganz einfach :)

der witz bei oauth ist ja gerade das man zu keinem zeitpunkt einem fremden system seine login daten übermitteln muss, sondern die autorisierung verteilt d.h. vom system das den benutzer kennt direkt selber gemacht wird. es gibt keinen grund das verteilen nicht noch weiter bis hin zum client zu machen. dann geht das ohne feste accounts, ohne registrierung und ohne shared secrets. nur mit einer jeweils lokal erzeugten id. diese muss der anwender ein einziges mal in seinem fhem system nachschauen und genau ein mal bei der initialen oauth anmeldung in die login maske eingeben.

unterm strich läuft es darauf hinaus das die zentrale datenhaltung durch eine gerade ausreichende menge an informationen in einem teil des token selber ersetzt wird. der restliche sensitivere teil des tokens ist jeweils mit einem key den nur der betreffende client kennt verschlüsselt. da jeder client nur seine eigenen daten entschlüsseln muss, gibt es keine verteilten schlüssel. da ein gutes kryptographisches system im prinzip nur von der sicherheit der schlüssel abhängt und hier die schlüssel niemals woanders als bei jedem einzelnen benutzer selber liegen funktioniert das ganze.

im folgenden gehen die bezeichnungen für die unterschiedlichen token arten etwas durcheinander. das ist aber in diesem fall egal weil die behandlung im prinzip gleich ist und jeder user lokal nur seine eigenen token verifiziert.


der oauth provider ist eben nicht mehr lwa sondern alexa-fhem bzw. der proxy. die token erzeugt aber jede installation selber. und validiert diese auch. der token besteht im prinzip aus mehreren teilen. einen teil der die zuordnung zu einem bestimmen benutzer erlaubt und einen teil der die autorisierung enthält. beides ist so verknüpft das beide teile nur genau in dieser kombination zusammen gültig sind.

wenn der anwender seinen lokalen dienst startet meldet er sich mit dieser id am proxy an. der proxy muss nur den id teil des tokens 'verstehen' um das komplette event dem richtigen empfänger zuzuordnen. jeder teilnehmer ist dann selber dafür verantwortlich auch den authorisierungs teil des tokens zu prüfen. den er ja auch selber erzeugt hat. das ganze funktioniert weil jeder nur seine eigenen daten prüft und nicht für jemand anderen. es müssen also keine secrets verteilt werden die es jemand anderm ermöglichen einen gefälschten authorisierungs teil für jemanden anders zu erzeugen.


auch der refresh der token läuft genau so ab. der proxy hat gerade genug information um den request zum richtigen client durch zu stellen. dieser erzeugt den neuen token und sendet ihn über den proxy zurück.


wenn der benutzer seine verbindung wieder zu mache gibt es keine zuordnung eines events zu einer existierenden verbindung mehr und amazon bekommt vom proxy einen 'client nicht erreichbar' fehler.


es gibt keine id/token/sonstige daten die besonders geschützt werden müssen. es sind immer mindestens zwei komponenten nötig damit ein event auch beim client ankommt. selbst wenn das token verloren geht erzeugt man sich ein neues und aktiviert den skill neu.


die id an sich ist nicht schützenswert. auch bei amazon nicht. zum einen ist sie nicht  mit einer identität oder sonstigen daten verknüpft, zum anderen bekommt jeder skill bei jeder aktivierung eine neue user id von amazon. es ist also nicht möglich den benutzer über mehrere anmeldungen hinweg zu verfolgen.

jeder der ein lwa token hat kann dies gegenüber dem amazon server verifizieren und bekommt eine zugehörige benutzer id. man kann also die id auch gleich als sichtbares teil des token haben.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

steve6502

okay verstanden, damit musst Du allerdings wirklich selber einen OAuth Provider bauen, den man so auch nicht "von der Stange" nehmen kann, weil Du die Token Erzeugung dezentral delegierst. Das ist sozusagen "der Preis" auf die zentrale Datenhaltung verzichten zu können, weil Du die gleiche Information quasi opaque im Token selbst unterbringst.

Clever, aber etwas aufwändiger als OAuth ala carte.

Gruß S.

coolice

Zitat von: justme1968 am 09 Februar 2018, 17:11:30
um 1. mache ich mir gedanken wenn es ein paar hundert oder tausend anwender gibt. bis dahin sollte das problemlos skalieren.

2. also.. das ist ganz einfach :)

der witz bei oauth ist ja gerade das man zu keinem zeitpunkt einem fremden system seine login daten übermitteln muss, sondern die autorisierung verteilt d.h. vom system das den benutzer kennt direkt selber gemacht wird. es gibt keinen grund das verteilen nicht noch weiter bis hin zum client zu machen. dann geht das ohne feste accounts, ohne registrierung und ohne shared secrets. nur mit einer jeweils lokal erzeugten id. diese muss der anwender ein einziges mal in seinem fhem system nachschauen und genau ein mal bei der initialen oauth anmeldung in die login maske eingeben.

unterm strich läuft es darauf hinaus das die zentrale datenhaltung durch eine gerade ausreichende menge an informationen in einem teil des token selber ersetzt wird. der restliche sensitivere teil des tokens ist jeweils mit einem key den nur der betreffende client kennt verschlüsselt. da jeder client nur seine eigenen daten entschlüsseln muss, gibt es keine verteilten schlüssel. da ein gutes kryptographisches system im prinzip nur von der sicherheit der schlüssel abhängt und hier die schlüssel niemals woanders als bei jedem einzelnen benutzer selber liegen funktioniert das ganze.

im folgenden gehen die bezeichnungen für die unterschiedlichen token arten etwas durcheinander. das ist aber in diesem fall egal weil die behandlung im prinzip gleich ist und jeder user lokal nur seine eigenen token verifiziert.


der oauth provider ist eben nicht mehr lwa sondern alexa-fhem bzw. der proxy. die token erzeugt aber jede installation selber. und validiert diese auch. der token besteht im prinzip aus mehreren teilen. einen teil der die zuordnung zu einem bestimmen benutzer erlaubt und einen teil der die autorisierung enthält. beides ist so verknüpft das beide teile nur genau in dieser kombination zusammen gültig sind.

wenn der anwender seinen lokalen dienst startet meldet er sich mit dieser id am proxy an. der proxy muss nur den id teil des tokens 'verstehen' um das komplette event dem richtigen empfänger zuzuordnen. jeder teilnehmer ist dann selber dafür verantwortlich auch den authorisierungs teil des tokens zu prüfen. den er ja auch selber erzeugt hat. das ganze funktioniert weil jeder nur seine eigenen daten prüft und nicht für jemand anderen. es müssen also keine secrets verteilt werden die es jemand anderm ermöglichen einen gefälschten authorisierungs teil für jemanden anders zu erzeugen.


auch der refresh der token läuft genau so ab. der proxy hat gerade genug information um den request zum richtigen client durch zu stellen. dieser erzeugt den neuen token und sendet ihn über den proxy zurück.


wenn der benutzer seine verbindung wieder zu mache gibt es keine zuordnung eines events zu einer existierenden verbindung mehr und amazon bekommt vom proxy einen 'client nicht erreichbar' fehler.


es gibt keine id/token/sonstige daten die besonders geschützt werden müssen. es sind immer mindestens zwei komponenten nötig damit ein event auch beim client ankommt. selbst wenn das token verloren geht erzeugt man sich ein neues und aktiviert den skill neu.


die id an sich ist nicht schützenswert. auch bei amazon nicht. zum einen ist sie nicht  mit einer identität oder sonstigen daten verknüpft, zum anderen bekommt jeder skill bei jeder aktivierung eine neue user id von amazon. es ist also nicht möglich den benutzer über mehrere anmeldungen hinweg zu verfolgen.

jeder der ein lwa token hat kann dies gegenüber dem amazon server verifizieren und bekommt eine zugehörige benutzer id. man kann also die id auch gleich als sichtbares teil des token haben.
Hallo, gibt es hier schon was neues?


Gesendet von iPhone mit Tapatalk

justme1968

leider noch nicht. ich hatte die ganze zeit auf antwort von amazon bezüglich des notification api gewartet. wurde aber immer wieder vertröstet. dann hatte ich ziemlich viel anderes zu tun.

sobald wieder etwas luft ist kommt eine erst test version ohne notification api.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

meddie

Hallo,

wie ist denn der Stand aktuell?

Danke
VG Eddie

justme1968

meine eigene version läuft aber es dauert leider noch etwas bis es weiter geht. mir ist etwas dazwischen gekommen. sorry.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Snooper166