Axios: لا يمكن الحصول على وظيفة عبر المواقع للعمل

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

مرحبا،

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

  • crossDomain: صحيح
  • xDomain: صحيح
    * xDomainRequest: صحيح

إلى التكوين. ولم يعمل أي منهم. (إذا كانت هذه الميزة متاحة بالفعل ، فسيساعد تحديث الملف التمهيدي.)

يرجى تقديم المشورة في أسرع وقت ممكن. شكرا لك.

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

كيف لا يتم التعامل مع مثل هذه القضية الضخمة؟

ال 70 كومينتر

بالإضافة إلى ذلك ، أقوم أيضًا بتعيين بيانات الاعتماد على true في ملف التكوين.

لقد واجهت هذه المشكلة أيضًا ويبدو أنها تحدث فقط بالنسبة لي على Mac. لقد أمضيت 3 أيام وليالٍ جيدة في محاولة تصحيح أخطاء شبكتي وقررت أن أجرب ذلك باستخدام طلب Vanilla XHR وأدركت أن المشكلة لم تكن شبكتي ، بل أكسيوس.

أنا أيضًا أقوم بطلبات عبر المواقع مع تعيين بيانات الاعتماد على "صحيح". بالنظر إلى طلب الشبكة ، تحصل على ERR_EMPTY_RESPONSE ويبدو الأمر وكأن الطلب قد فشل قبل أن يغادر المتصفح.

هذا هو التكوين الخاص بي:

const myApi = axios.create({
  baseURL: 'http://someUrl/someEndpoint',
  timeout: 10000,
  withCredentials: true,
  transformRequest: [(data) => JSON.stringify(data.data)],
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json',
  }
});'

إذا سنحت لي الفرصة سأحاول النظر في هذا الأمر أكثر.

أوه جيد أنا لست مجنونة. :) الرجاء النظر في هذا إذا كان ذلك ممكنا.

تبين أن مشكلتي لا علاقة لها بـ Axios. كان Cisco Anyconnect يحظر طلبات الخيارات من جهازي ... لأسباب؟

لا تتطلب الطلبات عبر النطاقات أي تكوين إضافي. سوف يعود إلى استخدام XDomainRequest لـ IE الأقدم. https://github.com/mzabriskie/axios/blob/master/lib/adapters/xhr.js#L22

هل يمكنك أن تعطي معلومات إضافية؟ أي متصفح ، نظام تشغيل ، إصدار أكسيوس ، أي رسائل خطأ.

لا يمكنني التحدث عن Jenny ولكن شيئًا ما على وجه الخصوص هذه المكتبة يتسبب في حظر الطلبات بواسطة أمان Cisco Anyconnect الافتراضي مما يعني أنه من الممكن أن تقوم إعدادات الأمان الأخرى بذلك أيضًا. أحاول تعقب ذلك ولكن لم يحالفني الحظ حتى الآن.

يمكن إعادة إنتاج ذلك عن طريق إجراء طلب عبر الموقع على جهاز Mac مثبت عليه cisco Anyconnect وربما عملاء VPN آخرين.

بيئتي هي:

  • Axios 0.8.1
  • إل كابيتان
  • كروم
  • رسالة الخطأ: "لا يوجد رأس" Access-Control-Allow-Origin "موجود على المورد المطلوب. لذلك فإن الأصل ' http: // localhost : 3000' غير مسموح له بالوصول."

لاحظ أن نفس الطلب يعمل مع curl.

شكرا للنظر في هذا!

باستخدام CORS ، يتم إجراء طلب الاختبار المبدئي إلى الخادم لمعرفة ما إذا كان الطلب مسموحًا به. ستحتاج إلى أن يستجيب خادمك للطلبات التي تحتوي على OPTIONS كطريقة طلب عن طريق تعيين العنوان Acces-Control-Allow-Origin: * والذي سيسمح بالطلبات من أي مصدر. بدلاً من ذلك ، يمكنك السماح بأصول معينة فقط Acces-Control-Allow-Origin: http://example.com .

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

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

