Mengirim cookie browser selama pengalihan 302

88

Apakah ada masalah dengan pengiriman kembali cookie selama 302 redirect? Misalnya, jika saya membuat kuki return-to-url dan mengalihkan pengguna dalam tanggapan yang sama, apakah peramban (modern) mana pun akan mengabaikan kuki?

http cookies http-status-code-302

— Abdullah Jibaly
sumber

Sedikit membaca, saya berpikir bahwa variabel sesi akan lebih baik daripada cookie karena mereka berada di sisi server dan tidak bergantung pada prediktabilitas klien.

— ADTC

41

Sebagian besar browser menerima cookie pada 302 pengalihan. Saya cukup yakin akan hal itu, tetapi saya melakukan sedikit pencarian. Tidak semua browser modern . Tautan arsip internet dari Q / A yang sekarang dihapus / mati / microsoft connect pada Tumpukan HTTP Klien Silverlight mengabaikan Set-Cookie pada 302 Redirect Responses (2010)

Saya pikir kami sekarang memiliki pengganti IE6 dan itu adalah browser Windows Mobile ...

— regilero
sumber

1

Halaman forum yang Anda tentukan tidak dapat diakses dengan URL. Apakah maksud Anda browser IE6 dan Windows Mobile tidak?

— hiroshi

1

tautan telah dipindahkan. Saya, telah menetapkan link baru dengan konten yang sama. dan maksud saya versi khusus IE untuk seluler menambahkan kumpulan bug mereka sendiri

— regilero

53

Menurut posting blog ini: http://blog.dubbelboer.com/2012/11/25/302-cookie.html semua browser utama, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) baik di Windows dan Mac, mengatur cookie pada pengalihan. Ini berlaku untuk pengalihan 301 dan 302.

Seperti yang dicatat @Benni:

https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies

Atribut SameSite dari sebuah cookie menentukan apakah cookie tersebut harus dibatasi untuk konteks pihak pertama atau situs yang sama. Beberapa nilai SameSite diperbolehkan:

Cookie dengan "SameSite=Strict"hanya akan dikirim dengan permintaan situs yang sama.

Cookie dengan "SameSite=Lax"akan dikirim dengan permintaan situs yang sama, atau navigasi tingkat atas lintas situs dengan metode HTTP "aman".

Cookie dengan "SameSite=None"akan dikirim dengan permintaan situs yang sama dan lintas situs.

— gavenkoa.dll
sumber

Sayangnya daftar ini tidak menyertakan Chrome, jadi kami tidak bisa mengatakan dengan tepat semua browser utama ...

— MestreLion

3

@MestreLion: di browser Chrome saya, ini berfungsi. Jadi .. Saya pikir kita dapat mengatakan bahwa ini akhirnya berhasil sekarang, pada tahun 2019.

— Michael

1

Itu tergantung pada kebijakan situs web: Dengan ketat masih tidak berfungsi.

— Benni

42

Satu pemberitahuan (untuk menyelamatkan hidup pengembang):

IE dan Edge mengabaikan Set-Cookie dalam respons pengalihan ketika domain cookie adalah localhost .

Larutan:

Gunakan 127.0.0.1 sebagai ganti localhost .

— Michal Maťovčík
sumber

12

IE dan Edge mungkin telah "memperbaiki" ini sehingga mereka juga tidak akan menyetel cookie untuk 127.0.0.1. Doh! Dan mereka bertanya-tanya mengapa pengembang tidak semua menyukai IE ... Jawaban Anda masih berakhir sekitar 4 jam menggaruk kepala bagi saya. Terima kasih!

— GlenPeterson

19

Berikut adalah bug Chromium untuk masalah ini (Set-cookie diabaikan untuk tanggapan HTTP dengan status 302).

— llambda
sumber

1

