Werkzeug: dukungan CORS

Werkzeug sudah mendukung CORS di mana Anda dapat mengatur header pada respons yang Anda kembalikan di aplikasi WSGI Anda. Saya tidak yakin apa lagi yang dapat atau harus dilakukan dalam Werkzeug untuk "mendukung CORS", dapatkah Anda menguraikannya?

Saya bukan OP, tetapi karena CORS adalah injeksi header boilerplate, mungkin ide yang baik untuk menjadikannya sebagai pengaturan/parameter. Sesuatu di sepanjang baris cuplikan ini , meskipun di sini-terutama tidak ada OPSI, jadi preflight akan bermasalah...

    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')

...Anda tahu mantra python: "termasuk baterai"... ;)

Tetapi CORS lebih dari sekadar mengizinkan * , terutama ketika Anda menggunakan cookie dan sejenisnya. Secara pribadi, saya menggunakan middleware 20 LoC WSGI untuk menambahkan header CORS dan menjawab permintaan preflight. Tidak sesulit itu.

@posativ -

Dalam bentuk yang sangat terbatas:

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/")

Anda dapat memperluas kelas ini untuk menyertakan header kustom, kredensial, wild-card.

@posativ - Terima kasih untuk ini, saya akan mencobanya awal minggu depan ketika saya akan melanjutkan pekerjaan pada proyek itu. :)

Perlu membenturkan ini.

Pertanyaan relatif http://stackoverflow.com/questions/19382431/set-header-on-werkzeug-exception

Baris terkait: https://github.com/pallets/werkzeug/blob/master/werkzeug/debug/__init__.py#L297

start_response('500 INTERNAL SERVER ERROR', mempersulit untuk menambahkan tajuk CORS seperti Access-Control-Allow-Origin: * . Tapi anehnya kita sudah punya X-XSS-Protection: 0 disana.

Saya telah mengaktifkan Flask-CORS, telah men-debug panggilan API ajax jarak jauh yang rumit di Chrome, ketika Flask memiliki pengecualian, saya tidak dapat melihat konten debug karena CORS. Bisakah kita menambahkan header ini dalam model debug?

Mengapa Anda ingin mengatur tajuk CORS pada debugger? Dan mengapa Anda tidak bisa melakukannya dengan pembungkus middleware?

Saya juga ingin menutup ini karena menurut saya kita tidak perlu menambahkan setiap middleware ke werkzeug.

@unititaker

Mengapa Anda ingin mengatur tajuk CORS pada debugger?

Karena ini adalah skenario rumit yang dipanggil oleh permintaan AJAX lintas-domain, di hanya dapat men-debug-nya di Chrome DevTool setelah serangkaian pemicu peristiwa javascript, jika tidak ada header CORS, Chrome DevTool tidak menampilkan konten apa pun sama sekali. Saya tidak bisa melihat apa-apa. Saya hanya bisa menatap halaman kosong dengan 500 server error.

Dan mengapa Anda tidak bisa melakukannya dengan pembungkus middleware?

karena middleware yang dibungkus hanya berfungsi dengan halaman NORMAL (aplikasi Flask yang dikembalikan dengan benar), tetapi tidak berfungsi sama sekali ketika debugger pengecualian Werkzeug terjadi.

Inilah "wrapping middleware" yang Anda maksud, https://github.com/corydolphin/flask-cors/issues/67 Anda dapat melihat kami tidak dapat berbuat banyak kecuali hal-hal Werkzeug tingkat yang lebih rendah di-tweak.

Saya kira @untitaker tidak melihat kode sumber yang saya

@lambdaq sekarang kamu jahat ke @untitaker

middleware apa pun yang membungkus aplikasi yang dibungkus debug dapat mengubah perilaku start_response - bahkan untuk debugger - sehingga kode yang Anda tempel dan tautkan tampaknya sama sekali tidak relevan,
karena kors middle-ware yang membungkus hanya bisa mengubahnya

mungkin saya melewatkan masalah Anda yang sebenarnya, karena perspektif/pemahaman yang berbeda, harap jelaskan kasus penggunaan yang tepat yang tampaknya rusak/tidak mungkin

Situasi menjadi sedikit rumit karena middleware debugger diterapkan saat memanggil app.run. Anda masih dapat mengatasinya dengan menerapkan CORS dan middleware debugger secara manual. IMO ini bagus untuk edgecase seperti itu, tetapi jika Anda memiliki proposal konkret untuk mengubah middleware debugger dengan cara yang tidak membahayakan keamanan, harap sarankan mereka. Saya tidak tahu ada perubahan mudah.

Saya juga sangat mengetahui kode di Werkzeug. Saya kira itu sebabnya saya mempertahankannya?

maaf, saya minta maaf untuk bahasa saya, Werkzeug adalah proyek yang luar biasa.

Saya kira saya hanya perlu mengedit baris start_response() dan menambahkan bruteforce header CORS untuk lingkungan dev saya, ini lebih nyaman daripada middleware berbulu.

Anda juga dapat mempertimbangkan untuk menambahkan kode JS tambahan yang mengalihkan ke debugger jika respons 500 kembali.

@untitaker Kode JS tidak dapat melakukan apa-apa, jika ada kesalahan 500, Anda hanya dapat memberi tahu kode status http-nya adalah 500, traceback dari halaman debugger adalah yang saya cari.

juga kode js adalah reactjs yang dikompilasi berbulu dengan banyak hal, dikembangkan oleh tim lain, dibutuhkan 300-an+ hingga npm run dev . Tidak mudah untuk mengubah atau menambahkan beberapa baris debug.

Saya pikir #1699 menyelesaikan ini. Sementara Werkzeug dapat melakukan lebih dari yang ada di #1699, saya pikir itu seharusnya hanya menyediakan metode pengakses (seperti untuk kontrol cache) dan mengizinkan alat yang dibangun di atasnya (misalnya Flask-CORS atau Quart-CORS) untuk melakukan logika CORS.