Jika saya memiliki pengguna yang masuk ke situs saya, setelah id-nya tersimpan $_SESSION, dan dari peramban dia mengklik tombol 'Simpan' yang akan membuat permintaan AJAX ke server. Akankah $_SESSIONcookie miliknya dan cookie dipertahankan dalam permintaan ini, dan dapatkah saya mengandalkan id yang ada di dalam $_SESSION?
Jawaban:
Jawabannya iya:
Sesi dikelola di sisi server. Sejauh menyangkut server, tidak ada perbedaan antara permintaan AJAX dan permintaan halaman biasa. Keduanya adalah permintaan HTTP, dan keduanya berisi informasi cookie di header dengan cara yang sama.
Dari sisi klien, cookie yang sama akan selalu dikirim ke server apakah itu permintaan reguler atau permintaan AJAX. Kode Javascript tidak perlu melakukan sesuatu yang istimewa atau bahkan untuk menyadari hal ini terjadi, itu hanya berfungsi sama seperti halnya dengan permintaan reguler.
Warning: session_write_close(): Failed to write session data (user)kesalahan dalam suatu proyek, tetapi hanya ketika permintaan AJAX terjadi selama pemuatan sisa halaman. Saya menggunakan DB MySQL untuk data sesi, dan mungkin permintaan halaman utama mengunci tabel itu, mencegah permintaan AJAX mengaksesnya.
Jika file PHP permintaan AJAX memiliki session_start()info sesi akan dipertahankan. (baring permintaan berada dalam domain yang sama)
Apa yang Anda maksudkan adalah: apakah cookie dikirimkan dengan permintaan AJAX? Dengan asumsi permintaan AJAX adalah untuk domain yang sama (atau dalam batasan domain cookie), jawabannya adalah ya. Jadi AJAX meminta kembali ke server yang sama tetap mempertahankan info sesi yang sama (dengan asumsi skrip yang dipanggil mengeluarkan session_start () sesuai skrip PHP lain yang menginginkan akses ke informasi sesi).
Ya, tidak selalu. Menggunakan cookie, Anda baik. Tetapi "bisakah saya mengandalkan id yang ada saat ini" mendesak saya untuk memperpanjang diskusi dengan poin penting (kebanyakan untuk referensi, karena jumlah pengunjung halaman ini tampaknya cukup tinggi).
PHP dapat dikonfigurasi untuk mempertahankan sesi dengan penulisan ulang URL, bukan cookie. ( Bagaimana ini baik atau buruk (<- lihat misalnya komentar paling atas di sana) adalah pertanyaan terpisah , sekarang mari kita berpegang pada pertanyaan saat ini, hanya dengan satu catatan: masalah yang paling menonjol dengan sesi berbasis URL - terang-terangan visibilitas ID sesi telanjang - bukan masalah dengan panggilan Ajax internal; tapi kemudian, jika dihidupkan untuk Ajax, itu dihidupkan untuk seluruh situs, juga, jadi di sana ...)
Dalam hal sesi penulisan ulang URL (tanpa masak), panggilan Ajax harus mengurusnya sendiri sehingga URL permintaan mereka dibuat dengan benar. (Atau Anda dapat menggulirkan solusi kustom Anda sendiri. Anda bahkan dapat menggunakan sesi pemeliharaan di sisi klien , dalam kasus yang kurang menuntut.) Intinya adalah perawatan eksplisit yang diperlukan untuk kelangsungan sesi, jika tidak menggunakan cookie:
Jika panggilan Ajax hanya mengekstrak URL kata demi kata dari HTML (seperti yang diterima dari PHP), itu tidak masalah, karena sudah dimasak (umm, dimasak).
Jika mereka perlu merakit sendiri URI permintaan, ID sesi perlu ditambahkan ke URL secara manual. (Periksa di sini , atau sumber halaman yang dihasilkan oleh PHP ( dengan penulisan ulang URL aktif ) untuk melihat bagaimana melakukannya.)
Dari OWASP.org :
Secara efektif, aplikasi web dapat menggunakan mekanisme, cookie atau parameter URL, atau bahkan beralih dari satu ke yang lain (penulisan ulang URL otomatis) jika kondisi tertentu terpenuhi (misalnya, keberadaan klien web tanpa dukungan cookie atau ketika cookie tidak diterima karena masalah privasi pengguna).
Dari posting Ruby-forum :
Saat menggunakan php dengan cookie, ID sesi akan secara otomatis dikirim dalam header permintaan bahkan untuk Ajax XMLHttpRequests. Jika Anda menggunakan atau mengizinkan sesi php berbasis URL, Anda harus menambahkan id sesi ke setiap url permintaan Ajax.
Sangat penting bahwa permintaan AJAX mempertahankan sesi. Contoh termudah adalah ketika Anda mencoba melakukan permintaan AJAX untuk panel admin, katakanlah. Tentu saja Anda akan melindungi halaman yang Anda ajukan permintaan, bukan untuk diakses oleh orang lain yang tidak memiliki sesi yang Anda dapatkan setelah login administrator. Masuk akal?
Satu hal yang harus diwaspadai, terutama jika Anda menggunakan kerangka kerja, adalah untuk memeriksa apakah aplikasi regenerasi id sesi antara permintaan - apa pun yang tergantung secara eksplisit pada id sesi akan mengalami masalah, meskipun jelas sisa data di sesi tidak akan terpengaruh.
Jika aplikasi membuat ulang id sesi seperti ini, maka Anda dapat berakhir dengan situasi di mana permintaan ajax berlaku membatalkan / mengganti id sesi di halaman yang meminta.
Itulah yang dilakukan kerangka kerja, misalnya jika Anda menginisialisasi sesi di Front Controller atau skrip boostrap, Anda tidak perlu peduli tentang inisialisasi itu baik untuk pengontrol halaman atau pengontrol ajax. Kerangka PHP bukan obat mujarab, tetapi mereka melakukan begitu banyak hal berguna seperti ini!
letakkan sesi Anda () auth di semua halaman sisi server menerima permintaan ajax:
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwiseitu tentang satu-satunya cara saya pernah melakukannya.
HttpOnlybendera ketika mengatur cookie yang berarti bahwa Javascript Anda tidak akan dapat melihat cookie. Namun cookie akan tetap dikirim untuk kedua AJAX dan permintaan halaman yang teratur dan terus bekerja persis sama. Javascript Anda tidak akan melihatnyadocument.cookie.