هل يمكنك فتح علامة تبويب الشبكة في متصفحك ومشاركة ما تحصل عليه كاستجابة لطلب OPTIONS؟ نأمل أن تساعد رؤية بيانات الاستجابة والعناوين في تصحيح هذه المشكلة.

شكرا

فيما يلي الرؤوس:

image

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

screen shot 2016-01-19 at 11 36 54 am

يمكنك أن ترى أن GitHub يضيف Access-Control-Allow-Origin: * . تفتقد الاستجابة الواردة من Baas لأي رؤوس من النوع Access-Control .

أرى أرى همم. آسف على الرد المتأخر للغاية. اسمحوا لي أن أنظر في هذا أكثر قليلا. شكرا جزيلا لك.

لست متأكدًا مما إذا كان ما أراه مرتبطًا أم لا. في الأساس ، يمكنني إرسال طلب مصادقة إلى خادمنا البعيد واستعادة ملف تعريف ارتباط ، ولكن بعد ذلك المكالمات اللاحقة إلى الخادم _ لا ترسل ملفات تعريف الارتباط معها ، مما يؤدي إلى حدوث خطأ.

فيما يلي الرؤوس من المكالمة POST لتسجيل الدخول:
login

والآن متابعة GET call:
verify

عنوان IP المدرج ضمن origin هو عنوان IP الخاص بي ، لذا لا ينبغي أن تكون هذه مشكلة. إذا كان هذا هو المكان الخطأ لذلك ، يسعدني إصدار عدد جديد أو إرفاق المشكلة الحالية المناسبة.

كتجاعيد جديدة ؛ لقد اختبرت مكالمة متابعة GET باستخدام XHR مباشرة ، ويتم إرسال ملف تعريف الارتباط على ما يرام. ومع ذلك ، يؤدي إجراء نفس المكالمة من خلال Axios إلى نفس المشكلة التي ذكرتها أعلاه.

قرف. الرجاء تجاهل ذلك - لم أكن أرسل الأشياء كما هو متوقع من خلال Axios :)

أنا أيضا أواجه نفس المشكلة.
OPTIONS Call يذهب من خلال ، ولكن مكالمات POST تتعطل.
http://stackoverflow.com/questions/36907693/axios-cors-issue-with-github-oauth-not-getting-access-token

كيف لا يتم التعامل مع مثل هذه القضية الضخمة؟

+1

+1

+1

+1

+1

+1

+1

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

الحصول على هذا أيضا

لا يمكن لـ XMLHttpRequest تحميل https://en.wikipedia.org/w/api.php؟action=opensearch&format=json&search=fish. لا يوجد رأس "Access-Control-Allow-Origin" موجود في المورد المطلوب. لذلك فإن الأصل " http: // localhost : 3000" غير مسموح له بالدخول.

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

إليك بعض الأمثلة (يتم عرض كلاهما عبر https)

مثال 1 - يعمل بشكل جيد

axios.get('https://randomuser.me/api/')
  .then(function (response) {
    console.log(response.data);
  })
  .catch(function (error) {
    console.log(error);
  });

Exampel 2 - لا يعمل - هل تظهر خطأ؟

axios.get('https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish')
  .then(function (response) {
    console.log(response.data);
  })
  .catch(function (error) {
    console.log(error);
  });

ها هي استجابة الخطأ

[object Error] {
  config: [object Object] {
    data: undefined,
    headers: [object Object] { ... },
    maxContentLength: -1,
    method: "get",
    timeout: 0,
    transformRequest: [object Object] { ... },
    transformResponse: [object Object] { ... },
    url: "https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish",
    validateStatus: function validateStatus(status) {
      return status >= 200 && status < 300;
    },
    xsrfCookieName: "XSRF-TOKEN",
    xsrfHeaderName: "X-XSRF-TOKEN"
  },
  response: undefined
}

شيء قد يكون ذا صلة في استجابة التحويل؟ أتساءل ماذا يعني بت PROTECTION_PREFIX؟

