Restsharp: Port wird vom Host-Header entfernt

Erstellt am 21. Feb. 2018  ·  35Kommentare  ·  Quelle: restsharp/RestSharp

Erwartetes Verhalten

Restsharp sollte den Host-Header unverändert senden, ohne den Port im Host-Header-Wert zu ändern.
https://github.com/minio/minio-dotnet/pull/212 bringt Restsharp 106.2.1 anstelle von Restsharp.Netcore (nicht offizielle Version mit .netcore-Unterstützung). Wir haben jedoch Signaturkonfliktfehler gefunden, weil der benutzerdefinierte Authentifikator, der von minio dotnet sdk verwendet wird, eine Autorisierungssignatur mit ip:port als Wert für den „Host“-Header erstellt. Restsharp httpclient scheint den Port abzustreifen, da der Server-Trace nur ip im Host-Header-Wert anzeigt.

Tatsächliches Verhalten

port wird in Restsharp 106.2.1 vom Header-Wert „Host“ entfernt

Schritte zum Reproduzieren des Problems

  1. Klonen Sie minio-dotnet sdk und erhalten Sie den Patch https://github.com/minio/minio-dotnet/pull/212
    ➜ minio-dotnet git:(02cbcb5) ✗ dotnet restore;dotnet build
    ➜ minio-dotnet git:(02cbcb5) ✗ dotnet run --project SimpleTest
    2.
    3.

Spezifikationen

StackTrace

minio-dotnet client side trace
---------------------------------------
Full URL of Request http://192.168.1.157:9000/
Request completed in 90.1376 ms, Request: {
  "resource": "/",
  "parameters": [
    {
      "name": "x-amz-content-sha256",
      "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "type": "HttpHeader"
    },
    {
      "name": "Host",
      "value": "192.168.1.157:9000",
      "type": "HttpHeader"
    },
    {
      "name": "x-amz-date",
      "value": "20180221T205958Z",
      "type": "HttpHeader"
    },
    {
      "name": "Authorization",
      "value": "AWS4-HMAC-SHA256 Credential=minio/20180221/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=db0fbcc9aa66975a530a2621962a87787559289a218da881420686263da862df",
      "type": "HttpHeader"
    },
    {
      "name": "Accept",
      "value": "application/json, application/xml, text/json, text/x-json, text/javascript, text/xml",
      "type": "HttpHeader"
    }
  ],
  "method": "GET",
  "uri": "http://192.168.1.157:9000/"
}, Response: {
  "statusCode": 403,
  "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><Key></Key><BucketName></BucketName><Resource>/</Resource><RequestId>3L137</RequestId><HostId>3L137</HostId></Error>",
  "headers": [
    {
      "Name": "Accept-Ranges",
      "Value": "bytes",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Server",
      "Value": "Minio/DEVELOPMENT.GOGET, (linux; amd64)",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Vary",
      "Value": "Origin",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "X-Amz-Request-Id",
      "Value": "151572E9DCF94747",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Date",
      "Value": "Wed, 21 Feb 2018 20:59:58 GMT",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Transfer-Encoding",
      "Value": "chunked",
      "Type": 3,
      "ContentType": null
    },
    {
      "Name": "Content-Type",
      "Value": "application/xml",
      "Type": 3,
      "ContentType": null
    }
  ],
  "responseUri": "http://192.168.1.157:9000/",
  "errorMessage": null
}
I'm not handling the Minio.Exceptions.MinioException.

Unhandled Exception: System.AggregateException: One or more errors occurred. (Minio API responded with message=The request signature we calculated does not match the signature you provided. Check your key and signing method.) (Minio API responded with message=The request signature we calculated does not match the signature you provided. Check your key and signing method.) ---> Minio.Exceptions.MinioException: Minio API responded with message=The request signature we calculated does not match the signature you provided. Check your key and signing method.
   at Minio.MinioClient.ParseError(IRestResponse response) in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 475
   at Minio.MinioClient.<>c.<.ctor>b__78_0(IRestResponse response) in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 70
   at Minio.MinioClient.HandleIfErrorResponse(IRestResponse response, IEnumerable`1 handlers, DateTime startTime) in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 502
   at Minio.MinioClient.<ExecuteTaskAsync>d__81.MoveNext() in /home/kris/code/minio-dotnet/Minio/MinioClient.cs:line 349
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Minio.MinioClient.<ListBucketsAsync>d__0.MoveNext() in /home/kris/code/minio-dotnet/Minio/ApiEndpoints/BucketOperations.cs:line 52
   --- End of inner exception stack trace ---
   at System.AggregateException.Handle(Func`2 predicate)
   at SimpleTest.Program.Main(String[] args) in /home/kris/code/minio-dotnet/SimpleTest/Program.cs:line 47

