Werkzeug: دعم CORS

تم إنشاؤها على ٣ نوفمبر ٢٠١١  ·  16تعليقات  ·  مصدر: pallets/werkzeug

سيكون من الجيد دعم CORS [1] [2]

حتى الملفات الثابتة تحتاج إلى دعمها

[1] http://www.w3.org/TR/cors/
[2] http://enable-cors.org/

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

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

ال 16 كومينتر

يدعم Werkzeug بالفعل CORS حيث يمكنك تعيين رؤوس الردود التي تعيدها في تطبيق WSGI الخاص بك. لست متأكدًا مما يمكن أو يجب فعله أيضًا داخل Werkzeug "لدعم CORS" ، هل يمكنك توضيح ذلك؟

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

    if 'cors' in config and config['cors'] is True:
        response.headers.add('Access-Control-Allow-Origin', '*')
        response.headers.add('Access-Control-Allow-Methods',
                             'GET,PUT,POST,DELETE,PATCH')
        response.headers.add('Access-Control-Allow-Headers',
                             'Content-Type, Authorization')

... أنت تعرف شعار الثعبان: "البطاريات متضمنة" ... ؛)

لكن CORS هو أكثر من السماح بـ * ، خاصة عند استخدام ملفات تعريف الارتباط والأشياء. أنا شخصياً أستخدم 20 برمجية وسيطة LoC WSGI لإضافة رؤوس CORS والإجابة على طلب الاختبار المبدئي. إنها ليست بتلك الصعوبة.

posativ - هل

بشكل محدود للغاية:

from werkzeug.datastructures import Headers

class CORSMiddleware(object):
    """Add Cross-origin resource sharing headers to every request."""

    def __init__(self, app, origin):
        self.app = app
        self.origin = origin

    def __call__(self, environ, start_response):

        def add_cors_headers(status, headers, exc_info=None):
            headers = Headers(headers)
            headers.add("Access-Control-Allow-Origin", self.origin)
            headers.add("Access-Control-Allow-Headers", "Origin, ...")
            headers.add("Access-Control-Allow-Credentials", "true")
            headers.add("Access-Control-Allow-Methods", "GET, POST, PUT, etc")
            headers.add("Access-Control-Expose-Headers", "...")
            return start_response(status, headers.to_list(), exc_info)

        if environ.get("REQUEST_METHOD") == "OPTIONS":
            add_cors_headers("200 Ok", [("Content-Type", "text/plain")])
            return [b'200 Ok']

        return self.app(environ, add_cors_headers)

# usage
app = CORSMiddleware(make_app(...), "http://example.org/")

يمكنك توسيع هذه الفئة لتشمل رؤوس مخصصة ، وبيانات الاعتماد ، والبطاقات البدل.

posativ - شكرًا لك على هذا ، سأحاول ذلك في وقت مبكر من الأسبوع المقبل عندما

تحتاج إلى رفع هذا الأمر.

سؤال نسبي http://stackoverflow.com/questions/19382431/set-header-on-werkzeug-exception

السطر ذو الصلة: https://github.com/pallets/werkzeug/blob/master/werkzeug/debug/__init__.py#L297

يجعل start_response('500 INTERNAL SERVER ERROR', من الصعب إضافة رأس CORS مثل Access-Control-Allow-Origin: * . لكن الغريب لدينا بالفعل X-XSS-Protection: 0 هناك.

لقد قمت بتمكين Flask-CORS ، وكنت أقوم بتصحيح استدعاء ajax API عن بُعد في Chrome ، عندما يكون لدى Flask استثناء ، لا يمكنني رؤية محتوى التصحيح بسبب CORS. هل يمكننا إضافة هذا الرأس في نموذج التصحيح؟

لماذا تريد تعيين رأس CORS على مصحح الأخطاء؟ ولماذا لا يمكنك فعل ذلك باستخدام برنامج وسيط ملفوف؟

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

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

لماذا تريد تعيين رأس CORS على مصحح الأخطاء؟

نظرًا لأنه سيناريو صعب تم استدعاؤه بواسطة طلب AJAX عبر النطاقات ، يمكن فقط تصحيحه في Chrome DevTool بعد سلسلة من تشغيل حدث جافا سكريبت ، إذا لم يكن هناك رأس CORS ، فلن يعرض Chrome DevTool أي محتوى على الإطلاق. لا أستطيع رؤية أي شيء. يمكنني فقط التحديق في صفحة فارغة بها 500 خطأ في الخادم.

ولماذا لا يمكنك فعل ذلك باستخدام برنامج وسيط ملفوف؟

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

إليك "البرامج الوسيطة الملتفة" التي تشير إليها ، https://github.com/corydolphin/flask-cors/issues/67 يمكنك أن ترى أننا لا نستطيع فعل الكثير حيال ذلك ما لم يتم تعديل عناصر Werkzeug ذات المستوى الأدنى.

أفترض أن untitaker لم

qq20160420-3

lambdaq الآن أنت تعني untitaker

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

ربما أفتقد مشكلتك بالضبط ، نظرًا لاختلاف المنظور / الفهم ، يرجى تحديد حالة الاستخدام الدقيقة التي تبدو مكسورة / مستحيلة

أصبح الموقف صعبًا بعض الشيء لأن البرنامج الوسيط لمصحح الأخطاء يتم تطبيقه عند استدعاء app.run. لا يزال بإمكانك حل هذه المشكلة عن طريق تطبيق كل من CORS والبرمجيات الوسيطة الخاصة بمصحح الأخطاء يدويًا. يعد هذا أمرًا جيدًا بالنسبة إلى IMO لمثل هذه الحالة ، ولكن إذا كانت لديك مقترحات محددة لتغيير البرامج الوسيطة لمصحح الأخطاء بطريقة لا تعرض الأمان للخطر ، فيرجى اقتراحها. لا أعرف أي تغييرات سهلة بالرغم من ذلك.

كما أنني أدرك جيدًا الرمز الموجود في Werkzeug. أعتقد أن هذا هو السبب في أنني أحافظ عليه؟

آسف ، أعتذر عن لغتي ، Werkzeug مشروع رائع.

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

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

رمز untitaker JS لا يمكنه فعل أي شيء ، إذا كان هناك خطأ 500 ، يمكنك فقط معرفة رمز حالة http الخاص به هو 500 ، والتتبع من صفحة مصحح الأخطاء هو ما أسعى إليه.

كما أن كود js عبارة عن تفاعلات مجمعة مشعرة مع الكثير من الأشياء ، تم تطويرها بواسطة فريق آخر ، يستغرق الأمر 300 ثانية + إلى npm run dev . ليس من السهل تعديل أو إضافة بعض خطوط التصحيح.

أعتقد أن # 1699 يحل هذا. في حين أن Werkzeug يمكن أن يفعل أكثر مما هو عليه في # 1699 ، أعتقد أنه يجب فقط توفير طرق وصول (مثل التحكم في ذاكرة التخزين المؤقت) والسماح للأدوات المبنية عليه (مثل Flask-CORS أو Quart-CORS) بتنفيذ منطق CORS.

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