REST Request Fehler

[Rollo62]

Kann es am Wordpress selber liegen, da war doch vor kurzem etwas in der Presse dass die REST-Schnittstelle Sicherheitslücken hat, und dass man die besser deaktiviert.
Ich weiss nicht ob Du den Wordpress-Server selber hostest, oder ob das jemand abgeschaltet haben könnte.

[t2000]

Zitat von Rollo62:

Kann es am Wordpress selber liegen, da war doch vor kurzem etwas in der Presse dass die REST-Schnittstelle Sicherheitslücken hat, und dass man die besser deaktiviert.
Ich weiss nicht ob Du den Wordpress-Server selber hostest, oder ob das jemand abgeschaltet haben könnte.

Nein. Es gibt WordPress REST und WooCommerce REST. Das WordPress brauchen wir für den Bilder (Medien) Upload. Für den Shop reicht WooCommerce aus.
Wir hosten selber.
UND, von meinem PC läuft alles einwandfrei.
UND, beim Kunden läuft die Abfrage, wenn ich mit Chrome und REST Editor arbeite.

Nur mit meinem Delphi 10.4.1 Programm geht es nicht. (Beim Kunden!)

[t2000]

Alle Varianten von RestClient.SecureProtocols getestet. Nichts geht.

[TiGü]

Unterstützt die von dir verwendete Delphi-Version (vermutlich Sydney) überhaupt dieses alte Betriebssystem?
Meine Frage zielt darauf ab:
Gibt es überhaupt die von den Delphi-REST-Komponenten erforderten Schnittstellen, Funktionen, DLLs etc. etc. in dieser Windows-Version?

Mir liegen nur die Quelltexte von Tokyo vor, aber im Prinzip wird für jeden Execute-Aufruf vom RESTRequest eine Instanz von TWinHTTPRequest erzeugt (System.Net.HttpClient.Win).
Wenn die hier eingebauten Windows-Funktionen wie bspw. WinHttpConnect, WinHttpOpenRequest, WinHttpAddRequestHeaders oder WinHttpSetTimeouts nicht in Windows Server 2008 vorliegen oder andere Werte erwarten bzw. zurück liefern, dann schlägt das natürlich fehl.

[Daniel]

Kann das ein Problem mit der TLS-Version sein?
Der 2008er-Server ist womöglich nicht ganz up-to-date was TLS 1.2/1.3 angeht. Wenn nun also der Webserver etwas fordert, was besagter Windows-Server nicht kann, wäre das eine plausible Erklärung.
Zu prüfen wäre, was dieser Windows 2008er-Server für Verschlüsselungen für HTTP anbietet (SSL / TLS und die jeweiligen Versionen). Und das müsste dann mit dem Webserver abgeglichen werden, was der seinerseits an Anforderungen stellt.

[t2000]

Der Server hat in den Internetoptionen TLS 1.0/1.1/1.2
Ich habe im RESTClient jetzt TLS 1.1/1.2 eingestellt.
Geht aber nicht.

Wäre super, wenn ich noch ne Lösung finden würde. Aber zwischenzeitlich muss ich nun beim Kunden das Programm auf einen anderen PC installieren, bis ich die Lösung für den Server habe oder der Techniker den neuen Server (vielleicht schon früher) fertig hat.

[TiGü]

Debuggen vor Ort bzw. Remote Debugging ist drin?

[sh17]

Windows Server 2008 R2 - auch wenns blöd klingt, aber irgendwann ist eben auch mal Ende der Fahnenstange. Ich hatte letztens
einen Windows Server 2003, hab ich direkt abgelehnt, auch wenn es evtl. funktioniert hätte

Ist das die erste Version, die auf dem System laufen soll? Oder ist das nur ein Update und vorher ging schon mal alles?

[t2000]

