javascript - not - http error 405




الرد على طلب الاختبار المبدئي لا يجتاز فحص التحكم في الوصول (14)

أتلقى هذا الخطأ باستخدام ngResource للاتصال بـ REST API على Amazon Web Services:

يتعذر على XMLHttpRequest تحميل http://server.apiurl.com:8000/s/login?login=facebook . الرد على طلب الاختبار المبدئي لا يجتاز فحص التحكم في الوصول: لا يوجد رأس "وصول - تحكم - السماح - أصل" موجود على المورد المطلوب. الأصل " http: // localhost " غير مسموح له بالوصول. خطأ 405

الخدمات:

socialMarkt.factory('loginService', ['$resource', function($resource){    
    var apiAddress = "http://server.apiurl.com:8000/s/login/";
    return $resource(apiAddress, { login:"facebook", access_token: "@access_token" ,facebook_id: "@facebook_id" }, {
                getUser: {method:'POST'}
            });
}]);

مراقب:

[...]
loginService.getUser(JSON.stringify(fbObj)),
                function(data){
                    console.log(data);
                },
                function(result) {
                    console.error('Error', result.status);
                }
[...]

أنا أستخدم Chrome ، ولا أعرف ماذا أفعل لإصلاح هذه المشكلة. لقد قمت حتى بتكوين الخادم لقبول رؤوس من localhost الأصل.


JavaScript XMLHttpRequest و Fetch يتبعان نفس السياسة الأصلية. لذلك ، يمكن لتطبيق ويب يستخدم XMLHttpRequest أو Fetch فقط تقديم طلبات HTTP إلى المجال الخاص به.

المصدر: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

يجب عليك إرسال Access-Control-Allow-Origin: * رأس HTTP من جانب الخادم الخاص بك.

إذا كنت تستخدم Apache كخادم HTTP الخاص بك ، فيمكنك إضافته إلى ملف تكوين Apache كما يلي:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
</IfModule>

يتم تمكين Mod_headers افتراضيًا في Apache ، ومع ذلك ، قد ترغب في التأكد من تمكينه عن طريق تشغيل:

 a2enmod headers

إذا كنت تكتب تمديد الكروم

عليك أن تضيف في manifest.json أذونات المجال الخاص بك.

"permissions": [
   "http://example.com/*",
   "https://example.com/*"
]

أعتقد أن تعطيل CORS من Chrome ليس طريقة جيدة ، لأنه إذا كنت تستخدمه في أيوني ، فمن المؤكد أنه في تطبيق Mobile Build ، ستثار المشكلة مرة أخرى.

لذلك أفضل لإصلاح في الخلفية الخاصة بك.

بادئ ذي بدء ، في الرأس ، تحتاج إلى ضبط

  • header ('Access-Control-Allow-Origin: *')؛
  • header ('Header set Access-Control-Allow-Headers: "Origin، X-Requested-With، Content-Type، Accept"')؛

وإذا كانت API تتصرف كـ GET و POST على حد سواء ، فقم أيضًا بتعيينها في عنوانك

