Alexa Smarthome Skill (Payload Version 3)

[Aktor]

Alexa App: Kontoverknüpfung fehlgeschlagen

Erst einmal Danke für die Arbeit der Entwicklung und vor allem der klasse Anleitung! Da steckt sehr viel Arbeit drin, so dass ich als Laie damit gut klar komme.

Trotzdem bräuchte ich bitte Eure Hilfe. Ich habe alles nach der Anleitung aufgesetzt und eigentlich sieht alles gut aus. Reverse Proxy usw. habe ich getestet. Nur leider schlägt trotzdem die Kontoverknüpfung in der Alexa App fehl.

Was mir komisch vorkommt ist, dass das Feld bei "Client Secret" (S.19 in der Anleitung) immer wieder leer ist.
Der Eintrag wird übernommen und die Speicherung bringt auch keine Fehler, aber wenn ich die Seite verlasse und wieder reingehe, ist das Feld wieder leer.

Ist das normal bzw. weiß jemand woran das liegt?

Danke schon einmal im Voraus

[deRainer]

Hallo Aktor,
was heißt den "die Kontoverknüpfung"? Meinst du, dass du den Edomi Skill in der Alexa App nicht aktivieren kannst?
Hatte auch das Problem. Bei mir hat das geholfen

curl https://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/cacert.pem

Das "Client Secret" Feld wird glaube ich standardmäßig immer ausgeblendet. Das heißt aber nichts. Da steht schon was drin. Ist halt "Secret"

[Aktor]

deRainer, Dankeschön.

Es kommt die Meldung "Edomi konnte nicht mit Alexa verknüpft werden".

Ich habe Deinen Tipp durchgeführt und den Edomi-Server neu gestartet. Leider hat dies nichts gebracht. Wenn das mit dem "Client Secret" normal ist, dann wird es das auch nicht sein. Gibt es noch andere Ideen woran es liegen bzw. was ich testen könnte?

[Aktor]

ich habe in den Log Events folgendes gefunden. Weiß jemand wo hier der Fehler liegt bzw. was ich als nächstes testen sollte?


2021-01-16T11:39:07.922+01:00 u'\ufeff{"event":{"header":{"messageId":"b7c06729-c292-4212-bc9a-9430a900847a","name":"AcceptGrant.Response","names pace":"Alexa.Authorization","payl...

u'\ufeff{
"event": {
"header": {
"messageId": "b7c06729-c292-4212-bc9a-9430a900847a",
"name": "AcceptGrant.Response",
"namespace": "Alexa.Authorization",
"payloadVersion": "3"
},
"payload": {}
}
}'


2021-01-16T11:39:07.942+01:00 No JSON object could be decoded: ValueError Traceback (most recent call last): File "/var/task/edomi-aws-lambda-skill-adapter-PLv3.py", line 28, in....

No JSON object could be decoded: ValueErrorTraceback (most recent call last): File "/var/task/edomi-aws-lambda-skill-adapter-PLv3.py", line 28, in lambda_handler return json.loads(response.text) File "/usr/lib64/python2.7/json/__init__.py", line 339, in loads return _default_decoder.decode(s) File "/usr/lib64/python2.7/json/decoder.py", line 364, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib64/python2.7/json/decoder.py", line 382, in raw_decode raise ValueError("No JSON object could be decoded")ValueError: No JSON object could be decoded

[philipp900]

Falls du nur Lampen steuern willst, probier mal meinen neuen LBS, der läuft komplett lokal und erfordert keine Lambda Funktion und keine Kontoverknüpfung.

[Aktor]

ok, danke. Es sieht so aus, als hätte ein Freund den Fehler gefunden. Sobald ich weiß was er gemacht hat, poste ich es hier.

[Jue]

Es kommt die Meldung "Edomi konnte nicht mit Alexa verknüpft werden".

Ich habe Deinen Tipp durchgeführt und den Edomi-Server neu gestartet. Leider hat dies nichts gebracht. Wenn das mit dem "Client Secret" normal ist, dann wird es das auch nicht sein. Gibt es noch andere Ideen woran es liegen bzw. was ich testen könnte?

Hi Leute,
dises Problem hab ich auch. Hab schon echt viel Zeit reingesteckt. Gestern hab ich noch mal den Proxy mit Zertifikat neu aufgesetzt. Heute alle Keys und IDs usw. geprüft.

Wie könnte man sich am besten an das Problem rantasten?

Viele Grüße

Jürgen

[Aktor]

Bei mir läuft es jetzt. Der Fehler war wohl der, dass ich die PHP-Files anscheinend mal in einem Windows-Editor bearbeitet bzw. gespeichert hatte und sie dadurch auf UTF-8 geändert wurden.

Unelegante Lösung zum Testen: Im edomi-aws-lambda-skill-adapter-PLv3.py folgendes ganz unten ergänzen:

t=response.text;
t=t.replace("ufeff","");
return json.loads(t)

Wenn es dann geht, dann einfach die PHP-Files wieder ins Originalformat bringen.

jonofe Man könnte dies wohl auch im Code entsprechend noch ergänzen, dass das abgefragt und dann entsprechend damit umgegangen wird, dafür reichen aber meine Kenntnisse leider nicht aus.

[Jue]

Danke Aktor für den Tip.

Leider hat er mich nicht weiter gebracht. Hab die Dateien überprüft:

[root@edomi alexa]# file -i alexa-config-PLv3.php
alexa-config-PLv3.php: text/x-php; charset=us-ascii
[root@edomi alexa]# file -i edomi-smarthome-skill-PLv3.php
edomi-smarthome-skill-PLv3.php: text/x-php; charset=us-ascii

müsst eigentlich passen.

Ich hab da noch eine Ahnung... kann es sein das das Zertifikat zu "schwach" ist?

URL.JPG

[jonofe]

Meines Wissens erfordert der Alexa Service TLS 1.2.
Nutzt du denn kein letsencrypt mit apache/nginx?

[Jue]

Hi,
ich hab mir gestern für das zertifizieren Hilfe geholt. Da sich die Installationsanleitung so nicht durchführen ließ.
Ich benutze Nginx mit letsencrypt. Es musste allerdings Certbot seperat eingerichtet werden.

Liegt es vielleicht an meinen Resperry, da es nur einer der 2. Generation ist?
Und dadur was nicht unterstützt?

[jonofe]

Ist eher eine Konfiguration im nginx. Ich kenne mich damit nur rudimentär aus, da ich apache verwende.
Aber es sollte in der nginx.conf parametriert werden, welche TLS Versionen verwendet werden.

Such dort mal nach "ssl_protocols"

und trage dort

ssl_protocols TLSv1.2 TLSv1.3;

ein. Danach nginx oder den RPI neustarten und nochmal testen.

[saegefisch]

Zur Info: ich nutze zwar ganz sicher nicht Alexa, aber ein Reverseproxy (uralt(!) "cubieboard 2"; armbian 5.38 stable Ubuntu 18.04.05 LTS) auf nginx-Basis & LE schafft Problemlos „A+“ mit

• 100% Certificate
• 100% Protocol Support
• 90% Key Exchange (weil mein DH „nur“ 2048 Bit hat, d.h. < 4096 → Kompromiss aus Performance + Sicherheit. Später mal erhöhen)
• 90% Cipher Strength (weil mindestens ein Cipher <256 Bit hat; z.Z einer der nicht änderbaren 3 Default-Cipher für TLS 1.3. Vielleicht später excludierbar)

Beschränkung auf TLS 1.2 und 1.3 ist dafür u.a. Erforderlich. Und zeitgemäße/sinnvolle Cipher-Liste. Diese Liste sollte man jährlich mal dem Stand der Dinge anpassen/prüfen - da fliegt mal was raus, da kommt mal was dazu (z.B. eliptisch vor einiger Zeit)

Nachtrag: Auszug aus meiner nginx.conf als Vorlage zum anpassen - ich habe auch eine Weile dran gearbeitet, bis ich die A und dann A+ erreichte...und auch alle Seiten dahinter noch funktionierten...

### >> Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;" always;
[..]
### >> Server-side Absicherung (z.B. gegen BEAST Attacken)
ssl_prefer_server_ciphers on;
ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13_AES_256_GCM_SHA384:EECDH+AESGCM:EDH+A ESGCM:!AES128;

### >> nur >= TLSv1.2 and more stuff
ssl_protocols TLSv1.2 TLSv1.3; # Ausschließlich TLS 1.2 oder höher erlauben | nur TLSv1.3 geht wohl noch(!) nicht...
ssl_ecdh_curve secp384r1; # Nur sinnvoll wenn ein RSA Schlüssel über 3072 bit verwendet wird

### >> Diffie-Hellman Parameter für DHE ciphersuites (2048bit reichen derzeit!)
ssl_dhparam /etc/ssl/certs/dhparams.pem;

### >> Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/<deineDomain>/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

[Jue]

URL2.JPG

Durch das eintragen von:

ssl_protocols TLSv1.2 TLSv1.3;

bin ich jetzt bei A und TLS 1.3

Ist das ausreichend? Denn das Verknüpfen funktioniert immer noch nicht.

Danke euch für die tolle Unterstützung

[trollmar]

Hi,
ich hab mir gestern für das zertifizieren Hilfe geholt. Da sich die Installationsanleitung so nicht durchführen ließ.
Ich benutze Nginx mit letsencrypt. Es musste allerdings Certbot seperat eingerichtet werden.

Liegt es vielleicht an meinen Resperry, da es nur einer der 2. Generation ist?
Und dadur was nicht unterstützt?

Auf dem Pi (debian Buster) wurde im letztes Jahr folgendes bei renew ausgespuckt ..

Your system is not supported by certbot-auto anymore.

Certbot will no longer receive updates.

According to [URL="https://community.letsencrypt.org/t/certbot-1-9-0-release/135414"]https://community.letsencrypt.org/t/...release/135414[/URL] :

Das läuft mW nach nur noch Certbot mit snapd.
Habe das bei mir gewechselt.


LG