java - Soalan tentang pengesahan log masuk tunggal JD

Question

Gambar di atas ialah permintaan http semasa proses pengesahan satu titik JD.com.

Prosesnya adalah seperti berikut: Maksudnya, halaman utama semasa ialah www.jd.com, dan kemudian ia memulakan pengesahan ke sso.jd.hk dengan memulakan permintaan merentas domain. Permintaan ini membawa kuki dan kuki juga dikembalikan dalam respons. Domina kuki yang dikembalikan dalam respons ditetapkan kepada nama domain peringkat pertama.

Saya ada beberapa soalan,

(1) Ini ialah permintaan merentas domain Mengapakah permintaan itu membawa kuki? Boleh tak ni? Saya nampak kawan-kawan lain cakap biskut boleh dibawa

Sebagai contoh, http://blog.csdn.net/wzl002/a... Sama ada hendak memasukkan tetapan kuki dalam permintaan Ajax merentas domain

Tetapi khususnya mengenai JD.com, bagaimana dia mengendalikannya?

(2) Kuki ditetapkan dalam respons, tetapi nama domain semasa bukan jd.hk, tetapi www.jd.com Bolehkah ini ditetapkan secara khusus?
(3) p3p ditetapkan dalam jawapan Adakah masalah yang dinyatakan dalam soalan 2 dicapai melalui ini?

(4) p3p boleh rujuk http://blog.csdn.net/ghj1976/...

Artikel tersebut menyebut:

Selepas menggunakan P3P, anda boleh menetapkan penyemak imbas untuk mengesan secara automatik sama ada tapak web: mengumpul maklumat yang boleh dikenal pasti secara peribadi, menggunakan maklumat ini untuk membuat profil pengguna atau membenarkan pelawat menolak pengumpulan data.

Pelayar berkemampuan P3P mempunyai beberapa pilihan lalai yang boleh anda pilih. Atau anda boleh menyesuaikan tetapan anda dengan menjawab soalan seperti data yang anda sanggup kongsikan dan jenis kuki yang anda sanggup terima. Semasa anda menyemak imbas Web, perisian ini menentukan sama ada keutamaan privasi anda sepadan dengan amalan pengumpulan data tapak web.

Pemahaman saya ialah: Penyemak imbas dengan fungsi p3p boleh mengesan penulisan kuki merentas domain dan bertanya kepada pengguna dengan berinteraksi dengan pengguna sama ada dia bersetuju untuk menulis kuki merentas domain? Sama seperti laman web yang sering berlaku mengubah interaksi segera? ? ? ? Pemahaman ini nampaknya tidak munasabah,

Sila sebut beberapa perkataan (

＾-＾

)

Answer 1

1. Fahami perbezaan antara nama domain dan hos. Contohnya, www.jd.com ialah nama hos, bukan nama domain, dan jd.com ialah nama domain. Dalam gambar di bawah, jika hostOnly ditandakan, kuki ini hanya akan berfungsi pada hos ini Menukar nama hos www1.jd.com tidak akan berfungsi. Tetapi jika hostOnly tidak ditandakan, kuki ini sah pada mana-mana hos di bawah nama domain ini Walaupun kuki ini dibuat di www.jd.com, ia masih boleh dibaca di www1.jd.com Kuki ini, iaitu. , apabila penyemak imbas melawati www1.jd.com, kuki ini akan dihantar ke pelayan sebagai sebahagian daripada permintaan.

1. Ajax merentas domain berbeza daripada ini. Ajax mengelirukan perbezaan antara nama domain dan hos. Dari perspektif Ajax, selagi permintaan tidak dimulakan pada hos yang sama, ia dianggap merentas domain. Contohnya, jika anda memulakan permintaan ajax daripada www.jd.com untuk mengakses kandungan di www1.jd.com, ini juga dianggap merentas domain. Tegasnya, ini hanya dikira sebagai hos silang, bukan domain silang Walau bagaimanapun, atas sebab sejarah, ia sentiasa ditakrifkan dengan cara ini, jadi tiada cara untuk membetulkannya.

Answer 2

Cadangan saya ialah mereka bentuk sendiri kaedah pengesahan token dan jawapan permintaan http hanyalah cara untuk lulus token. Jika anda menyimpan token ini dalam redis/memcached, semua nod boleh menanyakan status semasa (sama ada ia telah disahkan) melalui token, atau menulis perkhidmatan bebas untuk memberikan pengesahan atas sebab yang sama. sso.jd.hk menggunakan kuki untuk menyimpan maklumat seperti token pengesahan dan cap masa.

Token tidak perlu dirahsiakan, hanya balas dengan token terus. Mod ini juga sesuai untuk pengesahan soket web.

Kaedah pengiraan yang biasa digunakan:token = sha1(数据ID+过期时间戳+验证密码)

Hantar token, ID data dan cap masa tamat tempoh kepada pelanggan, dan lampirkan tiga maklumat ini apabila menghantar permintaan kepada perkhidmatan lain, kerana hanya pelayan yang mengetahui kata laluan pengesahan, jadi anda boleh mengesahkan sama ada permintaan itu datang daripada perkhidmatan lain. Kaedah pengesahan sumber AWS adalah serupa dengan ini, kecuali kata laluan pengesahan digantikan dengan kunci API anda.