Restsharp: يتم تجريد المنفذ من رأس المضيف

تم إنشاؤها على ٢١ فبراير ٢٠١٨  ·  35تعليقات  ·  مصدر: restsharp/RestSharp

سلوك متوقع

يجب أن يرسل Restsharp رأس المضيف كما هو بدون تعديل المنفذ في قيمة رأس المضيف.
https://github.com/minio/minio-dotnet/pull/212 يجلب Restsharp 106.2.1 بدلاً من Restsharp.Netcore (إصدار غير رسمي مع دعم netcore). ومع ذلك ، وجدنا أخطاء عدم تطابق التوقيع لأن المصدق المخصص المستخدم بواسطة minio dotnet sdk ينشئ توقيع التفويض باستخدام ip: port كقيمة لرأس "المضيف". يبدو أن Restsharp httpclient يقوم بتجريد المنفذ ، حيث يظهر تتبع الخادم ip فقط في قيمة رأس المضيف.

السلوك الفعلي

يتم تجريد المنفذ من قيمة رأس "المضيف" في Restsharp 106.2.1

خطوات إعادة إظهار المشكلة

  1. استنساخ minio-dotnet sdk واحصل على التصحيح https://github.com/minio/minio-dotnet/pull/212
    ➜ بوابة minio-dotnet: (02cbcb5) ✗ استعادة dotnet ؛ بناء dotnet
    ➜ بوابة minio-dotnet: (02cbcb5) ✗ تشغيل dotnet - مشروع SimpleTest
    2.
    3.

تحديد

تتبع المكدس

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]]

التعليق الأكثر فائدة

دعونا نرفعها!

ال 35 كومينتر

هل هناك طريقة لإعادة إنتاجه في اختبار بسيط؟

https://github.com/poornas/restsharp-test - هذا مشروع مكشوف باستخدام restsharp لإجراء استدعاء مستودعات القائمة إلى خادم minio. يستخدم مصدقًا مخصصًا - سترى أنه فشل بسبب عدم تطابق التوقيع. بمجرد تمرير الطلب إلى restsharp ، يتم تجريد المنفذ قبل أن يتم تمريره إلى الخادم.

شكرا. سوف ألقي نظرة وأحاول إصلاحها.

شكرا!

alexeyzimarev هل من أفكار حول سبب حدوث ذلك؟

alexeyzimarev ، هل لديك فرصة للنظر في هذا حتى الآن؟ شكرا

فحص الآن

لقد قمت باستنساخ نسختك وأرى هذا:

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

هل تقصد أن المعلمات في الطلب جيدة ولكن القيمة لا يتم إرسالها بشكل صحيح إلى الخادم؟

alexeyzimarev ، هذا صحيح - التتبع الذي تراه أعلاه قبل استدعاء executeAsync. عندما يتم استدعاء ExecuteAsync ، يستدعي Restsharp طريقة المصادقة ، حيث نقوم بتعيين رأس ترخيص التوقيع بناءً على عنوان url: المنفذ في المصادقة المخصصة. يبدو أن المنفذ قد تم تجريده بواسطة Restsharp قبل الضغط على الخادم وبعد استدعاء Authenticate ().

أي تحديثات على هذا؟ نحن محظورون بشدة على هذا.

آسف لم أتمكن من النظر إلى هذا حتى الآن. إذا كان الأمر حرجًا للغاية ، فهل يمكنك قضاء ساعة في تصحيحه؟

لقد ألقيت نظرة سريعة على هذا. بقدر ما أستطيع أن أقول ، فإن المشكلة هنا ليست في الواقع مع RestSharp ، لكنها في الواقع HttpWebRequest في System.Net !

بحلول الوقت الذي سلمت فيه RestSharp الطلب إلى System.Net ، لا تزال الخاصية Host (Uri) في HttpWebRequest تحتوي على معلومات المنفذ. ومع ذلك ، عندما يتم استدعاء .SendRequest() ، يتم ملء رأس المضيف المستخدم بواسطة مضيف URI فقط ، وليس المضيف والمنفذ .

هذه لقطة شاشة من مصحح الأخطاء الخاص بي على الرابط أعلاه.
screen shot 2018-03-22 at 11 22 52 am

من الواضح أن هذا يتعارض مع مواصفات HTTP التي تحترم استخدام المنافذ.

رجاءً ، يصحح لي شخص ما إذا كنت مخطئًا ، لأنني لم أجد أبدًا خطأ في إطار عمل dotnet ، وعادةً عندما أعتقد أنني - لم أجد ذلك. وإلا أفترض أن الخطوات التالية ستكون إثارة هذه المشكلة في CoreFX repo؟

دعونا نرفعها!

تم - دعنا نرى ما إذا كان هذا شرعيًا حيث يوجد الخطأ أم لا.

مجرد فضول - هل يعرف أي شخص ما إذا كان هذا هو الانحدار مع NET Core الحديثة؟ (2.1) أم بآخر مستقر (2.0)؟ أو الفرق بين .NET Framework و .NET Core ، أو الفرق بين OS Windows مقابل Linux؟ ("لا أعرف" إجابة جيدة ، شكرًا!)

karelz TBH لقد بحثت في هذه المشكلة لحل مشكلة أخرى حتى أتمكن من التوقف عن تلقي تحذيرات المترجم بالنسبة لي ، إنها "لا أعرف" ، لقد جربت هذا فقط على .NET Core 2.0 على MacOS. تمت ترقية هذه المكتبة مؤخرًا (ربما أشهر) لدعم NET Core عبر .NET Framework فقط. ربما alexeyzimarev قد يعرف المزيد؟