[object Object] {
  0: function transformResponse(data) {
      /*eslint no-param-reassign:0*/
      if (typeof data === 'string') {
        data = data.replace(PROTECTION_PREFIX, '');
        try {
          data = JSON.parse(data);
        } catch (e) { /* Ignore */ }
      }
      return data;
    }
}

حتى تحاول

الوضع: "no-cors"
في الجلب لا يزال يعطي هذا الخطأ

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

قد تكون واجهة برمجة تطبيقات ويكيبيديا مجرد مثال متزعزع ، ونفس الخطأ على الآخرين؟

أحذف هذا الرمز ، يمكن أن يعمل: axios.defaults.withCredentials = true

حصلت على wikipedia api للعمل بشكل جيد مع jsonp

var jsonp = require('jsonp');

// search for 'frog'
jsonp('https://en.wikipedia.org/w/api.php?action=opensearch&search=frog&format=json', null, function (err, data) {
  if (err) {
    console.error(err.message);
  } else {
    console.log(data);
  }
});

لا توجد تكوينات إضافية مطلوبة.

الحصول على نفس الخطأ مع أكسيوس. ها هو مكوِّن React الخاص بي:

import React, { Component } from 'react'
import axios from 'axios'

export default class User extends Component {
  constructor(props){
    super(props)

    // axios.defaults.withCredentials = true

    const config = {
    method: 'get',
    url: 'https://api.airbnb.com/v2/users/2917444?client_id=3092nxybyb0otqw18e8nh5nty&_format=v1_legacy_show',
    headers: {'X-Requested-With': 'XMLHttpRequest'},
    responseType: 'json',
    withCredentials: true,
  }

    axios.request(config)
      .then(response => { console.log('response: ', response) });

  }

  render() {
    return (
      <div>User</div>
    )
  }
}

_ ملاحظة: يمكنني الوصول إلى واجهة برمجة التطبيقات بشكل جيد تمامًا مع طلب العقدة.

أنا أواجه نفس الخطأ الذي Sinistralis . في أحدث إصدار من Chrome في Mac OSX ، أحصل على net::ERR_EMPTY_RESPONSE على طلبات CORS التي تم إجراؤها بشكل صحيح (يتعامل خادمي مع جميع رؤوس CORS بما في ذلك OPTIONS على ما يرام). إنه أمر غريب لأنه في iOS10 Safari ، يعمل نفس الرمز بالضبط دون أي مشاكل. سأحاول التحقيق أكثر من ذلك بقليل بنفسي لمعرفة كيف يمكن حل ذلك.

على جهاز Mac أقدم (10.11) مع أحدث إصدار من chrome ، لا يمكنني إعادة إنتاج هذا الخطأ بنفس الرمز بالضبط. هذا غريب جدا حقا قد تتمكن من إعادة الإنتاج من خلال زيارة هذا التطبيق البسيط للغاية: http://lights.suyashkumar.com وفحص وحدة التحكم (الرمز موجود هنا . لن يكون هناك خطأ في بعض الأجهزة وسيعيد توجيهك لتسجيل الدخول. في البعض الآخر لن يتم إعادة التوجيه وسيتركك على الصفحة الرئيسية.

حل خطأي. بالنسبة لي ، كانت مشكلة تعيين رأس في config.headers بقيمة فارغة عند بدء التطبيق (يسحب قيمة من التخزين المحلي ، وفي البداية ، لا يوجد شيء). يؤدي تعيين القيمة على أنها سلسلة فارغة عندما تكون القيمة فارغة إلى حل المشكلة. أتساءل عما إذا كان هذا أمرًا يمكن أو يجب التعامل معه داخل المحاور (لست متأكدًا مما إذا كانت هناك قيمة في تمرير العناوين الفارغة إلى xhr إذا كانت تنكسر _أحيانًا _).

بالنسبة للآخرين الذين لديهم مشكلة مماثلة ، وجدت أن بعض عملاء VPN يمكنهم أيضًا حظر طلبات OPTIONS (انظر هنا )

