Saya ingin mengurangi waktu muat di situs web saya dengan memindahkan semua cookie ke penyimpanan lokal karena tampaknya memiliki fungsi yang sama. Apakah ada pro / kontra (terutama dari segi kinerja) dalam menggunakan penyimpanan lokal untuk menggantikan fungsionalitas cookie kecuali untuk masalah kompatibilitas yang jelas?

Cookie dan penyimpanan lokal memiliki tujuan berbeda. Cookie terutama untuk membaca sisi server , penyimpanan lokal hanya dapat dibaca oleh sisi klien . Jadi pertanyaannya adalah, di aplikasi Anda, siapa yang butuh data ini - klien atau server?

Jika itu adalah klien Anda (JavaScript Anda), maka tentu saja beralihlah. Anda membuang-buang bandwidth dengan mengirimkan semua data di setiap tajuk HTTP.

Jika itu adalah server Anda, penyimpanan lokal tidak begitu berguna karena Anda harus meneruskan data itu entah bagaimana (dengan Ajax atau bidang formulir tersembunyi atau sesuatu). Ini mungkin baik-baik saja jika server hanya membutuhkan sebagian kecil dari total data untuk setiap permintaan.

Anda tetap ingin meninggalkan cookie sesi sebagai cookie.

Sesuai perbedaan teknis, dan juga pemahaman saya:

1. Selain sebagai cara lama menyimpan data, Cookies memberi Anda batas 4096 byte (4095, sebenarnya) - itu per cookie. Penyimpanan Lokal sebesar 5MB per domain - SO Pertanyaan juga menyebutkannya.

2. localStorageadalah implementasi dari StorageAntarmuka. Ia menyimpan data tanpa tanggal kedaluwarsa , dan hanya dihapus melalui JavaScript, atau membersihkan Tembolok Peramban / Data yang Disimpan Secara Lokal - tidak seperti cookie yang kedaluwarsa.

Dalam konteks JWT , Stormpath telah menulis artikel yang cukup membantu menguraikan cara-cara yang mungkin untuk menyimpannya, dan keuntungan (dis-) yang berkaitan dengan masing-masing metode.

Ini juga memiliki gambaran singkat tentang serangan XSS dan CSRF, dan bagaimana Anda dapat memerangi mereka.

Saya telah melampirkan beberapa cuplikan singkat dari artikel di bawah ini, jika artikel mereka diambil offline / situs mereka turun.

Penyimpanan lokal

Masalah:

Penyimpanan Web (localStorage / sessionStorage) dapat diakses melalui JavaScript pada domain yang sama. Ini berarti bahwa setiap JavaScript yang berjalan di situs Anda akan memiliki akses ke penyimpanan web, dan karena ini dapat rentan terhadap serangan lintas situs (XSS). Singkatnya, XSS adalah jenis kerentanan di mana penyerang dapat menyuntikkan JavaScript yang akan berjalan di halaman Anda. Serangan XSS dasar berupaya menyuntikkan JavaScript melalui input formulir, tempat penyerang memberi peringatan ('Anda Dibajak'); ke dalam formulir untuk melihat apakah itu dijalankan oleh browser dan dapat dilihat oleh pengguna lain.

Pencegahan:

Untuk mencegah XSS, respons umum adalah melarikan diri dan menyandikan semua data yang tidak dipercaya. Tapi ini jauh dari cerita lengkap. Pada 2015, aplikasi web modern menggunakan JavaScript yang diinangi pada CDN atau infrastruktur luar. Aplikasi web modern termasuk perpustakaan JavaScript pihak ketiga untuk pengujian A / B, analisis saluran / pasar, dan iklan. Kami menggunakan manajer paket seperti Bower untuk mengimpor kode orang lain ke dalam aplikasi kami.

Bagaimana jika hanya satu dari skrip yang Anda gunakan yang dikompromikan? JavaScript berbahaya dapat disematkan pada halaman, dan Penyimpanan Web dikompromikan. Jenis serangan XSS ini dapat membuat Penyimpanan Web semua orang yang mengunjungi situs Anda, tanpa sepengetahuan mereka. Ini mungkin sebabnya banyak organisasi menyarankan untuk tidak menyimpan sesuatu yang bernilai atau mempercayai informasi apa pun dalam penyimpanan web. Ini termasuk pengidentifikasi dan token sesi.

