InetRead bzw. Inetget mit HTTPS

Statement zur DSGVO im Forum

Alles zur DSGVO und zur Umsetzung im Forum hier: Statement zur DSGVO (letztes Update: 30.05.2018)
  • Hallo AutoItler!


    Ich habe vor länger Zeit einen Loader für eine LiveCD geschrieben. Der basiert noch auf einen HTTP-Download. Jetzt ist es aber an der Zeit das auf HTTPS umzustellen. Und da ist auch mein Problem: Der Download funktioniert nicht wenn das Zertifikat nicht am Client ist.


    Um das Problem einzugrenzen habe ich ein kleines Script zum Testen geschrieben:



    mit der Option 3 (Forces a reload from the remote site & Ignore all SSL errors (with HTTPS connections) sollte ein Zertifikatsfehler ja ignioriert werden, tut es aber nicht!

    Um mögliche Eigenfehler auszuschliessen, kann ich die Datei auch via HTTP runter laden, es funktioniert auch wenn kein Zertifikatsfehler kommt (sprich auf meinen PC ist alles korrekt eingetragen).


    Ein weiter Test mit WGET https://IP_des_Server/test.cfg -Oc:\test\test.cfg --no-check-certificate funktioniert auch....

    Um die Frage warum ich nicht das Zertifikat vorab installiere: Das ist eine Henne / EI Problem, denn die Zertifikate vom Loader geladen und installiert werden :/


    Im Forum habe diesen Beitrag gefunden, leider ohne Lösung: InetRead bei REST-Api schlägt fehl


    Ideen dazu?


    lg

    Racer

  • Ich hatte mit InetGet() auch schon mal zu kämpfen. Seitdem nutze ich das WinHTTP Objekt. Das kommt auch ohne viel Aufwand super mit Proxyumgebungen klar.


    AutoIt
    1. Local $oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
    2. $oHTTP.Open("GET", "https://IP_des_Server/test.cfg")
    3. $oHTTP.Send()
    4. $File = $oHTTP.Responsetext

    Ich hoffe der externe Link ist hier ok: WinHttpRequest object im MSDN

  • OMG, hier ist es alles für Dich fertig: TUT auf feldstudie.net


    Zum Verständnis (häää, wiso $objhttp.Option(4) = 13056 ; turns off ssl error messages and warnings ?!)


    13056 ist in hex 0x3300 und ergibt sich als Summe der folgenden WinHttpRequestOption_SslErrorIgnoreFlags (siehe MSDN):


    Error Value
    Unknown certification authority (CA) or untrusted root 0x0100
    Wrong usage 0x0200
    Invalid common name (CN) 0x1000
    Invalid date or certificate expired 0x2000


  • Ich bin erst jetzt dazugekommen das empfohlene WinHTTP zu testen. Leider sieht es nicht ganz so gut aus (liegt aber eher an mir :-)


    Code
    1. Local $oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
    2. $oHTTP.Open("GET", "https://IP_des_Server/test.cfg")
    3. $oHTTP.Send()$File = $oHTTP.ResponseText


    Die Zeile 2 ist Unternehmensintern und sieht anders aus. Den Link übernehme ich aus dem Browser um Tippfehler zu vermeiden...


    Es kommt aber am Ende ein Fehler:

    $File = $oHTTP.ResponseText
    $File = $oHTTP^ ERROR


    Leider kenne ich mich damit zu wendig aus...



    Mit dem Script


    hatte ich schon mehr Erfolg, zumindest unter Windows 7. Unter WinPE läuft es leider nicht so gut und ich bekomme immer nur 0 heraus, anstatt des gewüschten Datei.


    Und wenn ich schon dabei mit, kann mir bitte die Zeile "$hConnect = _WinHttpConnect($hSession, $sHost, $bSSL ? 443 : 80)" mit den letzten Parameter erklären? Was ist das "$bSSL ? 443 : 80" ???


    lg

    Racer

  • Zum letzten Parameter: Der Funktionskopf lautet ja Func _GetRest($sHost, $sPath, $bSSL = True)

    Mit $bSSL ? 443 : 80 wird nun überprüft, ob $bSSL im Funktionsaufruf True oder False ist. Wenn $bSSL = True, dann wird bei _WinHttpConnect als Port 443 verwendet also so: $hConnect = _WinHttpConnect($hSession, $sHost, 443), wenn $bSSL False ist wird Port 80 verwendet: $hConnect = _WinHttpConnect($hSession, $sHost, 80). Das ?: ist eigentlich nur eine If-Bedingung mit der überprüft wird ob die Variable die vor dem ? steht true oder false ist und dementsprechend wird dann der Wert vor dem : für Variable = true und nach dem Doppelpunkt für Variable = false "eingesetzt".

  • xxx ? dies machen : das machen


    Ist nur eine Kurzschreibweise für If ... Then ... Else ... EndIf.


    In diesem Fall wird gecheckt, ob eine SSL Verbindung hergestellt werden soll, dann nimmt er Port 443 zum Verbinden, sonst standard-HTTP Port 80.


    Deine Posts sind durch fehlende Zeilenumbrüche kaum lesbar. Kannst Du das nochmal reparieren?


    Wenn das Winhhtp Objekt bei .Responsetext einen Fehler wirft, ist vermutlich das .Send schon gescheitert. Ich vermute, die URL ist für das Skript nicht erreichbar gewesen.


    Auch wenn es firmeninterne Links sind, so schreibe sie in veränderter Form. Z.B. https://einserver:port/einordner/einedatei.xyz

  • hatte ich schon mehr Erfolg, zumindest unter Windows 7. Unter WinPE läuft es leider nicht so gut und ich bekomme immer nur 0 heraus, anstatt des gewüschten Datei.

    Wird denn überhaupt eine Verbindung aufgebaut? Ist die Assembly von WinHttp, also die DLL, auf WinPE standardmäßig vorhanden?


    Zum Thema ?: (ternäre Operatoren):

    Es ist nur die halbe Wahrheit, wenn man es die Kurzschriebweise von If-Blöcken nennt.

    Viel mehr ist es ein inline-If welches den Wert zwischen ? : zurückgibt wenn die Bedingung true ist und den Wert nach dem : zurückgibt wenn die Bedingung false ist.


    Das mag jetzt vielleicht identisch klingen aber Zeilen wie 1 = 1 ? Bla() : Blubb() sind nicht erlaubt.

    Ein If-Block lässt Befehle ausführen, ein ternärer Operator soll dazu genutzt werden unnötige If-Blöcke elegant zu verbergen wie in diesem Beispiel mit $bSSL.

  • Ich bin erst jetzt dazugekommen das empfohlene WinHTTP zu testen. Leider sieht es nicht ganz so gut aus (liegt aber eher an mir


    Code
    Local $oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
    $oHTTP.Open("GET", "https://IP_des_Server/test.cfg")
    $oHTTP.Send()$File = $oHTTP.ResponseText

    Hast du denn auch wie Zec geschrieben hat $objhttp.Option(4) = 13056 ; turns off ssl error messages and warnings benutzt?


    Also:

    Code
    1. $oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
    2. $oHTTP.Open("GET", "https://IP_des_Server/test.cfg")
    3. $oHTTP.Option(4) = 13056
    4. $oHTTP.Send()
    5. $File = $oHTTP.ResponseText()
  • Guten Morgen liebe AutoIt'ler!


    Ich habe einen kleinen Erfolg: Auf meinen Client hat es zuerst auch mit der $oHTTP.Option(4) = 13056 nicht funkioniert. Erst als ich ein @CRLF eingefügt habe ist es Problemlos gelaufen....


    Code
    1. Local $oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
    2. $oHTTP.Open("GET", "https://IP_des_Server/test.cfg" & @CRLF) ;ohne @CRLF gehts nicht!
    3. $oHTTP.Option(4) = 13056
    4. $oHTTP.Send()
    5. $File = $oHTTP.ResponseText()
    6. ConsoleWrite ($File & @CRLF)


    so, jetzt kommt WinPE an die Reihe...


    lg

    Racer

  • PE ist im MSDN nicht explizit aufgeführt. Melde mal, ob es das Objekt da so gibt.


    AutoIt
    1. $sPath = @WindowsDir & "\system32\Winhttp.dll"
    2. (FileExists($sPath)) ? ConsoleWrite($sPath& " found!") : ConsoleWrite($sPath& " not found.")


    Source

  • Ich bin dem Moment mit den Tests unter WinPE fertig geworden.

    Um WinHTTP unter WinPE nutzen zu können muss man die Winhttpcom.dll und winhttp.dll in in das %system32% Verzeichnis kopiern (sofern nicht schon vorhanden). Dann funktioniert das Script.


    Leider ist noch nicht das gewünscht Ergebnis da, denn ich bekomme vom Webserver die "Default-Webseite" anstatt dem Download :-(

    Da muss ich mich noch damit spielen bis es passt!


    Auf jedenfall ist mein Problem mit Eurer Hilfe gelöst - vielen Dank an Alle!


    lg

    Racer


    Die MS sagt vieles nicht was dann doch geht ;)

  • Erst als ich ein @CRLF eingefügt habe ist es Problemlos gelaufen...

    Ich bin auch kein Profi, was das Objekt-Handling angeht, aber hier mal ein kleines Test-Script aus meinem Code-Schnipsel-Archiv.

    @CRLF ... siehe Zeile 128 ;-)