Axios: لا ترسل العنوان الافتراضي

تم إنشاؤها على ١٩ يوليو ٢٠١٦  ·  64تعليقات  ·  مصدر: axios/axios

إذا تم تعيين الرأس كافتراضي ، فلا يبدو أن هناك أي طريقة لتخطيه في طلب فردي. تعيين null أو undefined لا يفعل شيئًا.

headers

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

transformRequest: [(data, headers) => {
    delete headers.common.Authorization
    return data
}]

يعمل لدي

ال 64 كومينتر

هل يمكنك تقديم بعض الأمثلة البرمجية التي توضح هذا السلوك؟ ما العنوان الافتراضي الذي تحاول إلغاء تعيينه؟

إذا قمت بتعيين axios.defaults.headers.common['Content-Type'] = 'application/json' ، فلا يمكنني إلغاء تعيين هذا العنوان لطلب فردي ، يمكنني فقط تعيينه على قيمة أخرى.

كيف حاولت فك العنوان؟ باستخدام شيء مثل هذا؟

axios.request('/path', {
  headers: {
    'Content-Type': null
  }
});

نعم. التي لا تعمل

آسف فاتني method في المثال الخاص بي. يمكن أن يكون هذا ما جعله لا يعمل؟

لقد حاولت تحديد الطريقة أيضًا. أظن أن الأمر يتعلق بـ Object.assign() مكان ما لا ينتبه فقط إلى قيمة undefined .

tyrsius ما هو إصدار axios الذي تستخدمه؟ لقد كتبت للتو اختبارًا لمحاولة إعادة إنتاج هذا وقد نجح. أتساءل عما إذا كان هذا قد تم إصلاحه في إصدار أحدث.

كمرجع هنا هو اختباري:

it('should remove default headers when config indicates', function (done) {
  var instance = axios.create();
  instance.defaults.headers.common['Content-Type'] = 'application/json';

  instance.post('/foo/bar/', {
    firstName: 'foo',
    lastName: 'bar'
  }, {
    headers: {
      'Content-Type': null
    }
  });

  getAjaxRequest().then(function (request) {
    testHeaderValue(request.requestHeaders, 'Content-Type', null);
    done();
  });
});

كان لي هذه المشكلة أيضا.
أحاول إزالة العنوان "التفويض" من "عام" ولكن الطريقة الوحيدة التي وجدتها لإنجاحه هي حذف الخاصية من axios.defaults.header ، وتقديم الطلب ، ثم إعادة الخاصية مرة أخرى تكرارا.
سيكون هذا أسهل عندما يتم إصلاح هذا الخطأ

هذه أيضًا مشكلة بالنسبة لي (باستخدام axios v0.14.0) ، خاصة بالنسبة لنقاط النهاية التي تستخدم Access-Control-Allow-Headers ، وفي هذه الحالة أحتاج إلى التأكد من عدم إرسال رؤوس معينة مع الطلب على الإطلاق.

أنا أستخدم الإصدار 15.2 وعندما أفعل

headers: {
      'Content-Type': null
    }

يقوم بتعيين قيمة الرأس على قيمة خالية. لكني أحتاج حقًا إلى إزالة اسم الرأس تمامًا.

على سبيل المثال ، عند استخدام s3 وإنشاء عنوان url مخصص لنشر ملف إلى حاوية ، لا يمكنك الحصول على رأس مصادقة. ولكن لدي مجموعة تفويض افتراضية لأن الغالبية العظمى من طلباتي تتطلب ذلك لواجهة برمجة التطبيقات الخاصة بي.

الطريقة التي يمكنني بها الالتفاف حول هذا من خلال القيام بما يلي

    var instance = axios.create();
    instance.defaults.headers.common = {};

    instance.put(signedUrl, file, {headers: {'Content-Type': file.type}})
        .then(function (result) {
            console.log(result);
        })
        .catch(function (err) {
            console.log(err);
        });

تحرير: هذا لا يعمل كما هو متوقع. المشكلة هي أنه عند مسح الرؤوس

instance.defaults.headers.common = {};

يزيله على المستوى العالمي. سيؤدي هذا إلى تسجيل خروجي لأنني أستخدم رأسًا لـ Auth.

للتغلب على هذه المشكلة حتى تكون هناك طريقة أفضل للتعامل مع التكوين العام ، فأنا أقوم بتمرير الرؤوس المطلوبة في كل مكالمة ، وليست مثالية.

545

كان لدي نفس المشكلة ولكن حل مع

delete axios.defaults.headers.common["Authorization"]; // or which ever header you have to remove

لدي الوضع الدقيق كـSepiaGroup
حاولت استبداله بـ null و '' ولكن بعد ذلك ترى AWS أن null هو التفويض الخاص بي وتشتكي.
حاولت حذفه من المثيل ولكن بعد ذلك تم حذف التفويض الخاص بي بشكل عام لذا أحصل على 403 على خادمي الخاص.

