Dva: sampel otentikasi oauth2

Bukankah verifikasi oauth2 dilakukan dengan pengalihan url? Tidak apa-apa jika Anda masuk dengan menilai cookie.

Beberapa OAuht2 dilakukan melalui access_token, bukan url, format RESTFul murni

Akan lebih baik jika ada contoh integrasi dva dan Spring Boot Oauth2: D

@soulmachine Saya menggunakan ini, dan saya akan menyelesaikannya

@WhatAKitty melewati access_token, di mana access_token disimpan? Disimpan di local/seesionStorage akan memiliki risiko keamanan XSS.

@u0x01 disimpan di penyimpanan lokal. Faktanya, tidak ada banyak risiko. Access_token memiliki batas waktu. Anda tidak dapat masuk lagi setelah waktu habis, dan tidak ada izin refresh_token. Selain itu, tidak ada cara lain.Informasi terkait lainnya ditanyakan, dan semuanya disimpan di penyimpanan lokal.

@WhatAKitty Sekarang peretas menggunakan atau menulis alat otomatis untuk menyerang. Masa berlaku akses_token dua jam sudah cukup untuk melakukan banyak hal. Bagaimana Anda sampai pada kesimpulan bahwa "tidak terlalu banyak risiko"?
Kedua, refresh_token tidak ditempatkan di penyimpanan lokal, di mana Anda meletakkannya?
Access_token lebih cocok untuk APP. Sisi JS murni tidak boleh menggunakan skema access_token. Masih ada risiko serangan lintas situs.
Solusi paling aman sekarang adalah menambahkan http-only ke set-cookie.
Saat mengecek login, bawa cookie ke server untuk menarik status seesion, jika gagal akan langsung melompat ke halaman login.
Keselamatan juga produktivitas, yang lebih penting daripada Taishan, jadi Anda tidak boleh bermalas-malasan di sini.

@u0x01 refresh_token, saya tidak akan memberikannya kepada klien js. Oleh karena itu, harus disertifikasi ulang setelah habis masa berlakunya. Saya mungkin belum menjelaskan sebelumnya, karena aplikasi kami seperti ini: access_token hanyalah kunci yang memungkinkan Anda untuk mengakses. Jika Anda ingin mengakses sumber daya tertentu, Anda harus melalui otentikasi pengguna. Proses ini diamankan oleh SSL, jadi Anda tidak akan muncul.Kata berbagai risiko.
Adapun solusi teraman yang Anda katakan, saya juga mempertimbangkan untuk menggunakan cookie, tetapi satu: Saya tidak membuat server kompatibel dengan OAUTH2 dan LOGIN PASSWORD secara bersamaan, karena saya tidak dapat mengembalikan access_token setelah masuk dengan PASSWORD LOGIN. , Mungkin ada cara lain, tetapi saya tidak menemukannya. Kedua: Karena persyaratan waktu proyek, opsi ini hanya dapat dipilih sebagai kompromi. Oleh karena itu, rencana ini tampaknya sedikit tidak tepat, tetapi sebenarnya tidak akan ada masalah keamanan.

@WhatAKitty belum pernah mendengar tentang SSL "dapat melindungi situs web dari serangan XSS/CSRF", tidak ada hubungan langsung antara keduanya.
Jika Anda dapat menjamin bahwa sistem situs web Anda 100% bebas dari kerentanan XSS/CSRF, maka Anda dapat menyimpannya di Penyimpanan lokal dan membiarkan JS mengakses kredensial secara langsung. (Tapi saya belum pernah melihat perusahaan yang berani memilih bahwa sistemnya tidak memiliki celah keamanan)

Dan saya tidak mengerti apa artinya mengakses sumber daya tertentu, yang harus diautentikasi oleh pengguna. Dalam spesifikasi OAuth2, memperoleh access_token berarti bahwa pengguna (atau Penyedia) telah menyetujui otorisasi ini.

Selain itu Anda menyebutkan:
因为没法在使用 LOGIN PASSWORD 登录后给我返回一个access_token
Ini adalah kesalahpahaman tentang spesifikasi OAUth2 dan penggunaan yang salah.