لا يزال خطأ CORS المضلل في المحاور. يدعم polyfill fetch mode: 'no-cors' لإصلاح هذه المشكلة.

نحتاج إلى تنفيذ هذه الأنواع من الطلبات لتقديم طلبات ضد آلات في بيئات أخرى نعمل فيها ، وكذلك على نفس الجهاز في منافذ مختلفة!

dreki يرجى تقديم وصف للمشكلة التي ذكرتها.

لا يمكنك فعل أي شيء من جانب العميل ، عندما لا يقبل الخادم ببساطة الطلبات من أصلك. إذا استطعت ، فسيحدث تسريب أمني ضخم هنا (ومع "نحن" أعني الإنترنت بالكامل) ...

أعتقد أن أكسيوس تعمل وتتفاعل بشكل مطابق تمامًا هنا.

رأس الاستجابة المهم هو Access-Control-Allow-Origin والذي يحدد بشكل أساسي الأصول الصالحة ، المسموح لها باستدعاء هذه الخدمة من جانب الخادم. إذا كان عميلك لا يتصل من أي من هذه الأصول المهيأة ، فسيتم رفض الطلب مع ظهور خطأ في وحدة التحكم مثل هذا:

لا يمكن لـ XMLHttpRequest تحميل http: // localhost : 8080 / v1 / api / search؟ q = candles. لا يوجد رأس "Access-Control-Allow-Origin" موجود في المورد المطلوب. لذلك فإن الأصل " http: // localhost : 9999" غير مسموح له بالدخول.

أنت لست على قائمة المدعوين.

أصلحت مشكلتي.
كنت أحاول الوصول إلى واجهة برمجة التطبيقات السريعة الخاصة بي على localhost:3000 من تطبيق vue الخاص بي على localhost:8080 ، ولكن كان هناك خطأ في العودة.
تبين أنك بحاجة إلى إضافة http:// حتى تعمل.
لذا استخدم http://localhost:3000 بدلاً من localhost:3000 عند إجراء اختبار التطوير.