Sebagai mekanisme penyimpanan, Penyimpanan Web tidak menerapkan standar aman apa pun selama transfer. Siapa pun yang membaca Penyimpanan Web dan menggunakannya harus melakukan uji tuntas untuk memastikan mereka selalu mengirim JWT melalui HTTPS dan tidak pernah HTTP.

Kue

Masalah:

Cookie, ketika digunakan dengan bendera cookie HttpOnly, tidak dapat diakses melalui JavaScript, dan kebal terhadap XSS. Anda juga dapat mengatur bendera cookie Aman untuk menjamin cookie hanya dikirim melalui HTTPS. Ini adalah salah satu alasan utama bahwa cookie telah diungkit di masa lalu untuk menyimpan token atau data sesi. Pengembang modern ragu-ragu untuk menggunakan cookie karena mereka secara tradisional mengharuskan negara untuk disimpan di server, sehingga melanggar praktik terbaik yang tenang. Cookie sebagai mekanisme penyimpanan tidak mengharuskan status disimpan di server jika Anda menyimpan JWT dalam cookie. Ini karena JWT merangkum semua yang dibutuhkan server untuk melayani permintaan.

Namun, cookie rentan terhadap berbagai jenis serangan: pemalsuan permintaan lintas situs (CSRF). Serangan CSRF adalah jenis serangan yang terjadi ketika situs web berbahaya, email, atau blog menyebabkan browser web pengguna untuk melakukan tindakan yang tidak diinginkan pada situs tepercaya di mana pengguna saat ini diautentikasi. Ini adalah eksploitasi bagaimana browser menangani cookie. Cookie hanya dapat dikirim ke domain yang diizinkan. Secara default, ini adalah domain yang awalnya mengatur cookie. Cookie akan dikirim untuk permintaan terlepas dari apakah Anda berada di galaxies.com atau hahagonnahackyou.com.

Pencegahan:

Browser modern mendukung SameSitebendera , selain HttpOnlydan Secure. Tujuan dari bendera ini adalah untuk mencegah cookie dari ditransmisikan dalam permintaan lintas situs, mencegah berbagai jenis serangan CSRF.

Untuk browser yang tidak mendukung SameSite, CSRF dapat dicegah dengan menggunakan pola token yang disinkronkan. Ini terdengar rumit, tetapi semua kerangka kerja web modern memiliki dukungan untuk ini.

Misalnya, AngularJS memiliki solusi untuk memvalidasi bahwa cookie hanya dapat diakses oleh domain Anda. Langsung dari AngularJS docs:

Saat melakukan permintaan XHR, layanan $ http membaca token dari cookie (secara default, XSRF-TOKEN) dan menetapkannya sebagai header HTTP (X-XSRF-TOKEN). Karena hanya JavaScript yang berjalan di domain Anda yang dapat membaca cookie, server Anda dapat yakin bahwa XHR berasal dari JavaScript yang berjalan di domain Anda. Anda dapat membuat perlindungan CSRF ini tanpa kewarganegaraan dengan memasukkan xsrfTokenklaim JWT:

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "tom@andromeda.com",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

Memanfaatkan perlindungan CSRF kerangka kerja aplikasi web Anda membuat cookie sangat kuat untuk menyimpan JWT. CSRF juga dapat dicegah sebagian dengan memeriksa tajuk HTTP Referer dan Origin dari API Anda. Serangan CSRF akan memiliki header Referer dan Origin yang tidak terkait dengan aplikasi Anda.

Artikel lengkap dapat ditemukan di sini: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Mereka juga memiliki artikel bermanfaat tentang cara terbaik merancang dan mengimplementasikan JWT, berkaitan dengan struktur token itu sendiri: https://stormpath.com/blog/jwt-the-right-way/

Dengan localStorage, aplikasi web dapat menyimpan data secara lokal di dalam browser pengguna. Sebelum HTML5, data aplikasi harus disimpan dalam cookie, termasuk dalam setiap permintaan server. Sejumlah besar data dapat disimpan secara lokal, tanpa memengaruhi kinerja situs web. Meskipun localStoragelebih modern, ada beberapa pro dan kontra untuk kedua teknik tersebut.

Kue

Pro

• Dukungan warisan (sudah ada selamanya)
• Data persisten
• Tanggal kedaluwarsa