Metode LOGIN PASSWORD pada dasarnya adalah proses di mana UA secara langsung meminta autentikasi dari Penyedia OAUth2, lihat RFC6749 . Saat ini, kode_otorisasi harus diperoleh. Setelah UA mendapatkan kode_otorisasi, kode tersebut akan dikirim ke Klien untuk memverifikasi validitas Penyedia OAUth2. Jika verifikasi lolos, Klien akan mendapatkan access_token dari Penyedia OAUth2. Saat ini, Klien dapat menggunakan access_token untuk mengakses sumber daya. Klien kemudian mengeluarkan SessionID ke UA.
(Klien di sini merujuk ke server atau APP pihak bisnis, bukan pengguna akhir, pengguna akhir adalah Pemilik Sumber Daya, dan UA adalah browser)

Secara keseluruhan, SessionID harus digunakan untuk mengautentikasi pengguna, bahkan jika SessionID tidak digunakan, access_token harus ditempatkan di cookie http saja:

1. Don't use local storage for session identifiers. Stick with cookies and use the HTTPOnly and Secure flags.
2. If cookies won't work for some reason, then use session storage which will be cleared when the user closes the browser window.
3. Be cautious with storing sensitive data in local storage. Just like any other client side storage options this data can be viewed and modified by the user. 

Jika Anda benar-benar ingin mengekspos access_token ke klien, metode komprominya adalah:

// GET /seesion
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" {
        ctx.JSON(200, {"signed": true, "access_token": access_token})
    } else {
        ctx.Redirect("//yoursite.com/login")
    }

Tetapi saya tetap menyarankan untuk hanya memasukkannya ke dalam cookie. JS menggunakan metode GET /seesion untuk menentukan apakah Anda telah masuk. Sumber daya lain diakses seperti biasa. Server akan langsung melompat ke halaman login setelah mengetahui bahwa access_token telah kedaluwarsa :

// GET /seesion
    access_token := ctx.Session().GetString("access_token")
    if signed != "" {
        ctx.JSON(200, {"signed": true})
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

// GET /posts/:postid
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" && isValidAccessToken(access_token) {
        ctx.JSON(200, getPostWithAccessToken(access_token, postid))
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

Tentu saja, jika menurut Anda sistem situs web Anda tidak memiliki nilai serangan, saya belum mengatakan apa pun.

Jenis "tampaknya tidak pantas, tetapi sebenarnya tidak akan ada masalah keamanan." berpikir, saya tidak tahu berapa banyak kerugian yang akan ditimbulkan oleh majikan Anda di masa depan:
Inventarisasi kebocoran keamanan informasi perusahaan
Satu juta informasi pelanggan dijajakan secara real time (masalah kebocoran keamanan informasi perusahaan ini belum sepenuhnya teratasi sampai sekarang, dilarang oleh sejumlah perusahaan e-commerce besar seperti klub produk)

Keamanan informasi memiliki jalan panjang.

@u0x01
Biarkan saya berbicara tentang apa yang saya jawab sebelumnya. Mungkin tidak jelas. Dalam proses memperoleh access_token, tidak hanya client_id dan client_secret (ini mungkin tidak diperlukan), tetapi juga nama pengguna dan kata sandi diperlukan.

Dapat melindungi situs web dari serangan XSS/CSRF

Ada CSRF telah dinonaktifkan. Adapun XSS, semua konten yang disimpan dalam database akan secara otomatis ditransfer dan bidang ilegal akan disaring. Meskipun mungkin ada kelalaian, tidak mungkin untuk menghilangkannya sepenuhnya. Keamanan informasi tidak sepenuhnya aman. Hal yang sama berlaku untuk Microsoft dan Apple Saya tidak percaya Anda Sistem dapat mencapai keamanan 100%.

Bahkan jika Anda tidak menggunakan SessionID, Anda harus meletakkan access_token di cookie http saja

Hanya Http juga tidak sepenuhnya aman.

Ini adalah kesalahpahaman tentang spesifikasi OAUth2 dan penggunaan yang salah.

Saya tidak tahu apakah ini dianggap sebagai penggunaan yang salah, tetapi apakah mungkin aplikasi saya sendiri meminta halaman otorisasi. Setelah pengguna masuk, dia mendapatkan halaman otorisasi dan kemudian setuju untuk mengaksesnya? Apakah itu terlalu banyak masalah? Untuk saat ini, tidak ada situs web yang melakukan ini untuk aplikasinya sendiri, bukan?

Selain itu, metode otentikasi ideal saya mungkin berbeda dari apa yang Anda katakan, karena server saya sendiri menyediakan layanan otentikasi OAuth2. Jadi saya pikir untuk klien browser saya, seperti ini: UA meminta AS, AS menemukan bahwa itu tidak diautentikasi, melompat ke LOGIN, dan kemudian setelah pengguna masuk, ia berhasil mendapatkan izin untuk mengakses server (ini mungkin menjadi access_token, atau mungkin) Anda dapat langsung membuka izin akses layanan sumber daya), dan kemudian pengguna dapat secara langsung/tidak langsung (access_token) meminta sumber daya di server sumber daya di sisi js.