Server side trace: 
--------------------------
➜  minio git:(debugnet) minio server ~/ex                               
Drive Capacity: 6.9 GiB Free, 221 GiB Total

Endpoint:  http://192.168.1.157:9000  http://172.17.0.1:9000  http://172.18.0.1:9000  http://172.19.0.1:9000  http://172.20.0.1:9000  http://127.0.0.1:9000
AccessKey: minio 
SecretKey: minio123 

Browser Access:
   http://192.168.1.157:9000  http://172.17.0.1:9000  http://172.18.0.1:9000  http://172.19.0.1:9000  http://172.20.0.1:9000  http://127.0.0.1:9000

Command-line Access: https://docs.minio.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://192.168.1.157:9000 minio minio123

Object API (Amazon S3 compatible):
   Go:         https://docs.minio.io/docs/golang-client-quickstart-guide
   Java:       https://docs.minio.io/docs/java-client-quickstart-guide
   Python:     https://docs.minio.io/docs/python-client-quickstart-guide
   JavaScript: https://docs.minio.io/docs/javascript-client-quickstart-guide
   .NET:       https://docs.minio.io/docs/dotnet-client-quickstart-guide
signed headers .... map[X-Amz-Content-Sha256:[e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855] X-Amz-Date:[20180221T205638Z] Host:[192.168.1.157]]

picture poornas

Hilfreichster Kommentar

Lass es uns erhöhen!

picture niemyjski am 22. März 2018
👍4

Alle 35 Kommentare

Gibt es eine Möglichkeit, es in einem einfachen Test zu reproduzieren?

alexeyzimarev picture alexeyzimarev am 24. Feb. 2018

https://github.com/poornas/restsharp-test - dies ist ein Bare-Bones-Projekt, das restsharp verwendet, um einen Listen-Bucket-Aufruf an den Minio-Server zu senden. Es verwendet einen benutzerdefinierten Authentifikator - Sie werden sehen, dass es aufgrund von Signaturkonflikten fehlschlägt. Sobald die Anfrage an restsharp übergeben wurde, wird der Port entfernt, bevor er an den Server weitergeleitet wird.

poornas picture poornas am 26. Feb. 2018

Danke. Ich werde nachsehen und versuchen, es zu beheben.

alexeyzimarev picture alexeyzimarev am 26. Feb. 2018
👍2

Danke!

niemyjski picture niemyjski am 27. Feb. 2018

@alexeyzimarev Irgendwelche Ideen, was das verursachen könnte?

niemyjski picture niemyjski am 28. Feb. 2018

@alexeyzimarev , hattest du schon Gelegenheit, das zu prüfen? Danke

poornas picture poornas am 5. März 2018

Prüfe jetzt

alexeyzimarev picture alexeyzimarev am 5. März 2018