Unsere Software läuft da schon seit über 10 Jahren. Hier ging es um ein separates Programm, welchses Daten in einen Woocommerce Shop schieben soll.
Ich hatte auch schon Herbst gesagt, dass wir seit Anfang 2020 jeglichen Support für Win 7 und Windows Server 2008 ablehnen.
Ist aber ein sehr guter Kunde und der Techniker hat versprochen bis Februar einen neuen Server zu liefern.

Leider sollte wegen Corona jetzt der Shop vorzeit aktiviert werden. Hätte ja klappen können.
So wie es aussieht, werden wir das Transfermodul einfach auf einem "normalen" Win10 PC im Netzwerk laufen lassen. Die Daten können ja auch über's Netz aus dem SQL-Server geladen werden um sie dann ins Internet zu stellen.

Ich sehe zur Zeit keine andere Lösung. Das letzte Update auf dem Server war auch im Mai 2018 !! Ich lass da jetzt die Finger von.

Danke für eure Bemühungen

[TiGü]

Wie oben beschrieben, habe ich nur die Tokyo-Sourcen vorliegen.
Ich nehme an, da hat sich zwei Versionen weiter schon was getan.

Ich vermute, dass du den Fehler in TWinHTTPClient.DoExecuteRequest bekommst.
Also beim Senden des Requests mit WinHttpSendRequest.

Das ist in Tokyo wie folgt gelöst (Zeile 855 ff. aus System.Net.HttpClient.Win):

Delphi-Quellcode:

  // Send Request
  LRes := WinHttpSendRequest(LRequest.FWRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0, WINHTTP_NO_REQUEST_DATA, 0, LDataLength, 0);
  if not LRes then
  begin
    LastError := GetLastError;
    case LastError of
      ERROR_WINHTTP_SECURE_FAILURE:
        Exit(TExecutionResult.ServerCertificateInvalid);
      ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED:
        Exit(TExecutionResult.ClientCertificateNeeded);
      else
        raise ENetHTTPClientException.CreateResFmt(@SNetHttpClientSendError, [GetLastError, SysErrorMessage(GetLastError, GLib.Handle)]);
    end;
  end;

Vom Fehlertext her, bekommst du ja einen ERROR_WINHTTP_SECURE_FAILURE ("Es ist ein Sicherheitsfehler aufgetreten").
Das wurde hier in 10.2 Tokyo noch mit einem einfachen Enum-Wert als Rückgabe gelöst.

Ich könnte mir vorstellen, dass dies in 10.4 Sydney auf den ENetHTTPClientException.CreateResFmt geht.
Denn SNetHttpClientSendError = 'Fehler beim Senden der Daten: (%d) %s'; ist der mittlere Teil deiner Fehlermeldung.
Der vordere Teil (sRESTRequestFailed) kommt aus dem except-Block von TCustomRESTRequest.Execute (Rest.Client),

Delphi-Quellcode:

        // Unknown error, might even be on the client side. raise it!
        on E: Exception do
        begin
          // If Execute raises an Exception, then the developer should have look into the actual BaseException
          raise ERESTException.CreateFmt(sRESTRequestFailed, [E.Message]);
        end;

Wie dem auch sein, für ERROR_WINHTTP_SECURE_FAILURE sagt die MSDN (https://docs.microsoft.com/en-us/win...psendrequest):

Zitat:

One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server.
To determine what type of error was encountered, verify through a WINHTTP_CALLBACK_STATUS_SECURE_FAILURE notification in a status callback function.
For more information, see WINHTTP_STATUS_CALLBACK.

Was uns hierzu führt: https://docs.microsoft.com/en-us/win...tatus_callback
Du könntest also durch das setzen einer Callback mehr Information erhalten, warum es bei dir scheitert (via WinHttpSetStatusCallback -> https://docs.microsoft.com/en-us/win...statuscallback).

In Tokyo ist dafür nichts vorgesehen bzw. ist das in TWinHTTPClient.Create auskommentiert.
Entweder gibt es in Sydney dann Möglichkeiten dafür ODER du kopierst dir die System.Net.HttpClient.Win in dein Projekt und veränderst sie entsprechend, um mehr Informationen loggen zu können.