Dengan kata lain, metode autentikasi ideal saya adalah untuk UA kita sendiri. Saya pikir jika itu adalah pihak ketiga, mungkin perlu menggunakan otorisasi_kode yang Anda sebutkan untuk mendapatkan halaman otorisasi yang dapat diakses pengguna.

Di atas adalah metode otentikasi ideal saya, tetapi sayangnya level saya terbatas dan saya tidak bisa mendapatkan efek yang saya inginkan melalui OAuth2 Spring.

Saya tidak tahu berapa banyak kerusakan yang akan terjadi pada majikan Anda di masa depan

Pertama-tama, saya ingin menunjukkan bahwa proyek kami sangat mendesak, dan arsitekturnya baru-baru ini menyusul.Jika mungkin, apakah saya tidak dapat berjuang untuk keunggulan? Namun, waktu tidak memungkinkan, bos Anda mengizinkan Anda untuk menyeret proyek klien sambil bermain keamanan teknis? Kenyataannya seringkali kejam. Bos Anda mungkin sama sekali tidak peduli dengan keselamatan pelanggan Anda. Mereka lebih mementingkan kepentingan. Satu-satunya hal yang bisa saya lakukan adalah memastikan keamanan sebanyak mungkin.

@u0x01 Bahkan, untuk saya sendiri, saya juga ingin membuat arsitektur yang saya rancang tanpa masalah keamanan, tetapi kenyataannya adalah:

1. Saya tidak dapat memenuhi persyaratan ini dengan tingkat teknis pribadi saya. Saya sendiri bukan ahli teknis.
2. Kurangnya ahli teknis yang nyata untuk membimbing saya, jika seseorang bersedia membimbing saya, saya pikir saya akan senang

Selama ini semua teknologi saya telah dieksplorasi oleh satu orang tanpa bimbingan, beberapa solusi yang kurang memang menjadi kekurangan saya.

@WhatAKitty
Karena proyek Anda sedang terburu-buru dan bos tidak peduli, lakukan saja sesuai dengan ide Anda sekarang.

Tetapi apakah mungkin aplikasi Anda sendiri meminta halaman otorisasi Setelah pengguna login, dapatkan halaman otorisasi lalu setuju untuk mengaksesnya? Apakah itu terlalu banyak masalah? Untuk saat ini, tidak ada situs web yang melakukan ini untuk aplikasinya sendiri, bukan?

Silakan merujuk ke spesifikasi OAuth2 yang relevan, OAuth2 memiliki konsep izin implisit.

Dengan kata lain, metode autentikasi ideal saya adalah untuk UA kita sendiri. Saya pikir jika itu adalah pihak ketiga, mungkin perlu menggunakan otorisasi_kode yang Anda sebutkan untuk mendapatkan halaman otorisasi yang dapat diakses pengguna.

OAuth2 tampaknya tidak memiliki konsep pihak ketiga.

Selain itu, apa yang Anda lakukan dengan perlindungan CSRF dinonaktifkan ... Bukankah itu menggali lubang untuk diri Anda sendiri?
Saya tidak mengatakan bahwa http saja yang benar-benar aman Masalah keamanan utama yang hanya dipecahkan oleh http adalah mencegah js membaca cookie. Bekerja sama dengan SSL dapat mencegah pihak ketiga memantau cookie (dalam kasus serangan non-man-in-the-middle).

@WhatAKitty
Saya dulu berdiri dari sudut pandang bos, tetapi sebenarnya, ada beberapa masalah keamanan yang baik. Di satu sisi, atasan Anda akan memperhatikan masalah keamanan, dan di sisi lain, Anda akan meninggalkan makanan untuk insinyur keamanan informasi.

Insinyur keamanan informasi harus berterima kasih kepada programmer yang sengaja meninggalkan bug :)