Ich habe Ihre Repro geklont und sehe Folgendes:

  "parameters": [
...
    {
      "name": "Host",
      "value": "play.minio.io:9000",
      "type": "HttpHeader"
    }

Meinen Sie, dass die Parameter in der Anfrage in Ordnung sind, aber der Wert nicht richtig an den Server gesendet wird?

alexeyzimarev picture alexeyzimarev am 5. März 2018

@alexeyzimarev , das ist richtig - die Ablaufverfolgung, die Sie oben sehen, befindet sich vor dem Aufruf von executeAsync. Wenn ExecuteAsync aufgerufen wird, ruft Restsharp die Authenticate-Methode auf, in der wir den Signaturautorisierungsheader basierend auf url:port im benutzerdefinierten Authentifikator festlegen. Der Port scheint von Restsharp entfernt zu werden, bevor er den Server erreicht und nach dem Aufruf von Authenticate().

poornas picture poornas am 5. März 2018

Irgendwelche Updates dazu? Wir sind diesbezüglich ziemlich stark blockiert.

niemyjski picture niemyjski am 14. März 2018

Leider konnte ich mir das noch nicht anschauen. Wenn es sehr kritisch ist, könnt ihr vielleicht eine Stunde damit verbringen, es zu debuggen?

alexeyzimarev picture alexeyzimarev am 14. März 2018

Ich habe mir das mal schnell angeschaut. Soweit ich das beurteilen kann, liegt das Problem hier nicht wirklich bei RestSharp, sondern tatsächlich HttpWebRequest in System.Net !

Bis RestSharp die Anforderung an System.Net übergeben hat, enthält die Host -Eigenschaft (Uri) in HttpWebRequest immer noch die Portinformationen. Wenn jedoch .SendRequest() aufgerufen wird, wird der verwendete Host-Header nur mit dem URI Host gefüllt, nicht mit Host und Port .

Hier ist ein Screenshot meines Debuggers unter dem obigen Link.
screen shot 2018-03-22 at 11 22 52 am

Dies widerspricht eindeutig der HTTP-Spezifikation , die die Verwendung von Ports respektiert.

Bitte korrigiert mich jemand, wenn ich falsch liege, denn ich habe noch nie einen Fehler im dotnet-Framework gefunden, und normalerweise, wenn ich denke, dass ich einen habe, habe ich keinen. Andernfalls nehme ich an, dass die nächsten Schritte darin bestehen würden, dieses Problem im CoreFX-Repo anzusprechen?

twgraham picture twgraham am 22. März 2018

Lass es uns erhöhen!

niemyjski picture niemyjski am 22. März 2018
👍4

Fertig - mal sehen, ob das echt ist, wo der Fehler ist oder nicht.

twgraham picture twgraham am 22. März 2018

Nur neugierig - weiß jemand, ob es sich um eine Regression mit dem letzten .NET Core handelt? (2.1) Oder mit laststable (2.0)? Oder der Unterschied zwischen .NET Framework und .NET Core oder der Unterschied zwischen dem Betriebssystem Windows und Linux? ("weiß nicht" ist eine gute Antwort, danke!)

karelz picture karelz am 22. März 2018

@karelz TBH Ich habe dieses Problem untersucht, um ein anderes Problem zu lösen, damit ich keine Compiler-Warnungen mehr bekomme. Diese Bibliothek wurde erst kürzlich (vielleicht Monate) aktualisiert, um .NET Core über nur .NET Framework zu unterstützen. Vielleicht weiß @alexeyzimarev mehr?

twgraham picture twgraham am 22. März 2018

OK, damit Sie es zumindest wissen: Es funktioniert auf .NET Framework (Windows) und schlägt auf .NET Core 2.0 (Mac) fehl. Ist das die richtige Zusammenfassung?

karelz picture karelz am 22. März 2018

Nein – aus anderen Threads, in denen ich mich befinde, würde ich sagen, dass alle Plattformen auf .NET Core 2.0 fehlschlagen, und ich weiß nichts über .NET Framework.

twgraham picture twgraham am 22. März 2018

@karelz Ich würde sagen, diese Annahme wäre richtig. Ich habe gerade von Full Framework zu .net Core/Standard gewechselt und dann sind die Tests kaputt gegangen. Ich bin mir nicht sicher, ob es sich um eine Regression von 1.x handelt, da wir nur versucht haben, auf .net Standard 2.0 zu migrieren

niemyjski picture niemyjski am 22. März 2018
👍1

@niemyjski danke für die Bestätigung. Das ist an dieser Stelle eine ausreichende Information. Ich habe nur nach bekannten Fakten / Erfahrungen gesucht.

karelz picture karelz am 22. März 2018

Halten wir dieses Thema offen?

alexeyzimarev picture alexeyzimarev am 22. März 2018

Der Fix in CoreFx ist in der PR: https://github.com/dotnet/corefx/pull/28375

caesar-chen picture caesar-chen am 22. März 2018
🎉2

Ja :)

Danke
-Blake Niemyjski

Am Do, 22. März 2018 um 15:57 Uhr, Caesar Chen [email protected]
schrieb:

Der Fix in CoreFx ist in der PR: dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski picture niemyjski am 23. März 2018