أعتقد أن الحل سيكون استخدام XHR لهذا ولكن هذا يجعلني حزين :(

+1 عالق أيضًا بسبب عدم قدرته على مسح العنوان الافتراضي لمكالمة معينة.

+1

+1

أرى أيضًا هذا السلوك في أحدث إصدار (0.16.2). الحزن يستتبع:

فقط احذفه

delete instance.defaults.headers.common.Authorization
````

the way below is not working.
----
I think we could create a logout method that recreate the axios instance to replace the old one.

دع المثال = axios.create ({options})

الوظيفة: تسجيل الخروج () {
المثيل = axios.create ({options})
}
""

@ lzp4ever الذي سيعمل في معظم الحالات ، أتوقع. ولكن في الحالات التي أضاف فيها شخص ما معترضات للطلب والاستجابة ، أو قام بإجراء المزيد من التكوين للمثيل بما يتجاوز مجرد تمرير خيارات التكوين ، ألن يتطلب نهجك إعادة كل ذلك؟

فقط أتساءل عما إذا كان حل axelgenus أكثر نظافة ويتطلب "إعادة تعيين" أقل

سيكون من الجيد ألا تكون قادرًا على إرسال العنوان الافتراضي دون حذف الخصائص :)

+1

+1

+1. يبدو أنه من المحزن أنه لا يمكنك إزالة الرؤوس على سبيل المثال. هذا يعني أن جميع الحالات لها مرجع إلى المتغير العام.

+1

+1

+1 الرجاء إصلاح هذه المشكلة.

+1

+1

+1

نواجه نفس المشكلة. تحتاج معظم تطبيقات الواجهة الأمامية التي نقوم بإنشائها إلى استهلاك خدمات ويب Rest متعددة. يمثل عدم القدرة على إلغاء الاشتراك في رأس الأمان مشكلة كبيرة بالنسبة لنا.

+1

+1

جرب هؤلاء الأشخاص على كائن طلب محدد ، جنبًا إلى جنب مع الرؤوس والبيانات والطريقة:
transformRequest(data, headers) { delete headers.common.Authorization; return data; }

جرب هذا ، إنه حل مشكلتي:

حذف axios.defaults.headers.common ["التفويض"] ؛ // وإنشاء الرؤوس الخاصة بك

mukeshyadav تم ذكر هذا الحل عدة مرات في هذا الموضوع.

النقطة التي أثيرت هي أن هذا ليس بالضرورة الحل المثالي. تخيل سيناريو قمت فيه بإضافة معترضات الطلب / الاستجابة المخصصة إلى مثيل Axios ، لكنك تريد طلبًا محددًا واحدًا ألا يتضمن الرؤوس المستخدمة في أي مكان آخر ، فسيتعين عليك حذف العنوان (العناوين) وإعادة الإضافة بعد الطلب مكتمل.

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

+1

transformRequest: [(data, headers) => {
    delete headers.common.Authorization
    return data
}]

يعمل لدي

aaronatmycujoo هذا يبدو وكأنه الحل الأكثر جاذبية هنا. على الرغم من أن التساؤل عما إذا كان حذف الرأس مثل هذا يزيله من مثيل Axios أعلى السلسلة. قد يتعين عليك إنشاء نسخة عميقة من headers أو شيء من هذا القبيل.

سآخذ لاختبار ذلك.

مما يمكنني قوله لا. على الرغم من أنه يمكن أن تكون هناك حالة حافة لا أثيرها

SepiaGroup ، لست بحاجة إلى إضافة رؤوس في طلباتك بالكامل ... افعل هذا:

axios.defaults.headers.common = {};
axios.defaults.headers.common.accept = ‘application/json’;

وفي رؤوس الطلب ، سترى فقط "application / json"

+1 بفضل axelgenus نجح الحل الخاص بك

+1

تضمين التغريدة عمل حله مثل السحر ... تاي!

واجهت نفس المشكلة عند محاولة تحميل الملفات إلى S3 (السماح بآلية مصادقة واحدة فقط).
جربت الحل من SepiaGroup ولكنه يزيل أيضًا رأس المصادقة بشكل عام لجميع الحالات التالية:
aaronatmycujoo هذا الحل يعمل بشكل مثالي بالنسبة لي! 🎉
شكرا لكم يا رفاق لانقاذ يومي!

+1

+1

+1

axios.defaults.headers.common = {};
axios.defaults.headers.common.accept = ‘application/json’;

يعمل بشكل رائع بالنسبة لي !!!