@u0x01 Sepertinya Anda mengenal OAuth2 dengan baik? Apakah mungkin membuat grup? Saya tidak menemukan banyak informasi aplikasi di area ini, dan saya tidak punya banyak waktu untuk mengumpulkannya. Saya dapat mengajukan beberapa pertanyaan kepada Anda.

@u0x01 Backend adalah stateless dan tidak ada sesi sama sekali. Anda perlu menggunakan token untuk redis untuk menentukan apakah sudah kedaluwarsa.Bolehkah saya bertanya di mana token itu aman?

@longzb stateless sesi tidak ada, Anda menyebutkan

Gunakan token untuk redis untuk menentukan apakah sudah kedaluwarsa

Faktanya, access_token digunakan sebagai sesi. Disarankan untuk mempelajari definisi dan cara kerja session.

Di mana tokennya aman?

Menempatkannya di cookie http_only dapat mencegah JS mendapatkan cookie secara langsung, sehingga mengurangi nilai dan kemungkinan serangan XSS/CSRF.

@u0x01 Hmm. Saya pergi ke Baidu kemarin. Saya akan menaruh kue, lebih baik lebih aman.

Artikel ini bagus tentang analisis implisit.
Hari ini saya menyelesaikan sampel SSM+ANTD. Setelah membaca artikel ini, saya merasa bahwa cara teraman adalah menggunakan server implisit untuk meminta server otentikasi dan mendapatkan token, dan secara implisit meminta server implisit untuk mendapatkan sumber daya dari server sumber daya.

Karena seperti yang dikatakan artikel ini, otorisasi implisit berisiko, seperti phishing, mudah bagi peretas untuk berpura-pura menjadi klien yang aman untuk meminta sumber daya.

Tetapi untuk melakukan ini, dva perlu mendukung rendering sisi server. Sekarang antd mendukungnya, apakah dva sudah mendukungnya? @maafcc

Anda tidak mengkhawatirkan hal yang benar

Melindungi informasi yang terletak di klien?

Anda tidak perlu melakukan apa pun setelah informasi mencapai klien Anda (mis.: browser Anda) untuk melindunginya. Anda dapat menyimpan token akses di cookie, di bidang tersembunyi di halaman web Anda, di cache lokal html5 atau terlihat jelas langsung di tengah halaman dan tidak mengubah apa pun (kecuali selancar bahu...).

Khawatir tentang token akses setelah ada di klien seperti membuka notepad untuk menulis kata sandi email Anda dan kemudian khawatir bahwa penyerang mungkin dapat mencuri informasi itu dari lokasi yang jauh. Itu tidak terjadi. Kecuali komputer Anda sudah disusupi tetapi pada titik ini Anda sudah kalah.

Di mana masuk akal untuk khawatir?

Biasanya, informasi Anda rentan saat sedang transit. Dalam kasus OAuth2 (aliran implisit), token akses akan transit di dua tempat:

dari server otorisasi ke browser Anda
dari browser Anda ke server sumber daya
Melindungi informasi saat sedang transit semudah menggunakan TLS di mana-mana. Yang seharusnya sudah Anda lakukan karena Anda menggunakan OAuth2 dan itu diwajibkan oleh protokol.

Sekarang masalah sebenarnya

Cara Anda ingin menggunakan OAuth2 kemungkinan besar bukan cara yang seharusnya Anda gunakan.

Untuk memahami mengapa Anda mungkin akan menyalahgunakan OAuth2, Anda harus tahu tentang alurnya. OAuth2 mendefinisikan 4 alur otorisasi

Kode Otorisasi (hanya satu yang bagus tapi... teruslah membaca)
Implisit (rasa aman palsu)
Kredensial Kata Sandi Pemilik Sumber Daya (ide yang mengerikan)
Kredensial Klien (tidak berlaku untuk kasus Anda)
Karena Anda menggunakan klien javascript, satu-satunya aliran yang bekerja untuk Anda adalah aliran implisit dan sekarang memulai masalah.

Masalah aliran implisit

Ada banyak tapi mari kita bicara tentang yang paling kritis. Token akses tidak terikat ke klien tertentu! Dari bagian spesifikasi 10.16:

Untuk klien publik yang menggunakan alur implisit, spesifikasi ini tidak menyediakan metode apa pun bagi klien untuk menentukan klien apa yang diberikan token akses.
Ini membuka pintu bagi penyerang untuk menyamar sebagai Anda, pemilik sumber daya, dan kemudian mendapatkan akses ke server sumber daya.Mari terus membaca bagian 10.16:

Pemilik sumber daya dapat dengan sukarela mendelegasikan akses ke sumber daya dengan memberikan token akses ke klien jahat penyerang. Ini mungkin karena phishing atau alasan lain. Penyerang juga dapat mencuri token melalui mekanisme lain. Penyerang kemudian dapat mencoba untuk menyamar sebagai pemilik sumber daya dengan memberikan token akses ke klien publik yang sah.

Dalam aliran implisit (response_type=token), penyerang dapat dengan mudah mengganti token dalam respons dari server otorisasi, mengganti token akses nyata dengan yang sebelumnya dikeluarkan untuk penyerang.

Server yang berkomunikasi dengan aplikasi asli yang mengandalkan token akses yang diteruskan di saluran belakang untuk mengidentifikasi pengguna klien mungkin juga disusupi oleh penyerang yang membuat aplikasi yang disusupi yang dapat menyuntikkan token akses yang dicuri secara sewenang-wenang.

Setiap klien publik yang berasumsi bahwa hanya pemilik sumber daya yang dapat menyajikannya dengan token akses yang valid karena sumber daya rentan terhadap jenis serangan ini.
Serangan pertama itu sebenarnya bukan serangan melainkan hanya "cacat" dalam aliran implisit ...

Serangan berikutnya

Sekarang mulailah masalah besar. Anda tampaknya mencoba menggunakan aliran implisit OAuth2 sebagai bentuk autentikasi pengguna akhir yang didelegasikan yang tidak dimaksudkan untuk diberikan. Kembali ke bagian spesifikasi 10.16

Mengautentikasi pemilik sumber daya kepada klien berada di luar cakupan spesifikasi ini. Setiap spesifikasi yang menggunakan proses otorisasi sebagai bentuk autentikasi pengguna akhir yang didelegasikan kepada klien (misalnya, layanan masuk pihak ketiga) TIDAK HARUS menggunakan alur implisit tanpa mekanisme keamanan tambahan yang akan memungkinkan klien untuk menentukan apakah token akses dikeluarkan untuk penggunaannya (misalnya, token akses yang membatasi audiens).
Pada titik ini sebagian besar permainan berakhir untuk Anda.

Bagaimana cara memasang serangan itu?

Ini cukup sederhana. Katakanlah layanan REST Anda memerlukan token akses dari facebook. Yang perlu dilakukan penyerang hanyalah meng-host layanan, misalnya stackoverflow, dan memerlukan token akses dari facebook. Saat Anda memberikan token akses facebook ke stackoverflow, stackoverflow (penyerang kami) sekarang dapat menyamar sebagai Anda dengan layanan REST Anda.

Semua itu karena token akses tidak terikat pada klien tertentu.

Sebuah solusi

Jangan gunakan alur implisit dan alih-alih gunakan alur kode otorisasi. Artinya, aplikasi sisi klien 100% Anda tidak perlu lagi menjadi aplikasi sisi klien 100%.

Mengapa Anda tidak menggunakan server yang melayani klien angularjs kepada pengguna Anda untuk menangani aliran OAuth2?

Referensi: http://tools.ietf.org/html/rfc6749

@WhatAKitty Jika pengidentifikasi tertentu dari setiap browser pengguna adalah unik, pengguna akan secara otomatis membawa pengidentifikasi ini saat mengirim permintaan, dan itu tidak dapat diubah. Backend dapat mengikat token ke pengidentifikasi ini saat mengajukan token untuk pertama kalinya. Setelah permintaan berikutnya tidak sesuai dengan ID browser yang disimpan dalam token, permintaan tersebut akan dianggap sebagai permintaan ilegal. .
Jadi saya ingin bertanya, apakah ada logo seperti itu ketika browser memintanya? ?

@longzb umumnya menggunakan JSESSIONID, atau dapat dikustomisasi, misalnya oschina menggunakan id sendiri

@WhatAKitty @soulmachine @longzb

Ketika mode Sandi dan Klien OAuth2.0 digunakan secara bersamaan, proxy entri dapat ditambahkan ke server back-end untuk menyimpan access_token, dan proxy ini juga dapat digunakan sebagai CORS front-end (Boot Musim Semi Oauth2 tampaknya mencegat preflight CORS)