if ($ _SERVER ['REQUEST_METHOD'] == 'OPTIONS') {if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_METHOD']))) header ("Access-Control-Allow-Methods: GET، POST، OPTIONS")؛
if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) رأس ("الوصول - التحكم - السماح - الرؤوس:
{$ _SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']} ") ؛ والخروج (0) ؛}


أنا أستخدم AWS sdk للتحميلات ، بعد قضاء بعض الوقت في البحث على الإنترنت ، عثرت على هذا الموضوع. بفضلSimoneau 45581857 اتضح أن نفس الشيء كان يحدث بالضبط. لقد أشرت ببساطة إلى طلبي Url للمنطقة على دلو لي من خلال إرفاق خيار المنطقة وعملت.

<web-app>
  <filter>
      <filter-name>cross-origin</filter-name>
      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
  </filter>
  <filter-mapping>
      <filter-name>cross-origin</filter-name>
      <url-pattern>/*</url-pattern>
  </filter-mapping>
</web-app>

إذا كنت تستخدم خادم IIS عن طريق الصدفة. يمكنك تعيين الرؤوس أدناه في خيار رؤوس طلب HTTP.

Access-Control-Allow-Origin:*
Access-Control-Allow-Methods: 'HEAD, GET, POST, PUT, PATCH, DELETE'
Access-Control-Allow-Headers: 'Origin, Content-Type, X-Auth-Token';

مع هذا كل وظيفة ، والحصول على الخ ، سوف تعمل بشكل جيد.


بالنسبة لأولئك الذين يستخدمون Lambda Integrated Proxy مع واجهة برمجة تطبيقات API . تحتاج إلى تكوين وظيفة lambda الخاصة بك كما لو كنت تقوم بتقديم طلباتك إليها مباشرةً ، مما يعني أن الوظيفة يجب أن تقوم بإعداد رؤوس الاستجابة بشكل صحيح. (إذا كنت تستخدم وظائف lambda المخصصة ، فستتم معالجتها بواسطة بوابة API).

//In your lambda's index.handler():
exports.handler = (event, context, callback) => {
     //on success:
     callback(null, {
           statusCode: 200,
           headers: {
                "Access-Control-Allow-Origin" : "*"
           }
     }
}

تتضمن التوزيعات المستقلة لـ GeoServer خادم تطبيق Jetty. تمكين مشاركة المصادر المشتركة (CORS) للسماح لتطبيقات JavaScript خارج نطاقك باستخدام GeoServer.

uncomment التالية <filter> و <filter-mapping> من webapps / geoserver / WEB-INF / web.xml:

 const s3 = new AWS.S3({
 accessKeyId: config.awsAccessKeyID,
 secretAccessKey: config.awsSecretAccessKey,
 region: 'eu-west-2'  // add region here });

تعطيل chrome security. إنشاء اختصار chrome بالنقر بزر الماوس الأيمن -> الخصائص -> الهدف ، لصق هذا "C: \ Program Files (x86) \ Google \ Chrome \ Application \ chrome.exe" - disable-web-security --user داتا-دير = "ج: / chromedev"


في AspNetCore web api ، تم إصلاح هذه المشكلة عن طريق إضافة "Microsoft.AspNetCore.Cors" (ver 1.1.1) وإضافة التغييرات أدناه على Startup.cs.

public void ConfigureServices(IServiceCollection services)
{ 
    services.AddCors(options =>
    {
          options.AddPolicy("AllowAllHeaders",
                builder =>
            {
                    builder.AllowAnyOrigin()
                           .AllowAnyHeader()
                           .AllowAnyMethod();
                });
    });
    .
    .
    .
}

و

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{


    // Shows UseCors with named policy.
    app.UseCors("AllowAllHeaders");
    .
    .
    .
}

ووضع [EnableCors("AllowAllHeaders")] على وحدة التحكم.


في PHP ، يمكنك إضافة الرؤوس:

<?php
header ("Access-Control-Allow-Origin: *");
header ("Access-Control-Expose-Headers: Content-Length, X-JSON");
header ("Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS");
header ("Access-Control-Allow-Headers: *");
...

قد يكون السبب الشائع لهذا الخطأ هو أن واجهة برمجة تطبيقات المضيف قد عيّنت الطلب إلى طريقة http (مثل PUT) وأن عميل API يتصل بـ API باستخدام طريقة http مختلفة (مثل POST أو GET)


لإصلاح مشكلات الطلبات المشتركة في تطبيق Node JS:

npm i cors

وما app.js سوى إضافة الأسطر أدناه إلى app.js

let cors = require('cors')
app.use(cors())

هناك بعض المحاذير عندما يتعلق الأمر بـ CORS. أولاً ، لا يسمح باستخدام أحرف البدل * لكن لا تمسكني بهذا السؤال الذي قرأته في مكان ما ولا يمكنني العثور على المقالة الآن.

إذا كنت تقدم طلبات من مجال مختلف ، فأنت بحاجة إلى إضافة رؤوس السماح الأصلية. Access-Control-Allow-Origin: www.other.com

إذا كنت تقدم طلبات تؤثر على موارد الخادم مثل POST / PUT / PATCH ، وإذا كان نوع mime مختلفًا عن application/x-www-form-urlencoded التالي application/x-www-form-urlencoded أو multipart/form-data أو text/plain ، فسيتم تلقائيًا قدم طلبًا لخيارات ما قبل الرحلة للتحقق من الخادم إذا كان سيسمح بذلك.

لذلك ، يحتاج خادمك / خادمك إلى معالجة طلبات OPTIONS هذه وفقًا لذلك ، تحتاج إلى الاستجابة access control headers المناسبة ويجب أن يكون كود حالة استجابة http هو 200 .

يجب أن تكون الرؤوس شيئًا كهذا ، قم بضبطها حسب احتياجاتك: Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type Access-Control-Max-Age: 86400 رأس الحد الأقصى للعمر مهم ، في حالتي ، لن يعمل بدونه ، وأعتقد أن المتصفح يحتاج إلى معلومات عن مدة صلاحية "حقوق الوصول".

بالإضافة إلى ذلك ، إذا كنت تقدم على سبيل المثال طلب POST مع application/json mime من مجال مختلف ، فستحتاج أيضًا إلى إضافة رأس مصدر السماح المذكور سابقًا ، لذلك سيبدو كما يلي:

Access-Control-Allow-Origin: www.other.com Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type Access-Control-Max-Age: 86400

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

بشكل عام ، يجب تقديم استجابة لرؤوس Access-Control مهما كانت مطلوبة في الطلب الأولي أو قبل الرحلة ، حتى تعمل.

يوجد مثال جيد في مستندات MDN هنا على هذا الرابط ، ويجب عليك أيضًا الاطلاع على منشور SO هذا


يرى فريقنا هذا من حين لآخر باستخدام Vue ، axios و C # WebApi. إضافة سمة مسار في نقطة النهاية التي تحاول الوصول إليها تعمل على إصلاحها لنا.

[Route("ControllerName/Endpoint")]
[HttpOptions, HttpPost]
public IHttpActionResult Endpoint() { }




http-status-code-405