Anda mungkin pernah melihat situs seperti Google menyetel cookie status login di berbagai domain mereka (YouTube, Blogger). Seperti yang Anda ketahui, cookie tidak dapat disetel di domain yang berbeda dari domain lain secara langsung
Jika Anda memiliki beberapa situs tempat Anda perlu menyetel cookie dari situs induk, Anda dapat menggunakan HTML dasar dan JS untuk menyetel cookie. Google menggunakan cara yang sama
Domain
Untuk tutorial ini, kami akan merujuk ke tiga domain
www.example.com www.mysite.com www.india.comKami akan menyetel cookie di situs saya. com dan india. com dari contoh. com
Domain Lainnya
Anda harus membuat halaman dinamis bernama "setCookie. php" di server tempat Anda akan membuat cookie. Jika itu PHP, tambahkan kode berikut untuk mengatur cookie
<? setcookie("MyCookie", "subinsb.com", time()+3600); ?>_Dalam kasus di atas kami tidak menyebutkan jalur atau domain karena PHP secara otomatis mengaturnya
Domain Utama
Di domain utama (contoh. com) di mana Anda akan meminta dua domain lainnya untuk menyetel cookie, buat halaman HTML dengan konten berikut
<!DOCTYPE html> <html> <head> <script> function loadComplete(){ alert("Completed Setting Cookies"); } </script> </head> <body onload="loadComplete()"> <p> Please Wait... </p> <img src="//www.mysite.com/setCookie.php" style="display:none;" /> <img src="//www.india.com/setCookie.php" style="display:none;" /> </body> </html>Saat klien mengunjungi halaman di atas, sebuah halaman diminta dari situs saya. com domain sebagai sumber gambar, tetapi halaman tersebut bukan gambar. Halaman yang ada di domain lain ini akan mengatur cookie di domain itu
Kami juga menambahkan pendengar acara pada dokumen, sehingga kami akan mengetahui kapan cookie disetel sepenuhnya. Ini sama dengan pendengar yang memuat dokumen karena saat gambar dimuat, cookie disetel
Hal-hal lain
Anda juga dapat mengirimkan data ke domain lain sebagai parameter GET sehingga cookie berdasarkan data tersebut dapat dibuat. Namun, saat Anda mengirim kata sandi atau konten aman lainnya, pastikan untuk mengenkripsi string
Gambar harus disembunyikan karena, karena ini bukan gambar yang valid, ikon gambar jelek akan muncul di browser
Anda dapat mengubah konten callback event listener loadComplete() untuk melakukan hal lain sesuai pilihan Anda, seperti mengalihkan kembali ke domain utama
Bagaimana Google Melakukannya
Jika Anda memiliki akun di Blogger dan YouTube yang berada di domain eksternal, saat Anda masuk melalui akun. google. com Anda dialihkan ke halaman yang mengatakan "Please Wait…", kan?
Saluran, cookie, dan otorisasi
Gambar ukuran penuh
Sertifikat saluran adalah X yang ditandatangani sendiri. 509 sertifikat kunci publik [,]. Ini berisi deskripsi saluran yang dapat dibaca manusia, nama saluran (bersama dengan pengidentifikasi algoritma hash yang digunakan untuk menghitungnya), dan flag aman. Itu ditandatangani dengan kunci pribadi pemilik. Sertifikat saluran bersifat opsional dalam otorisasi. Jika tidak disertakan, pihak yang mengandalkan (mis. g. , browser) harus dapat memperolehnya dengan cara lain. Skema kami menyediakan mekanisme penemuan untuk melakukannya
Sertifikat otorisasi juga ditandatangani dengan kunci pribadi pemilik. Ini diimplementasikan sebagai sertifikat atribut Internet yang didefinisikan dalam RFC 3281 []. Nama subjek otorisasi ditempatkan di bidang Pemegang sertifikat. Otorisasi memberikan pemegangnya izin untuk membaca atau menulis (i. e. , membuat, memodifikasi, dan menghapus) cookie XDC. Selain nama pemegang dan izin, sertifikat otorisasi mengkodekan nama saluran XDC dan deskripsi singkat saluran yang dapat dibaca manusia atau penggunaan saluran oleh pemegang. Untuk saluran aman juga berisi ID sertifikat SSL pemegang (nama penerbit/pasangan nomor seri []). Seperti sertifikat atribut apa pun, sertifikat otorisasi memiliki masa berlaku yang harus diperiksa setiap kali cookie XDC terkait digunakan
Sertifikat atribut Internet mendukung model pemeriksaan pencabutan berdasarkan daftar pencabutan sertifikat (CRL) atau pada Protokol Status Sertifikat Online (OCSP). Namun, untuk menyederhanakan pemrosesan dan meminimalkan biaya tambahan, kami memilih untuk tidak menggunakan pemeriksaan pencabutan dalam solusi kami
3. 4 Cookie lintas domain
Cookie lintas domain (atau XDC) pada dasarnya memiliki struktur yang sama dengan cookie HTTP yang saat ini digunakan. Mereka masih membawa pasangan nama/nilai dan atribut manajemen tambahan (lihat Tabel ). Alih-alih atribut Domain, Path, dan Port, kami memperkenalkan atribut Nama XDC; . Cookie XDC tidak mengizinkan akses ke skrip, jadi atribut HttpOnly juga tidak diperlukan. Terakhir, atribut Secure digantikan oleh flag secure (lebih tangguh) di sertifikat saluran XDC
4 Protokol
4. 1 Pertukaran data
Saat browser membuat permintaan yang diprakarsai pengguna ke server Web, mungkin ada beberapa cookie XDC untuk dikirim ke server yang tunduk pada otorisasi XDC server. Browser mungkin memiliki beberapa, semua, atau tidak ada otorisasi yang diberikan ke server (atau domain DNS induknya). Proposal kami menyediakan tiga mekanisme untuk menemukan semua otorisasi yang berlaku
Kirim permintaan preflight ke server
Kirim permintaan pengguna, izinkan server untuk memberikan otorisasi yang hilang, lalu kirim ulang permintaan lagi
Lakukan pencarian DNS
Kami mengeluarkan permintaan preflight untuk semua permintaan pengguna yang menggunakan metode HTTP POST dan PUT. Tidak melakukannya dapat mengakibatkan server mengaktifkan mekanisme penemuan kedua yang, pada gilirannya, dapat menyebabkan pengiriman ulang sejumlah besar data dalam permintaan. Informasi preflight yang diterima dari server di-cache (untuk durasi yang ditunjukkan oleh server), jadi tidak semua permintaan pengguna memerlukan otorisasi preflight; . Informasi prapenerbangan dapat mencakup sertifikat saluran XDC dan otorisasi XDC serta waktu aktif untuk informasi dan opsi tambahan. Satu-satunya opsi yang saat ini ditentukan adalah tanda yang menunjukkan apakah browser harus menggunakan DNS untuk mencari otorisasi tambahan untuk server (atau domain DNS induknya) dan, jika demikian, seberapa sering
Saat server menerima permintaan pengguna sebenarnya, ia mungkin menemukan bahwa beberapa cookie XDC yang diharapkannya belum disertakan oleh browser. ethernet browser tidak memiliki cookie sama sekali, atau memiliki cookie tetapi tidak memiliki otorisasi untuk server. Untuk memperhitungkan kasus terakhir, server dapat merespons dengan otorisasi yang hilang, dan meminta browser untuk mengulangi permintaan tersebut, sekarang dengan cookie yang hilang (mungkin, dicakup oleh otorisasi yang baru ditemukan)
Browser yang menerima cookie XDC dari server dapat menggunakan semua otorisasi yang sebelumnya di-cache atau otorisasi yang dikirimkan server dengan cookie itu sendiri. Karena server selalu dapat menggabungkan cookie dan otorisasi dalam satu respons, tidak diperlukan perjalanan bolak-balik tambahan untuk menyelesaikan penemuan
Sumber terakhir otorisasi XDC untuk situs Web adalah DNS. Untuk mendukung pengiriman out-of-band, kami mengusulkan untuk menempatkan otorisasi XDC di catatan sumber daya TXT (RR) di DNS [], yang disandikan untuk menghormati aturan DNS. Karena catatan sumber daya TXT dapat digunakan oleh banyak aplikasi, terdapat risiko bahwa catatan yang diterima oleh browser bukan merupakan otorisasi XDC. Dalam implementasi kami, klien hanya membuang RR jika tidak dapat menafsirkannya dengan benar;
Pencarian DNS dilakukan saat mengirim saat browser menemukan cookie XDC yang belum terselesaikan di "jar" cookie, dan saat menerima saat server mengirim cookie XDC yang tidak dapat diselesaikan dengan cara lain (cache atau otorisasi XDC in-band). DNS tidak dikonsultasikan kecuali server menunjukkannya sebagai tanggapannya terhadap permintaan preflight
4. 2 permintaan sebelum penerbangan
Permintaan preflight adalah permintaan HTTP; . Permintaan preflight dikeluarkan untuk URL yang sama dengan permintaan pengguna asli. Server yang sesuai dapat mengembalikan nol atau lebih Xdc-Info-Request to true. A preflight request is issued for the same URL as the original user request. A compliant server may return zero or more Xdc-Channel dan Xdc-Authorization headers. It may also include the Xdc-Max-Age yang menunjukkan waktu retensi maksimum informasi yang diberikan dalam respons. (Jika tidak ada yang diberikan, default protokol akan digunakan. ) Terakhir, header Xdc-Options dapat menyertakan instruksi pemrosesan XDC tambahan; . Contoh permintaan preflight ditunjukkan pada Gambar. dns-max-age option is defined; if set, it instructs the browser to look up missing XDC authorizations in the DNS and defines the maximum frequency of such lookups. A sample preflight request is shown in Figure .
Gambar 2
Permintaan pra-penerbangan. >> menandai tajuk yang dikirim ke server, > menandai tajuk yang dikirim ke server,