لدي نفس المشكلة مع wikmedia api. بالنظر إلى صفحة CORS الخاصة بهم (https://www.mediawiki.org/wiki/Manual:$wgCrossSiteAJAXdomains) أضفت origin = * إلى الطلب وتم حل المشكلة.

axios.get('https://en.wikipedia.org/w/api.php?action=opensearch&format=json&origin=*&search=Albert') .then(function(res) { console.log(res); }) .catch(function(err) { console.log('Error: =>' + err); })

على الرغم من أنني تلقيت رسالة خطأ cors المخيفة ، إلا أن طلبي كان يصيب الخادم.

XMLHttpRequest cannot load "...url here...". No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.

فريق أكسيوس ، هل يمكنك الإصلاح من فضلك ؟؟؟

mellogarrett هذه ليست مشكلة متعلقة https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

استشهاد هام:

"لأسباب تتعلق بالأمان ، تقوم المتصفحات بتقييد طلبات HTTP عبر الأصل التي يتم بدؤها من داخل البرامج النصية. على سبيل المثال ، يتبع XMLHttpRequest و Fetch سياسة الأصل نفسه. لذلك ، يمكن لتطبيق ويب يستخدم XMLHttpRequest أو Fetch فقط إرسال طلبات HTTP إلى المجال الخاص به. إلى تحسين تطبيقات الويب ، طلب المطورون من بائعي المستعرضات السماح بطلبات عبر المجالات. "

ربما لا يستجيب الخادم لطلب OPTIONS إلى العديد ممن لديهم هذه المشكلة. تأكد من أن لديك معالجات (برؤوس CORS) لكل من طلبات OPTIONS و POST. العميل (أكسيوس) سوف يقوم أولاً بتنفيذ أمر ping OPTIONS ثم يقوم بـ POST.

لدي نفس الخطأ في Firefox ، لكن ليس على Chromium. ثم تذكرت أن NoScript كان هناك (في Firefox) يمنع الطلب إلى الخادم البعيد. في حالة تثبيت NoScript (أو مكون إضافي مشابه) ، تحقق من ذلك أولاً.
في حالتي ، لم تكن القضية متعلقة بـ Axios. شكرا على العمل العظيم.

بالنسبة لأي شخص آخر يبحث عن حل لهذه المشكلة ، كان لدي كل الأعراض نفسها ولكن تتبعت المشكلة إلى إعداد php.ini على الخادم.

كان طلب خيارات الاختبار المبدئي الخاص بي ناجحًا وتبعه طلب POST مناسب ولكني ما زلت أحصل على No 'Access-Control-Allow-Origin' header is present on the requested resource... مشابه لـ mellogarrett . بدا هذا غريبًا تمامًا لذا استخدمت مكونًا إضافيًا من Chrome لتعطيل حماية CORS مؤقتًا. بعد ذلك ، استطعت أن أرى أن المشكلة كانت في الواقع خطأ PHP:

Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0

يحتوي هذا المنشور على مزيد من المعلومات حول المشكلة ، ولكن باختصار ، إذا كنت تستخدم PHP 5.6 ، فيجب عليك إلغاء التعليق always_populate_raw_post_data في ملفك php.ini وتعيينه على -1 . آمل أن يوفر هذا على شخص آخر بضع ساعات من استكشاف الأخطاء وإصلاحها 🤓

مرحبًا daltonamitchell يبدو أنني أواجه نفس المشكلة (تشير الظروف إلى أنها نفس المشكلة). لكني أتساءل: كيف عرفت أن خطأ ما بعد البيانات الخام كان هو المشكلة؟ عند استخدام المكون الإضافي chrome ، ذكرت أن طلب CORS يمر وكل شيء يعمل بشكل جيد. ولكن على الرغم من ضبط الرؤوس بشكل صحيح ، لا يمكنني جعلها تعمل بدون المكون الإضافي. لذلك ربما لا يتم عرض رسالة الإيقاف ولكن ربما لا تزال المشكلة قائمة ...؟ هل يمكنك تقديم بعض النصائح حول كيفية التحقق من ذلك؟

@ RT-TL يتم استخدام المكون الإضافي فقط لمشاهدة محتوى الاستجابة دون حظر CORS. في حالتي ، لأغراض الاختبار ، كنت أعيد للتو سلسلة مثل Hello World لذا بمجرد تعطيل CORS رأيت شيئًا مثل

Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
Hello World

تأكد من تمكين تحذيرات PHP عن طريق إضافة error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE) أو error_reporting(E_ALL) إلى الجزء العلوي من طريقة وحدة التحكم الخاصة بك. إذا كنت لا تزال لا ترى أي شيء ، فسأحاول فقط إرجاع بعض ردود JSON البسيطة للتحقق من أنها تبدو كما هو متوقع.

هل لا يزال أي شخص يعاني من هذه المشكلة؟ أنا أواجه نفس الشيء:

const instance = axios.create({
    baseURL: 'http://localhost/',
    responseType: 'json',
    headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
        'Authorization': 'test',
        'X-Test': 'testing'
    }
})
axios.get('v2/portal/bar/foo?')

رؤوس الاستجابة

HTTP/1.1 401 Unauthorized
Server: nginx/1.11.10
Date: Fri, 24 Mar 2017 07:12:13 GMT
Content-Type: application/json; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, PUT, DELETE, GET, OPTIONS
Access-Control-Allow-Headers: *

طلب الرؤوس