Mode kata sandi front-end hanya perlu mengirimkan nama pengguna dan kata sandi ke agen. Agen memperoleh otorisasi dan menyimpan access_token. Kemudian SESSION_ID yang dihasilkan oleh agen dikembalikan ke front-end, dan agen perlu mengelola kedaluwarsa dan penyegaran access_token. Satu-satunya hal yang terekspos ke front-end adalah Remember- Me dll. hanya berbeda di kepala Set-Cookie: Expires=

Mode Klien hanya klien tidak perlu mengakses proxy, cukup langsung ke antarmuka OAuth untuk mendapatkan otorisasi

Adapun balasan @u0x01 , saya mengatakan banyak informasi yang membingungkan dan tidak berguna

Sebenarnya dapat diringkas sebagai berikut:

1. Melempar access_token langsung ke front end alih-alih Sesi adalah karena perlu berbagi antarmuka dengan mode Klien. Antarmuka semacam ini sering tidak mendukung verifikasi Sesi, atau tidak nyaman untuk mengelola Sesi pada sistem terdistribusi.

2. Keamanan terhadap serangan XSS dan CSRF harus dianalisis secara terpisah

   2.1 Untuk mencegah CSRF, front-end menempatkan access_token di header HTTP untuk dikirim, dan back-end hanya mendukung verifikasi header. Pada saat yang sama, cukup untuk mendesain antarmuka dengan baik. Karena situs web pihak ketiga tidak dapat mengirim header HTTP tambahan hanya melalui formulir, dan JS situs web pihak ketiga tidak dapat mengirim data ke situs webnya sendiri (bila CORS diatur dengan benar)

   2.2 Untuk mencegah XSS, access_token penyimpanan front-end memang tidak aman dan dapat dibaca oleh JS sesuka hati dan dikirim ke seluruh domain; dan cookie dengan set HttpOnly adalah sumber Kredensial. Peramban modern memiliki batasan lintas domain yang sangat terbatas pada Kredensial. Hampir tidak ada cara untuk mendapatkannya. Tetapi dalam analisis terakhir, bukankah mencegah XSS berarti mencegah injeksi skrip + menghindari mengutip skrip eksternal yang tidak tepercaya?HttpOnly ini hanya bisa dikatakan sebagai obat

3. Ukuran paling aman adalah bertindak sebagai proxy ingress di back end, dan menyetel Access-Control-Allow-Origin CORS untuk mengizinkan hanya nama domain front-end. Setelah pengguna berhasil login, Sesi HttpOnly dikembalikan, dan kode acak seperti X-CSRF-TOKEN ditambahkan ke bidang header. Kode acak ini ada dengan access_token yang diperoleh dari antarmuka OAuth . Front-end menggunakan Ajax atau mengambil untuk mengirim data dengan Cookie dan header ini.Setelah back-end memverifikasi validitas Cookie, perlu memverifikasi validitas header X-CSRF .Ini pada dasarnya dapat mencegah CSRF dan XSS biasa mencuri izin

Singkatnya, manajemen front-end access_token tidak dapat dianggap tidak aman

Pembaruan 1:

Middleware atau backend menggunakan jwt untuk mengenkripsi access_token, dan pada saat yang sama, membentuk deteksi injeksi dan CSP untuk mencegah XSS

@mdluo punya ide yang jelas, puji 👍

@mdluo Maaf, saya seorang pemula di front end. Dalam metode ketiga yang Anda sebutkan, pada dasarnya saya dapat mencapai bagian back-end dengan Spring boot + spring security, tetapi bagaimana cara membawa cookie ke pengambilan front-end? Karena melibatkan lintas domain, beberapa solusi di Internet menggunakan parameter credentials: "include" menyelesaikannya, tetapi parameter ini hanya dapat menyelesaikan permintaan GET. POST dan masalah lainnya memiliki masalah. Karena baru pertama kali pakai, mungkin bodoh menulisnya sendiri. lingkungan adalah:
Ujung depan: port DVA 8000
Backend: Boot pegas + Keamanan pegas, X-CSRF-TOKEN dan Cookie

@yoster0520 Konfigurasi CORS di backend. Jika frontend memiliki banyak alamat, backend harus secara dinamis menentukan dan mengembalikan satu-satunya Access-Control-Allow-Origin sesuai dengan daftar putih, sehingga dapat membawa cookie