لست متأكدًا مما إذا كانت هذه معرفة عامة ، ولكن هناك مجموعة من "العناوين المحظورة" ، والتي لا يمكن حذفها.

  • Accept-Charset
  • Accept-Encoding
  • Access-Control-Request-Headers
  • Access-Control-Request-Method
  • Connection
  • Content-Length
  • Cookie
  • Cookie2
  • Date
  • DNT
  • Expect
  • Host
  • Keep-Alive
  • Origin
  • Referer
  • TE
  • Trailer
  • Transfer-Encoding
  • Upgrade
  • Via

خطأ

TypeError: لا يمكن تحويل غير محدد أو فارغ إلى كائن

delete axios.defaults.headers.cummon["Authorization"];

لديك خطأ مطبعي @ putu-eka-mulyana وأعتقد أيضًا أن هذا هو المكان الخطأ للإبلاغ عن مثل هذه المشكلة.

delete axios.defaults.headers.common["Authorization"];

+1 ، قم بإزالة مجموعة الأحرف من نوع المحتوى

+1 ، قم بإزالة رأس المصادقة لطلب واحد فقط ، قم بأخذ كائن تهيئة الطلب دون حذفه صراحة ، فقط عن طريق تمرير بعض القيمة مثل غير محدد أو فارغ

+1 ، قم بإزالة رأس المصادقة لطلب واحد فقط ، قم بأخذ كائن تهيئة الطلب دون حذفه صراحة ، فقط عن طريق تمرير بعض القيمة مثل غير محدد أو فارغ

لدي طلب OPTION قبل طلب PUT الخاص بي ، لذلك نجح حل

في النهاية ، انتهيت من إنشاء نسخ منفصلة لطلبات المصادقة مقابل الطلبات العامة ، لذلك تم تطبيق رأس المصادقة الخاص بي فقط على نسخة المصادقة.

// do not configure auth header
export const publicAxios = axios.create(...)

// configure auth header
export const authAxios = axios.create(...)

// no auth header present for public instance
publicAxios.put(...)

يسمحrizen PR # 1845 بواسطة codeclown بعدم ضبط الرؤوس بتمرير null . هل هذا يحل المشكلة؟

يسمحrizen PR # 1845 بواسطة codeclown بعدم ضبط الرؤوس بتمرير null . هل هذا يحل المشكلة؟

نعم

يا لها من رحلة طويلة. تم دمج Hope # 1845 في أسرع وقت ممكن.

transformRequest: [(data, headers) => {
    delete headers.common.Authorization
    return data
}]

من وثائق أكسيوس:

> هذا ينطبق فقط على طرق الطلب "PUT" و "POST" و "PATCH" و "DELETE"

أواجه موقفًا مشابهًا إلى حد ما ولكن مع طلب GET:

  1. احصل على http://www.saasserviceprovider.com/notpublicapi برأس Authorization: Bearer mytoken
  1. يعيد التوجيه إلى نقطة نهاية AWS S3. يحتوي عنوان URL لإعادة التوجيه على سلسلة استعلام: تم إلحاق X-Amz-Signature=blahblahblah .

  2. يرفض AWS S3 المكالمة لأن اثنين من Authenication:

    • العنوان: Authorization bearer token
    • سلسلة الاستعلام: X-Amz-Signature=blahblahblah

لا يبدو أن transformRequest ، transformResponse ، axios.interceptors.request ، axios.interceptors.response قادر على السماح لي بإدخال نفسي في العملية وإزالة رأس التفويض مؤقتًا عند الضغط على إعادة التوجيه إلى AWS S3 - من المفترض أنه إذا تمكنت من الدخول بعد إعادة التوجيه ، فيمكنني فعل شيء لتحقيق تأثير delete headers.Authorization .

نفس المكالمة مع طلب api / postman / etc work.

"الحل البديل":

هذا هو POS تبخير قبيح غير فعال ... لكنه "يعمل ™". هل أحصل على تمويل VC الآن؟

  let retry = false;
  await axios({
    method: 'get',
    url: "http://www.saasserviceprovider.com/notpublicapi",
    headers: {
      'Authorization': "Bearer mytoken",
    }
  })
  .then((r) => {
    //return successful
  })
  .catch ((e) => {
    if (e.request.res.responseUrl.match(/s3.amazonaws.com/)) {
      retry = e.request.res.responseUrl;
    } else {
          //log error
    }
  })

  //Retry
  if (retry) {
    await axios.get(retry)
    .then((r) => {
        //return successful
      }
    })
    .catch((e) => {
       //log error
    })
  }

على محمل الجد ... يجب أن تكون طريقة أفضل (ضمن أكسيوس)

أواجه موقفًا مشابهًا إلى حد ما ولكن مع طلب GET:

  1. احصل على http://www.saasserviceprovider.com/notpublicapi برأس Authorization: Bearer mytoken
  2. يعيد التوجيه إلى نقطة نهاية AWS S3. يحتوي عنوان URL لإعادة التوجيه على سلسلة استعلام: تم إلحاق X-Amz-Signature=blahblahblah .
  3. يرفض AWS S3 المكالمة لأن اثنين من Authenication:
  • العنوان: Authorization bearer token
  • سلسلة الاستعلام: X-Amz-Signature=blahblahblah