OPTIONS /v2/portal/bar/foo? HTTP/1.1
Host: localhost
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Access-Control-Request-Headers: authorization,content-type,x-test
Accept: */*
Referer: http://localhost:3000/dashboard/report
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,fr;q=0.6,nl;q=0.4,zh-TW;q=0.2,zh;q=0.2,zh-CN;q=0.2

لا يمكنني معرفة سبب عدم إرسال أي من الرؤوس بشكل صحيح.

نفس المشكلة هنا ، تم إجراء طلب OPTIONS ، لكن طلب POST ليس كذلك.

TLDR: عمليات الجلب ، لا يتم استخدام axios ما لم أستخدم JSON.stingify

لقد رأيت أيضًا متغير هذا الخطأ حيث تقوم OPTIONS بإرجاع 200 مع تعيين الرؤوس لطلبات عبر الأصل ، ولكن لا يتم إجراء POST. أستخدم هذا الامتداد ويبدأ العمل كما هو متوقع. لكنني متأكد من وجود مشكلة ما هنا. ألق نظرة على طلبي:

يستجيب خادمي بـ Access-Control-Allow-Origin: *
إليك جميع الأمثلة مع التعليمات البرمجية ولقطات الشاشة:

أكسيوس:

axios.post('http://localhost:3001/card', { test: 'test' })

axios_cors


أحضر:

    return fetch('http://localhost:3001/card', {
      method: 'POST',
      body: { test: 'test' },
    })

fetch_no_stringify

بـ JSON.stringify

    return fetch('http://localhost:3001/card', {
      method: 'POST',
      body: JSON.stringify({ test: 'test' }),
    })

fetch_cors

لقد تمكنت من جعل محاور العمل تعمل بواسطة JSON.stringify -ing بياناتي مثل:

    return axios.post('http://localhost:3001/card', JSON.stringify({ test: 'test' }));

axios_json_stringify

كنت أواجه نفس المشكلة كما أوضح kwhitaker ، لم تكن axios ترسل ملف تعريف الارتباط الخاص بي بشكل صحيح مما أدى إلى استجابات بمعلومات أقل (أفترض بسبب مخاوف أمنية). من ناحية أخرى ، فإن طلب XHR العادي يعمل بشكل جيد. ثم كما اقترح zlyi ، أضفت للتو السطر axios.defaults.withCredentials = true; وبدأ كل شيء يعمل كما هو متوقع.

حاولت كل شيء وما زلت تواجه المشكلة. :(

حاولت كل شيء وما زلت تواجه المشكلة. :(

تمكنت من إدارة المشكلة عن طريق إضافة ما يلي إلى .htaccsess:

<IfModule mod_headers.c> 
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type" 
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS" 
</IfModule>

تمكنت من معالجة هذا باستخدام وكيل. أضف الوكيل إلى package.json

{
    "proxy": "http://some-url/some-endpoint"
}

ثم اطلب:

axios.get('/user?ID=12345')
  .then(function (response) {
    console.log(response)
  })
  .catch(function (error) {
    console.log(error)
  })

هذه مشكلة من جانب الخادم ، يجب أن يكون لديك 'Acces-Control-Allow-Origin': '*' في رأس الاستجابة. إذا كنت تستخدم Express ، فيمكنك استخدام npm-cors لتنفيذ أكثر قوة / أناقة.

+1ProfNandaa
لقد قمت بإنشاء تصدير في خادمي المحلي

# cors.js file
module.exports = (req, res, next) => {
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
  next();
}

لذلك ثم قمت بتعيين:
""
cors الثابتة = تتطلب ('cors') ؛
router.use (cors) ؛
""
الآن المضي قدما ... شكرا

سيحدث الخطأ عندما لا يقبل الخادم طلب OPTION.

بالنسبة لأولئك الذين يعلقون قائلين "إضافة معالجة طلب OPTION إلى الخادم الخاص بك" ، هذا لا يعمل. أنا أقوم بتشغيل بيئة محلية تم فيها تمكين معالجة طلب OPTION.

لقد واجهت هذه المشكلة تمامًا كمستخدم أعلاه ، حيث قام Axios.post(url, obj) بإرجاع خطأ CORS 403 المحظور ، ولكن تحديث ذلك إلى Axios.post(url, JSON.stringify(obj)) عمل بشكل صحيح.

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

لقد قمت ببساطة باستبدال jsonp بـ get وتمكنت من الوصول إلى البيانات.

كانت لدي هذه المشكلة وكان koa-cors حلاً بسيطًا! (npm-cors لمستخدمي Express وفقًا لـ ProfNandaa)

بالنسبة لأولئك الذين ما زالوا يواجهون مشاكل مع هذا: سيعمل Axios بشكل جيد مع CORs ، مع طلبات OPTIONS ، مع إرسال JSON كنص للطلب دون أن يكون JSON.encoded ، ومع ملفات تعريف الارتباط المرسلة والمستمرة بشكل صحيح ، طالما أن Axios و تم تكوين الخادم الذي يستجيب للطلبات بشكل صحيح.

لقد تطلب الأمر بعض التجربة والخطأ المحبطين ولكن لدينا طلبات عبر النطاقات تعمل بشكل جيد مع Axios.

بعض النقاط:

لطلب العمل ، تأكد

  • يستجيب الخادم لطلبات OPTIONS ، كما لو كانت الاستجابة هي أي شيء بخلاف 200 مع تعيين جميع الرؤوس الصحيحة ، ستفشل الطلبات "التي تم اختبارها مسبقًا" .

  • يتم إجراء الطلب باستخدام الرؤوس الصحيحة ، ويستجيب الخادم بكل الرؤوس اللازمة.

  • إذا كانت ملفات تعريف الارتباط / رؤوس التفويض أو شهادات عميل TLS مطلوبة ، فأرسل allowCredentials إلى true لطلب Axios. يمكن القيام بذلك كإعداد افتراضي ( axios.defaults.withCredentials = true ) أو لكل طلب.

مثال على رؤوس الطلبات الناجحة

Access-Control-Request-Headers: Content-Type
Access-Control-Request-Method: GET

مثال على رؤوس الاستجابة الناجحة

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
Access-Control-Allow-Origin: http://your-origin-url.com

أضفنا رؤوس الاستجابة تدريجيًا ووجدنا أن لدينا أخطاء متنوعة يصعب تشخيصها وسلوك غير متوقع بتركيبات مختلفة

بدون Access-Control-Allow-Credentials: true لم يتم إرسال ملفات تعريف الارتباط أو استمرارها ، وهو أمر منطقي بعد قراءة صفحة MDN لهذا العنوان

القراءة من خلال هذه الوثائق تساعد.

أي شخص لديه المشكلة ، ...Allow-Headers: Content-Type مهم.

Access-Control-Allow-Origin: '*'
Access-Control-Allow-Methods: ...
Access-Control-Allow-Headers: Content-Type, Accept

أنا أستخدم امتداد Chrome هذا المسمى "Allow-Control-Allow-Origin: *"
آمل أن يساعد في مشكلتك.
2017-07-19 14 06 37

لمن لا يفهم سبب عدم تمكن Axios من إصلاح هذا الخطأ:

هذه ليست مشكلة أكسيوس. إنها مشكلة في المتصفح. سيرفض JS في المتصفح الطلبات إلى الخوادم التي لم يتم تعيين الرؤوس المناسبة لها. إذا كنت تستخدم هذا مع شيء مثل React على العميل ، فلا داعي للارتباك ، فهذه ليست مشكلة React أو Axios ، إنها ببساطة المتصفح الذي يحترم معيار CORS.

يقدم JakeElder وصفًا جيدًا لما تحتاج إلى القيام به على جانب الخادم لواجهة برمجة التطبيقات الخاصة بك هنا: https://github.com/mzabriskie/axios/issues/191#issuecomment -311069164

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

لست متأكدا لماذا تم تنفيذ هذا. من المؤكد أنه أمر مزعج عندما تريد فقط تقديم طلب إلى خادم للحصول على بعض المعلومات ولكن لا يمكنك ذلك لأن الخادم لا يحتوي على مجموعة رؤوس محددة. تبدو مقيدة للغاية. اوه حسنا ...

@ robins-eldo مرة أخرى ، لا أعتقد أنك على صواب.

تعليقي الأصلي:

For those commenting saying "Add OPTION request handling to your server", that does not work. I'm running a local environment that has OPTION request handling enabled.

I experienced this issue identically as a user above, where Axios.post(url, obj) returned the CORS 403 forbidden error, but updating that to Axios.post(url, JSON.stringify(obj)) worked correctly.

إذا كانت في الواقع مشكلة في الخادم ، وليست مشكلة Axios ، فلن يكون لتقييد كائن أي تأثير ، لأن طلب OPTIONS كان سيفشل في كلتا الحالتين.

تضمين التغريدة

لست متأكدًا من طريقة OPTION HTTP ولكن مشكلتي المحددة كانت أن لدي عميل React يحاول الإرسال إلى واجهة برمجة تطبيقات داخلية كتبتها (واجهة برمجة التطبيقات الداخلية هي الخادم هنا). ظللت أتلقى هذا الخطأ: Failed to load resource: Origin http://localhost:7149 is not allowed by Access-Control-Allow-Origin. XMLHttpRequest cannot load http://localhost:8902/user-login due to access control checks.

اعتقدت أنها قد تكون مشكلة في Axios ، لذا جربت Unirest بدلاً من ذلك واستمررت في الحصول على نفس الخطأ. لذلك اعتقدت أنه يجب أن يكون شيئًا آخر. لست متأكدًا مما إذا كانت هذه مشكلة في المتصفح أو في رد فعل ، ولكن بمجرد أن أضفت ما يلي إلى خادم واجهة برمجة التطبيقات (وهو Nodejs + Express API) ، بدأ كل شيء في العمل مع كل من Axios و Unirest من جانب العميل:

app.use(function(req, res, next) { res.header("Access-Control-Allow-Origin", "*"); next(); });

ربما يكون فهمي لما يحدث بالفعل وراء الكواليس هنا محدودًا إلى حد ما ، ومع ذلك ، فإن هذا الجزء من الكود الموجود على الخادم قد حل المشكلة بالنسبة لي.

تأكد من أن الخادم الخاص بك لا يقيد الوصول إلى الأصل كثيرًا وإذا كنت ترغب في الالتفاف حول no-cors ، فجرّب ما يلي:

    return axios(url, {
      method: 'POST',
      mode: 'no-cors',
      headers: {
        Accept: 'application/json',
        'Content-Type': 'application/json',
      },
      withCredentials: true,
      credentials: 'same-origin',
    }).then(response => {
    })

أعتقد أن هناك بعض الناس هنا في حيرة من أمرهم حول كيفية عمل CORS. ومع ذلك ، فإن المشكلة الأصلية لم تكن تتعلق بـ CORS ، أو على الأقل ينبغي أن تكون هذه هي المشكلة المهمة. أعني ، عندما يكون لديك CORS مهيأ بشكل صحيح ولكن على الرغم من أن المنشور لا يعمل ، فهذه مشكلة يجب الإبلاغ عنها ، وليست كيفية تكوين الخادم بشكل صحيح

API يتصرف غريب. طلب GET بكافة كورس كان يعمل مع "بيانات الاعتماد: صحيح".
بالنسبة لطلبات POST ، يعمل طلب الأصل نفسه بدون تشديد كائن البيانات بينما يبدأ طلب CORS POST أيضًا في العمل عندما أقوم بتشديد كائن البيانات.

لم أحصل على السبب بالضبط ولكن المشكلة حلت بالنسبة لي.

أنا آسف ولكني أقفل سلسلة المحادثات هذه حيث يبدو أننا نقوم بعمل دوائر حول نفس الموضوع. إذا كانت لديك مشكلة معينة لم تتم تغطيتها في مشكلة أخرى (مشكلات CORS العامة بسبب التهيئة الخاطئة ، يتم إرسال طلبات POST بتنسيق JSON بدلاً من URL-urlencoded ، وما إلى ذلك) يرجى فتح مشكلة جديدة بتفاصيل محددة.

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