Gab es einen Grund, warum wir nicht zu HttpClient wechseln konnten, das viel schneller ist?
und einfacher zu verarbeiten? Es würde dieses Problem nicht haben?

Danke
-Blake Niemyjski

Am Freitag, 23. März 2018 um 7:14 Uhr, Blake Niemyjski [email protected]
schrieb:

Ja :)

Danke
-Blake Niemyjski

Am Do, 22. März 2018 um 15:57 Uhr, Caesar Chen [email protected]
schrieb:

Der Fix in CoreFx ist in der PR: dotnet/corefx#28375
https://github.com/dotnet/corefx/pull/28375

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski picture niemyjski am 23. März 2018

@niemyjski meinst du, du wechselst RestSharp verwendet HttpClient statt HttpWebRequest ?

alexeyzimarev picture alexeyzimarev am 23. März 2018

Ja :)

Danke
-Blake Niemyjski

Am Freitag, 23. März 2018 um 9:22 Uhr, Alexey Zimarev [email protected]
schrieb:

@niemyjski https://github.com/niemyjski Du meinst, du schaltest aus
RestSharp verwendet HttpClient anstelle von HttpWebRequest?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375680769 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA-So0cbK66_Nq-MRdk0xwdb7sLPSGUoks5thQUUgaJpZM4SOXLx
.

niemyjski picture niemyjski am 23. März 2018

@niemyjski die Frage war die eine _oder_ die andere, _ja_ ist wirklich keine gültige Antwort :)

Wenn Sie meinen, dass RestSharp HttpClient verwenden sollte - ich bin dafür, aber als ich es das letzte Mal versucht habe, war es eine Menge Arbeit, alle Parameter im RestClient abzugleichen.

alexeyzimarev picture alexeyzimarev am 25. März 2018

Ja, wir sollten zu HttpClient wechseln, das viel mehr Flexibilität, eine bessere Leistung und eine moderne API bietet, von der wir wissen, dass sie überall funktioniert. Wir könnten ein paar bahnbrechende Änderungen vornehmen und den Major ankurbeln :)

niemyjski picture niemyjski am 25. März 2018

Ja, mir geht es gut, aber ich mache es nicht alleine. Ich habe es versucht und es war zu viel Arbeit. Ich würde auch Async-Aufrufe entfernen, die Rückrufe akzeptieren. ContinueWith sollte in Ordnung sein.

alexeyzimarev picture alexeyzimarev am 25. März 2018
👍1

Sieht so aus, als ob dies in 2.1 zusammengeführt wurde, sollten wir ein Nightly herausgeben, das auf die neuen Vorschau-2-Bits verweist und wir andere Pakete lange verschieben können? Gibt es Workarounds, die wir für < 2.1 Runtimes/Libs machen können?

niemyjski picture niemyjski am 20. Apr. 2018

Ich habe keine Ahnung von Problemumgehungen

alexeyzimarev picture alexeyzimarev am 20. Apr. 2018

Ich muss zuerst eine Veröffentlichung durchführen, bevor ich die Vorabversion in die Vorschauversion 2.1 ändern kann

alexeyzimarev picture alexeyzimarev am 20. Apr. 2018

Wurde das gelöst? 2.1 RTM-Pakete befinden sich auf Nuget.

niemyjski picture niemyjski am 1. Juni 2018

Also müssen Sie versuchen, 2.1 zu verwenden und sehen, ob sie es behoben haben?

alexeyzimarev picture alexeyzimarev am 1. Juni 2018

@niemyjski mein Kommentar vom 20. April ist doof. Ich muss nirgendwo etwas zeigen. Die Bibliothek wird nach .NET Standard 2.0 kompiliert. Der Fehler wird durch einen Fehler in der .NET Core 2.0-Laufzeit verursacht. Sobald Sie also Ihre Anwendung mit .NET Core 2.1 neu erstellen, sollte sie funktionieren, wenn das Problem behoben ist. Entschuldigung für die Verwirrung.

alexeyzimarev picture alexeyzimarev am 1. Juni 2018
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

ChenJasonGit picture ChenJasonGit  ·  5Kommentare
instriker picture instriker  ·  7Kommentare
stricq picture stricq  ·  6Kommentare
AlexanderSchoenfeld picture AlexanderSchoenfeld  ·  3Kommentare
nilsga picture nilsga  ·  5Kommentare