حسنًا ، حتى تعرف على الأقل: إنه يعمل على .NET Framework (Windows) ويفشل في .NET Core 2.0 (Mac). هل هذا ملخص صحيح؟

لا - من سلاسل الرسائل الأخرى التي أستخدمها ، أقول إنها فشلت في جميع الأنظمة الأساسية على .NET Core 2.0 ، ولا أعرف شيئًا عن .NET Framework.

karelz أقول أن الافتراض سيكون صحيحًا. لقد غيرت للتو من الإطار الكامل إلى. net core / القياسي ثم تعطلت الاختبارات. لست متأكدًا مما إذا كان هذا انحدارًا من 1.x لأننا حاولنا فقط الترحيل إلى .net القياسي 2.0

niemyjski شكرا للتأكيد. هذه معلومات كافية في هذه المرحلة. كنت أستكشف الحقائق / التجارب المعروفة.

هل نبقي هذه القضية مفتوحة؟

الإصلاح في CoreFx موجود في العلاقات العامة: https://github.com/dotnet/corefx/pull/28375

نعم :)

شكرا
-بليك نيميجسكي

يوم الخميس ، 22 مارس 2018 الساعة 3:57 مساءً ، Caesar Chen [email protected]
كتب:

الإصلاح في CoreFx موجود في PR: dotnet / corefx # 28375
https://github.com/dotnet/corefx/pull/28375

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

هل كان هناك أي سبب لعدم تمكننا من التبديل إلى HttpClient وهو أسرع بكثير
وأسهل للعمل معها؟ لن يكون لديها هذه المشكلة؟

شكرا
-بليك نيميجسكي

يوم الجمعة ، 23 آذار (مارس) 2018 الساعة 7:14 صباحًا ، بليك Niemyjski [email protected]
كتب:

نعم :)

شكرا
-بليك نيميجسكي

يوم الخميس ، 22 مارس 2018 الساعة 3:57 مساءً ، Caesar Chen [email protected]
كتب:

الإصلاح في CoreFx موجود في PR: dotnet / corefx # 28375
https://github.com/dotnet/corefx/pull/28375

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375454963 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AA-So67a2QfPq72jMHNxaSCBhDXiWXOMks5thBAygaJpZM4SOXLx
.

niemyjski تقصد أن التبديل من RestSharp يستخدم HttpClient بدلاً من HttpWebRequest ؟

نعم :)

شكرا
-بليك نيميجسكي

يوم الجمعة 23 مارس 2018 الساعة 9:22 صباحًا ، أليكسي زيماريف إخطارات @github.com
كتب:

niemyjski https://github.com/niemyjski تقصد أنك قمت بالتبديل
يستخدم RestSharp HttpClient بدلاً من HttpWebRequest؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/restsharp/RestSharp/issues/1085#issuecomment-375680769 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AA-So0cbK66_Nq-MRdk0xwdb7sLPSGUoks5thQUUgaJpZM4SOXLx
.

nemyjski ، السؤال كان _أو_ آخر ، _yes_ في الحقيقة ليس إجابة صحيحة :)

إذا كنت تقصد أن RestSharp يجب أن يستخدم HttpClient - فأنا مؤيد لذلك ولكن في المرة الأخيرة التي جربت فيها الكثير من العمل لمطابقة جميع المعلمات في RestClient.

نعم ، يجب أن ننتقل إلى HttpClient الذي يتمتع بقدر أكبر من المرونة وأداء أفضل وواجهة برمجة تطبيقات حديثة نعرف أنها تعمل في كل مكان. يمكننا إجراء بعض التغييرات العاجلة وإدخال التغييرات الرئيسية :)

نعم ، أنا بخير للقيام بذلك ولكني لا أفعل ذلك بمفردي. حاولت وكان الكثير من العمل. أود أيضًا إزالة مكالمات Async التي تقبل عمليات الاسترجاعات. استمر مع يجب أن يكون على ما يرام.

يبدو أنه تم دمج هذا في 2.1 ، فهل يجب أن نصدر نشرة ليلية تشير إلى المعاينة الجديدة 2 بت ويمكننا نقل الحزم الأخرى لفترة طويلة؟ هل هناك أي عمل بديل يمكننا القيام به لـ <2.1 أوقات تشغيل / libs؟

ليس لدي أي فكرة عن الحلول

أحتاج إلى إجراء إصدار أولاً قبل أن أتمكن من تغيير الإصدار التجريبي للإشارة إلى معاينة 2.1

هل تم حل هذا؟ حزم 2.1 rtm على nuget.

لذا ، أنت بحاجة إلى محاولة استخدام الإصدار 2.1 ومعرفة ما إذا تم إصلاحه؟

niemyjski تعليقي من 20 أبريل غبي. لست بحاجة إلى توجيه أي شيء إلى أي مكان. تقوم المكتبة بالتجميع إلى .NET Standard 2.0. حدث الخطأ بسبب خطأ في وقت تشغيل .NET Core 2.0 ، وبمجرد إعادة إنشاء التطبيق باستخدام .NET Core 2.1 ، إذا تم إصلاح المشكلة ، يجب أن يبدأ العمل. آسف على الارتباك.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات