Amazon AWS meldet ERROR Client network socket disconnected

[AndreK]

Hallo mitschel ,

# Alexa Plugin Weiterleitung
location /alexa/ {
include /etc/nginx/headers.conf;
satisfy any;
# auth_basic "Restricted Area: Alexa";
# auth_basic_user_file /etc/nginx/.alexa;
allow 127.0.0.1;
allow 192.168.0.0/16;
allow 10.0.0.0/16;
allow ::1;
deny all;
....
proxy_pass http://alexa;

Dein Pfad in der Lambda müsste dann "/alexa " lauten. Allerdings ist hier die Authentifizierung auskommentiert.

# auth_basic_user_file /etc/nginx/.alexa;

Die solltest Du auf jeden Fall "einschalten" (das "#" wegnehmen) und mittels htpasswd die entsprechenden Zugangsdaten erstellen.
Es sieht für mich aus wie wenn Dein NGINX auf der gleichen Maschine wie shNG läuft. Irgendwo muss noch definiert sein wo die Weiterleitung hin geht (proxy_pass http://alexa)

Ich vermute das ist hier

include /etc/nginx/headers.conf;

Prüfe mal auf welchen Port hier weitergeleitet wird und ob dieser mit Deinem Port im Plugin selbst übereinstimmt. (Normalerweise 9001)

Nochmal die Frage zur Installation als solches - verwendest Du das Image von OnkelAndy ?

Gruss Andre

[mitschel]

Hallo André,

Dein Pfad in der Lambda müsste dann "/alexa " lauten.--> hab ich geändert

Die solltest Du auf jeden Fall "einschalten" (das "#" wegnehmen) --> hab ich auch gemacht. solle ich das # nur bei auth_basic_user_file wegnehmen, oder auch bei auth_basic?

htpasswd --> hatte ich bereits gemacht

Es sieht für mich aus wie wenn Dein NGINX auf der gleichen Maschine wie shNG läuft. --> ja genau

Irgendwo muss noch definiert sein wo die Weiterleitung hin geht (proxy_pass http://alexa) --> wo muss ich suchen? in der include /etc/nginx/headers.conf; seht nur
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains" always;
add_header X-Cache $upstream_cache_status;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Xss-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Proxy-Cache $upstream_cache_status;

Prüfe mal auf welchen Port hier weitergeleitet wird und ob dieser mit Deinem Port im Plugin selbst übereinstimmt. (Normalerweise 9001) --> wie mache ich das?

verwendest Du das Image von OnkelAndy ? --> ja genau

[AndreK]

Hallo mitschel ,

leider kenn ich das Setup des Images nicht genau. Irgendwo, ich weiß aber nicht wo, ist der Pfad für http://alexa definiert.
Nimm mal noch das aukommentieren bei "auth_basic" weg. Das sollte aber nur der Anzeigename des Fensters beim manuellen anmelden sein (lt. NGINX-Doku)
Versuchsweise kannst Du ja mal die Zeile

proxy_pass [URL]http://alexa;[/URL]

wie folgt ändern :

proxy_pass [URL="http://alexa;"]http://127.0.0.1:<DEIN_PORT>;[/URL]

<DEIN_PORT> muss dann der Port es Alexa-Plugins sein auf den das Plugin lauscht.

Gruss Andre

[mitschel]

Hallo André,

ich habe beides probiert. Leider hab ich immernoch den gleichen Fehler in Lambda.
2020-03-06T22:18:23.501Z 14db42cf-7aba-49c9-ae36-6f35484338f6 ERROR Uncaught Exception
{ "errorType": "SyntaxError",
"errorMessage": "Unexpected token < in JSON at position 0",
"stack": [ "SyntaxError: Unexpected token < in JSON at position 0",
" at JSON.parse (<anonymous>)",
" at IncomingMessage.<anonymous> (/var/task/index.js:45:21)",
" at IncomingMessage.emit (events.js:228:7)",
" at endReadableNT (_stream_readable.js:1185:12)",
" at processTicksAndRejections (internal/process/task_queues.js:81:21)"
]
}

Irgendwo, ich weiß aber nicht wo, ist der Pfad für http://alexa definiert.--> wo sollte er denn hingehen?

Muss ich vielleicht den host in der config anpassen?

[yachti]

Hallo mitschel,

für mich sieht die nginx Konfiguration verwirrend aus.
Du solltest hier mal strukturiert vorgehen.
Für Debian stretch/buster sieht das so aus:

Im Verzeichnis /etc/nginx/sites-available befindet sich eine default Datei.
Die zeigt die die default nginx Konfiguration.
In diesem Verzeichnis lege ich eine Datei für meine Domain an.
Z.B. dyndnsltd
In dieser Datei erstelle ich meine Konfiguration für jeden Host der Domain
z.B:

# alexa
server {
server_tokens off;
listen 443 ssl;
server_name alexa.dyndns.ltd;

# gzip should not be used with ssl
   gzip off;
##
# SSL
# Global SSL in nginx.conf
##
# ssl on;

 ssl_certificate /etc/letsencrypt/live/alexa.dyndns.ltd/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/alexa.dyndns.ltd/privkey.pem;
 add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
 access_log /var/log/nginx/alexa.log combined;

# maintain the .well-known directory alias for letsencrypt & renewals
location /.well-known {
auth_basic off;
alias /var/www/html/.well-known;
}

auth_basic "username";
auth_basic_user_file /etc/nginx/htpasswd;

location / {
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://deineIP:9000/;
proxy_read_timeout 90;
}

}

Dann die Konfiguration verfügbar machen

sudo ln -s /etc/nginx/sites-available/dyndnsltd /etc/nginx/sites-enabled
sudo systemctl reload nginx
/

Im Verzeichnis ../sites-enabled sollte dann diese Verknüpfung stehen.
Sollten da andere Verknüpfungen vorhanden sein diese umbenen<axnen.

Der nginx lauscht dann auf die Domain alexa.dyndns.tld

Die Variblen in der Lambda sollten dann für das Beispiel wie folgt aussehen:

SMARTHOME_HOST alexa.dyndns.tld
SMARTHOME_PORT 443
SMARTHOME_PATH '/'
SMARTHOME_AUTH 'username:password'

Dann mal von aussen auf die URL alexa.dyndns.tld zugreifen. Hier sollte dann die Credentials-Abfrage kommen.
Da kannst dann die Crendtials prüfen und im log vom nginx siehst Du ob die Weiterleitung funktioniert.

Wenn das passt kannst Du die nginx Konfiguration in dem Verzeichnis /etc/nginx/sites-available step für step für andere Hosts erweitern.
Den nginx neu starten nicht vergessen.

Gruß

Michael

[AndreK]

Hallo @mitschel,

Du kannst auch noch versuchen das "Diskovery" mittels einer Testfunktion in der Lambda durchzuführen. Dort kannst du vielleicht noch besser die Ursache für den Fehler erkennen.
Oben rechts kannst du in der Lambda-Definition eine Testfunktion anlegen. (Neben dem Actions Button)
Für das Diskovery muss die Funktion wie folgt lauten. Diese erstellen und dann mittels "Test"-Button durchführen.

{
"directive": {
"header": {
"namespace": "Alexa.Discovery",
"name": "Discover",
"payloadVersion": "3",
"messageId": "abc-123-def-456"
},
"payload": {
"scope": {
"type": "BearerToken",
"token": "access-token-from-skill"
}
}
}
}

Kennst Du die Doku von schuma aus dem Alexa Plugin Thread (Post #779), dort ist sehr vieles, und aktuell beschrieben.

Gruss Andre

P.S.: eventuell kannst Du das Ergebnis der Testfunktion posten

[mitschel]

Hallo Leute,

gute Neuigkeiten. Es geht!!!!!!


Anhand eurer Beschreibungen bin ich jetzt selbst auf die Lösung gekommen.
Bei Lambda musste ich bei SMARTHOME_PATH doch /alexa/ eintragen. Und dank dem Post #20 von Yachti habe ich in /etc/nginx/conf.d/https.conf nach ein paar anderen Tests bei location alexa gesehen, dass ich einen Tippfehler bei "proxy_pass http://... " hatte.

Vielen Dank an euch. Ihr seid die Besten!!!