Cons

• Setiap domain menyimpan semua cookie dalam satu string, yang dapat membuat penguraian data menjadi sulit
• Data tidak terenkripsi, yang menjadi masalah karena ... ... meskipun berukuran kecil, cookie dikirim dengan setiap permintaan HTTP Ukuran terbatas (4KB)
• Injeksi SQL dapat dilakukan dari cookie

Penyimpanan lokal

Pro

• Dukungan oleh sebagian besar browser modern
• Data persisten yang disimpan langsung di browser
• Aturan asal yang sama berlaku untuk data penyimpanan lokal
• Tidak dikirim dengan setiap permintaan HTTP
• ~ 5MB penyimpanan per domain (yaitu 5120KB)

Cons

• Tidak didukung oleh apa pun sebelumnya: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• Jika server membutuhkan informasi klien yang tersimpan, Anda harus mengirimnya.

localStoragepenggunaannya hampir identik dengan sesi satu. Mereka memiliki metode yang sangat tepat, sehingga beralih dari sesi ke localStoragebenar-benar permainan anak-anak. Namun, jika data yang disimpan benar-benar penting untuk aplikasi Anda, Anda mungkin akan menggunakan cookie karena cadangan jika localStoragetidak tersedia. Jika Anda ingin memeriksa dukungan browser localStorage, yang harus Anda lakukan adalah menjalankan skrip sederhana ini:

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

"Nilai localStorage pada halaman Secure (SSL) terisolasi" karena seseorang memperhatikan perlu diingat bahwa localStorage tidak akan tersedia jika Anda beralih dari protokol aman 'http' ke 'https', di mana cookie akan tetap dapat diakses. Ini agak penting untuk diperhatikan jika Anda bekerja dengan protokol yang aman.

Nah, kecepatan penyimpanan lokal sangat tergantung pada browser yang digunakan klien, serta sistem operasi. Chrome atau Safari di mac bisa jauh lebih cepat daripada Firefox di PC, terutama dengan API yang lebih baru. Seperti biasa, pengujian adalah teman Anda (saya tidak dapat menemukan tolok ukur).

Saya benar-benar tidak melihat perbedaan besar dalam cookie vs penyimpanan lokal. Selain itu, Anda harus lebih khawatir tentang masalah kompatibilitas: tidak semua browser bahkan mulai mendukung API HTML5 baru, sehingga cookie akan menjadi taruhan terbaik Anda untuk kecepatan dan kompatibilitas.

Perlu disebutkan juga bahwa localStoragetidak dapat digunakan ketika pengguna menjelajah dalam mode "pribadi" di beberapa versi Safari seluler.

Dikutip dari MDN ( https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage ):

Catatan: Dimulai dengan iOS 5.1, Safari Mobile menyimpan data Penyimpanan lokal di folder cache, yang sewaktu-waktu harus dibersihkan, atas perintah OS, biasanya jika ruangnya pendek. Mode Penjelajahan Pribadi Safari Mobile juga mencegah penulisan ke localStorage sepenuhnya.

Penyimpanan lokal dapat menyimpan hingga 5 mb data offline, sedangkan sesi juga dapat menyimpan hingga 5 mb data. Tetapi cookie hanya dapat menyimpan data 4kb dalam format teks.

Data penyimpanan LOCAl dan Session dalam format JSON, sehingga mudah diurai. Tetapi data cookie dalam format string.

Kue kering :

1. Diperkenalkan sebelum HTML5.
2. Memiliki tanggal kedaluwarsa.
3. Bersihkan oleh JS atau dengan Clear Browsing Data browser atau setelah tanggal kedaluwarsa.
4. Akan dikirim ke server per setiap permintaan.
5. Kapasitasnya 4KB.
6. Hanya string yang dapat disimpan di cookie.
7. Ada dua jenis cookie: persisten dan sesi.

Penyimpanan lokal:

1. Diperkenalkan dengan HTML5.
2. Tidak memiliki tanggal kedaluwarsa.
3. Bersihkan oleh JS atau dengan Hapus Data Perambanan browser.
4. Anda dapat memilih kapan data harus dikirim ke server.
5. Kapasitasnya 5MB.
6. Data disimpan tanpa batas waktu, dan harus berupa string.
7. Hanya ada satu tipe.