https request von fhem 7390 kein response

[dutzend]

Hallo Forum,

ich möchte eine PushNotification (Windows 10 UWP) auslösen.

Der erste Schritt hierzu ist einen Access Token per HTTPS anzufordern. Ich bekomme bei keinem meiner (tagelangen) Versuche eine Antwort zurück (z.B. mit HttpUtils_BlockingGet: empty answer received).
Mit einem zu Testzwecken geschriebenen Windows-Client funktioniert die Anfrage einwandfrei (aus dem selben Netzwerk).

POST /accesstoken.srf HTTP/1.1
Host: https://login.live.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 206

Eine eigene Lösung für den Request funktioniert genauso wenig:

my $contentlength = length($content);

my $header =
    "POST /accesstoken.srf HTTP/1.1\r\n".
    "Host: https://login.live.com\r\n".
    "Content-Type: application/x-www-form-urlencoded\r\n".
    "Content-length: $contentlength\r\n";
 
  select SOCKET;
  $| = 1;
  #binmode SOCKET;
  print SOCKET $header;
  print SOCKET $content;
  shutdown SOCKET, 1;

  my @data = (<SOCKET>);

Der Server scheint erreichbar zu sein, die Antwort kommt "nur" nicht durch. Ich habe schon mit allerlei Portfreigabevarianten experimentiert, leider ohne Erfolg.

Kann jemand weiterhelfen?
Danke René

[rudolfkoenig]

Verstehe ich richtig, FHEM laeuft auf einem FB7390, und versucht eine HTTPS Verbindung zu login.live.com aufzubauen?
Wenn ja: Kannst du bitte verifizieren, dass das vom Windows-Client versendete HTTP-Header dem von FHEM/HttpUtils_BlockingGet versendeten genau entspricht, und hier den Aufruf mit allen Parameter zeigen? Vorher sicherstellen, dass eine aktuelle Version von HttpUtils.pm verwendet wird.
Deinen Code kann ich wg. Unvollstaedigkeit auch nicht beurteilen, zu shutdown faellt mir ein, dass das viele Webserver nicht verstehen.

[dutzend]

Hallo Rudolph,

Dank für die schnelle Antwort...

Ja, richtig FB7390 mit FHEM 5.7 (Updates gemacht) ruft https://login.live.com/
Leider vergaß ich in meinem ersten Post einen wohl wichtigen Aspekt: Die FB7390 befindet sich hinter einer FB6490 Cable

Der HTTP-Request entspricht aufs Haar dem aus meinem Windows -Client. Mit dem Windows-Client sehe ich auch, dass der Server bei noch so falschen Anfragen eine wie auch immer geartete Antwort zurück gibt.

Der Aufruf mit HttpUtils_BlockingGet sieht vollständig so aus:

sub
GetAccessToken()
{
  my $clientId = "ms-app://s-1-15-2-3423490847-2720683751-1593327743-4271669891-3499021736-3666078824-4231493559";
  my $clientSecret = "sHuxAUJZOpjdKIVkE9XkmjcwwNzMOPDg";

  my $data =
    "grant_type=client_credentials&".
    "client_id=$clientId&".
    "client_secret=$clientSecret&".
    "scope=notify.windows.com";

  $data = uri_escape($data);

  Log 1, $data;

  my $param = {
              url => "https://login.live.com/accesstoken.srf",
              method => "POST",
              header => "Content-Type: application/x-www-form-urlencoded",
              data => $data,
              };
 
  my $err = "";
  my $con = "";
  ($err, $con) = HttpUtils_BlockingGet($param);

  Log 1, "AccessToken: $err $con";
}

Den Code von mir hatte ich erfolgreich in Verbindung mit einer Windows Phone App am laufen, im Moment kann ich das aber nicht mehr testen...

Gruß René

[rudolfkoenig]

Code Auswählen Erweitern

fhem> attr global verbose 5
fhem> { GetAccessToken() }


2016.05.21 22:05:52.827 5: Cmd: >{ GetAccessToken() }<
2016.05.21 22:05:52.827 1: grant_type%3Dclient_credentials%26client_id%3Dms-app%3A%2F%2Fs-1-15-2-3423490847-2720683751-1593327743-4271669891-3499021736-3666078824-4231493559%26client_secret%3DsHuxAUJZOpjdKIVkE9XkmjcwwNzMOPDg%26scope%3Dnotify.windows.com
2016.05.21 22:05:52.827 4: HttpUtils url=https://login.live.com/accesstoken.srf
2016.05.21 22:05:53.489 4: https://login.live.com/accesstoken.srf: HTTP response code 400
2016.05.21 22:05:53.489 4: HttpUtils https://login.live.com/accesstoken.srf: Got data, length: 76
2016.05.21 22:05:53.489 1: AccessToken:  {"error":"invalid_request","error_description":"Invalid request parameters"}

Ob das jetzt gut oder schlecht ist, kann ich nicht beurteilen.

[dutzend]

Hallo Rudolf,

mit VERBOSE 5 sehe ich bei mir Folgendes:

2016.05.22 10:08:17 5: Cmd: >{ GetAccessToken() }<
2016.05.22 10:08:17 1: grant_type%3Dclient_credentials%26client_id%3Dms-app%3A%2F%2Fs-1-15-2-3423490847-2720683751-1593327743-4271669891-3499021736-3666078824-4231493559%26client_secret%3DsHuxAUJZOpjdKIVkE9XkmjcwwNzMOPDg%26scope%3Dnotify.windows.com
2016.05.22 10:08:17 4: HttpUtils url=https://login.live.com/accesstoken.srf
2016.05.22 10:08:17 4: Attempt to reload IO/Socket/SSL.pm aborted.
Compilation failed in require at (eval 18477) line 2.
BEGIN failed--compilation aborted at (eval 18477) line 2.

Gruß René

[rudolfkoenig]

2016.05.22 10:08:17 4: Attempt to reload IO/Socket/SSL.pm aborted.

https://forum.fhem.de/index.php/topic,26959.msg201256.html#msg201256

[dutzend]

Hi,

ich habe jetzt ein paar Tage lang versucht die Dateien, wie hier mehrfach beschrieben, einzubinden. Der SSL-Fehler (Attempt to reload IO/Socket/SSL.pm aborted) verschwindet bei mir nicht. Dann FHEM-Neustart versucht, mit dem Ergebnis so lange die Dateien vorhanden sind startet FHEM nicht mehr

Dankbar für jeden Tipp
René
FB7390 6.23 FHEM 5.7

[dutzend]

Hi,

ich habe gerade zum Test ob das JSON-Modul bei mir läuft (anderes Problem? https://forum.fhem.de/index.php/topic,40305.45.html) Yahoo-Wetter eingebunden, hier habe ich das selbe Problem: die Anfrage an Yahoo per https liefert "empty answer received"...

Gruß
René