لا يبدو أن transformRequest ، transformResponse ، axios.interceptors.request ، axios.interceptors.response قادر على السماح لي بإدخال نفسي في العملية وإزالة رأس التفويض مؤقتًا عند الضغط على إعادة التوجيه إلى AWS S3 - من المفترض أنه إذا تمكنت من الدخول بعد إعادة التوجيه ، فيمكنني فعل شيء لتحقيق تأثير delete headers.Authorization .

نفس المكالمة مع طلب api / postman / etc work.

على محمل الجد ... يجب أن تكون طريقة أفضل (ضمن أكسيوس)

iyerusad هل وجدت أي طريقة أفضل من الحل البديل الخاص بك؟ أواجه نفس المشكلة ، ومن المحبط أنني لا أستطيع اعتراض إعادة التوجيه وحذف رأس التفويض فقط لطلب المتابعة / إعادة التوجيه (إلى أمازون في هذه الحالة) 🤔

iyerusad هل وجدت أي طريقة أفضل من الحل البديل الخاص بك؟ أواجه نفس المشكلة ، ومن المحبط أنني لا أستطيع اعتراض إعادة التوجيه وحذف رأس التفويض فقط لطلب المتابعة / إعادة التوجيه (إلى أمازون في هذه الحالة) 🤔

ليس حقًا - باستخدام الخيار ( ب) من الأسفل.

_الخيارات التي قمت بتقييمها: _
أ. اعتماد برنامج تضمين / عميل بديل (على سبيل المثال ، يبدو أن طلب جلب واجهة برمجة التطبيقات (api؟ request) يعمل ولكن يبدو أنه مهمل). قد يكون هذا الخيار الأنظف ولكنه يعني التبديل إلى بنية عميل http أخرى.

ب. قم بتغليف الحل البديل الخاص بي في دالة واستخدم هذه الوظيفة للطلبات التي أعرف أنها تواجه هذه المشكلة - يبدو الأمر قبيحًا على ما يبدو أقل كفاءة ولكن باستخدام هذا في الوقت الحالي.

ج. أتمنى أن أكون أحمق وأستخدم الأكسيوس بشكل خاطئ وهناك حل أفضل مع الأكسيوس.

D. الحصول على أكسيوس الإصلاح / التصحيح؟

mikhoqiyerusad هل تمانع في فتح قضية جديدة لتتبع مشكلتك؟ لأنه يختلف عن الحالي والذي ربما تم إصلاحه في # 2844.

لا مشكلة - تم فتحه # 2855.

mikhoq يرجى إضافة تعليق هناك إذا كان لديك نقطة نهاية repro عامة.

لذلك يبدو transformRequest يحصل دعا إلى GET الطلبات؟ لقد جربت هذا ونجحت ، فحذف فقط رأس الطلب الحالي.

transformRequest: [(data, headers) => {
    delete headers.common.Authorization
    return data
}]

لكن المستندات تقول

// transformRequest يسمح بإجراء تغييرات على بيانات الطلب قبل إرسالها إلى الخادم
// ينطبق هذا فقط على طرق الطلب "PUT" و "POST" و "PATCH" و "DELETE"

مما جعلني أعتقد أن transformRequest لن يتم استدعاؤه لطلبات GET ، لكنه كذلك. إذن ماذا يعني هذا الخط في الواقع؟

"هذا ينطبق فقط على طرق الطلب" PUT "و" POST "و" PATCH "و" DELETE ""

ربما ، "يحتمل أن يكون هذا مفيدًا فقط لـ ...." ....؟ انها مضللة المنظمة البحرية الدولية.

هذا يعمل:
الرؤوس: {
"نوع المحتوى": "application / json"،
"التخويل": لاغٍ ،
}

حاولت تعيين { headers: { 'Content-Type' = null } } دون جدوى ،
ولإضافة تعليق مفيد إلى axelgenus ، كان علي أن أذهب إلى أبعد من ذلك بقليل:

import Axios from 'axios'
const client = Axios.create({
  // ...
  transformRequest: [(data, headers) => {
    // add required "Content-Type" whenever body is defined
    if (data) headers['Content-Type'] = 'application/x-www-form-urlencoded'
    return data
  }],
})
// completely remove "Content-Type" from instance by default
delete client.defaults.headers.common['Content-Type']
delete client.defaults.headers.post['Content-Type']
delete client.defaults.headers.put['Content-Type']
delete client.defaults.headers.patch['Content-Type']
// ...

حالة الاستخدام هي تنفيذ طبقة الطلبات لطريقة مصادقة V2 .

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