Jika ini benar, itu benar-benar berita buruk :-(

— MestreLion

Saya pikir mereka memperbaikinya. Laporan bug masih mengatakan "WontFix", tetapi di browser Chrome saya berfungsi.

— Michael

@Michael perhatikan bahwa Chromium bukan Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - itu berarti bahwa meskipun dapat berfungsi di Chrome, itu belum tentu berlaku untuk Chromium

— Thomas

4

Ini benar-benar pendekatan yang tidak disukai, tetapi jika Anda benar-benar ingin tidak mengandalkan perilaku browser set-cookie 30x, Anda dapat menggunakan meta http-equiv="refresh""pengalihan" HTML saat menyetel cookie. Misalnya, di PHP:

<?php
    ...
    setcookie("cookie", "value", ...);
    url="page.php";
?>
<html>
<head><meta http-equiv="refresh" content=1;url="<?=$url?>"></head>
<body><a href="<?=$url?>">Continue...</a></body>
</html>

Server akan mengirim Set-Cookie dengan 200 bukannya 300x redirect yang tepat, jadi browser akan menyimpan cookie, dan kemudian melakukan "redirect". The <a>link adalah fallback dalam kasus browser tidak melakukan penyegaran meta.

— MestreLion
sumber

3

Saya baru saja mengalami masalah ini dengan Firefox dan Safari, tetapi tidak dengan Chrome. Dari pengujian saya, ini hanya terjadi ketika domain berubah selama pengalihan. Ini tipikal dalam aliran OAuth2:

Penyedia id OAuth2 (GitHub, Twitter, Google) mengalihkan browser kembali ke aplikasi Anda
URL panggilan balik aplikasi Anda memverifikasi otorisasi dan menyetel cookie masuk, lalu mengalihkan lagi ke URL tujuan
URL tujuan Anda dimuat tanpa ada set cookie.

Untuk alasan yang belum saya ketahui, beberapa cookie dari permintaan 2 diabaikan sementara yang lainnya tidak. Namun, jika permintaan 2 mengembalikan HTTP 200 dengan Refreshtajuk (pengalihan "meta refresh"), cookie disetel dengan benar oleh permintaan 3.

— Kiran Jonnalagadda
sumber

1

Saya menduga bahwa alasan untuk masalah panggilan balik ini adalah samesite=strict. Untuk permintaan panggilan balik, browser masih menganggap pembuatnya adalah google (atau penyedia oauth mana pun yang Anda gunakan). Oleh karena itu, jika Anda menyetel samesite = strict cookie dalam respons 302 Anda, maka browser mungkin berpikir "ah ha! Ini adalah permintaan lintas situs yang datang dari Google ke situs Anda" dan karenanya tidak mengirimkan cookie saat meminta url yang diarahkan ulang. Perbaikannya adalah dengan menggunakan meta-refresh seperti yang Anda lakukan, jadi permintaan Anda berasal dari situs Anda sendiri. Saya bisa saja berbicara omong kosong, tapi itulah pemikiran saya saat ini.

— Ilan

2

Mengalami masalah ini saat menggunakan OpenIdConnect / IdentityServer di .Net, di mana API terpisah (nama host berbeda) menangani otentikasi dan pengalihan kembali ke situs utama.

Pertama (untuk pengembangan di localhost) Anda perlu mengatur CookieSecureopsi ke SameAsRequestatau Neveruntuk menangani http://localhost/tidak aman. Lihat jawaban Michael Freidgeim .

Kedua, Anda perlu menyetel CookieSameSiteatribut ke Lax, jika tidak, cookie tidak akan disimpan sama sekali. Stricttidak bekerja disini!

— Willem
sumber

-1

Dalam kasus saya, saya menetapkan CookieOptions.Secure = true, tetapi mengujinya di http: // localhost ., Dan browser menyembunyikan cookie sesuai dengan pengaturan.

Untuk menghindari masalah seperti itu, Anda dapat membuat opsi Cookie Secure agar sesuai dengan protokol Request.IsHttps, mis

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }

— Michael Freidgeim
sumber

2

Dalam hal ini jangan setel tanda aman . Inti dari flag ini adalah untuk memberi tahu browser untuk hanya menggunakan cookie saat menghubungkan melalui HTTPS. Menyetel bendera secara bersyarat akan mengubah semantik, dan Anda kehilangan cookie yang bertransisi dari HTTPS -> HTTP, tetapi tidak saat beralih dari HTTP -> HTTPS. Semua ini ortogonal dengan apa yang browser lakukan dengan Set-Cookieheader pada 302 pengalihan.

— Martijn Pieters

1

Saat itu ketika jawaban dengan -3 suara menyelesaikan masalah. Saya mengatur Secure = true, tetapi lupa bahwa di localhost saya hanya menggunakan http untuk mengujinya. Kesalahan noob. Gunakan secure=request.is_securedalam labu.

— Eloff