Bagaimana menjaga agar aplikasi tidak memiliki kewarganegaraan

Ini mungkin pertanyaan yang berbelit-belit, tapi saya mencoba untuk mendapatkan pemahaman yang lebih baik tentang kewarganegaraan.

Berdasarkan apa yang saya baca, aplikasi web harus stateless, artinya setiap permintaan diperlakukan sebagai transaksi independen. Akibatnya, Sesi dan Cookies harus dihindari (karena keduanya stateful). Pendekatan yang lebih baik adalah dengan menggunakan Token, yang stateless karena tidak ada yang disimpan di server.

Jadi saya mencoba memahami, bagaimana aplikasi web bisa stateless ketika ada data yang disimpan untuk sesi saya (seperti barang-barang di keranjang belanja)? Apakah ini sebenarnya disimpan dalam database di suatu tempat dan kemudian secara berkala dibersihkan? Bagaimana cara kerjanya saat Anda menggunakan token alih-alih cookie?

Dan kemudian sebagai pertanyaan terkait, apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) Sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?

"aplikasi web harus stateless" harus dipahami sebagai "aplikasi web harus stateless kecuali ada alasan yang sangat bagus untuk memiliki status" . "Keranjang belanja" adalah fitur stateful dengan desain, dan menyangkal bahwa itu cukup produktif. Inti dari pola keranjang belanja adalah untuk mempertahankan kondisi aplikasi di antara permintaan.

Alternatif yang dapat saya bayangkan sebagai situs web tanpa kewarganegaraan yang menerapkan keranjang belanja adalah aplikasi satu halaman yang membuat keranjang belanja sepenuhnya sisi-klien, mengambil informasi produk dengan panggilan AJAX dan kemudian mengirimkannya ke server sekaligus ketika pengguna melakukan checkout. Tapi saya ragu saya pernah melihat seseorang benar-benar melakukan itu, karena itu tidak memungkinkan pengguna untuk menggunakan beberapa tab browser dan tidak mempertahankan status ketika mereka secara tidak sengaja menutup tab. Tentu, ada solusi seperti menggunakan penyimpanan lokal, tetapi kemudian Anda memiliki negara lagi, hanya pada klien, bukan pada server.

Setiap kali Anda memiliki aplikasi web yang mengharuskan untuk bertahan data antara tampilan halaman, Anda biasanya melakukannya dengan memperkenalkan sesi. Sesi permintaan milik dapat diidentifikasi oleh cookie atau dengan parameter URL yang Anda tambahkan ke setiap tautan. Cookie harus disukai karena mereka membuat URL Anda lebih praktis dan mencegah pengguna Anda berbagi URL tanpa sengaja dengan id sesi mereka di dalamnya. Tetapi memiliki token URL sebagai cadangan juga penting untuk pengguna yang menonaktifkan cookie. Sebagian besar kerangka kerja pengembangan web memiliki sistem penanganan sesi yang dapat melakukan ini di luar kotak.

Di sisi server, informasi sesi biasanya disimpan dalam database. Caching dalam-sisi-server adalah opsional. Ini dapat sangat meningkatkan waktu respons, tetapi tidak akan memungkinkan Anda untuk mentransfer sesi antara server yang berbeda. Jadi Anda akan membutuhkan database persisten sebagai cadangan.

apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?

Apakah mereka mengizinkan Anda untuk masuk? Ketika Anda kemudian menutup tab dan mengunjungi kembali situs tersebut, apakah Anda masih masuk? Jika ya, maka mereka menggunakan cookie untuk menjaga identitas Anda di antara sesi.

Memang benar bahwa aplikasi web harus stateless. Namun, variabel sesi, cookie, dan token tidak melanggar ini ketika mereka semua disimpan di klien (browser web). Mereka bisa menjadi parameter dalam permintaan.

Berikut model yang disederhanakan:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Ini bisa berfungsi untuk Pertukaran Stack Rekayasa Perangkat Lunak . Jawaban yang saya ketikkan ini adalah bagian dari kondisi browser web saya. Selama itu satu-satunya tempat di mana itu berada, itu tidak dapat diakses oleh siapa pun kecuali aku. Tetapi segera setelah saya menekan Post your Answerbrowser saya mengirimkannya ke server web. Server web memproses pos tanpa menggunakan statusnya sendiri. Ia belajar siapa saya dari browser saya dan dari database. Setelah selesai memeriksa posting saya, dan menambahkannya ke database, server web segera melupakan saya.

Itulah arti kewarganegaraan. Server tidak bertanggung jawab untuk mengingat semua ini. Itu bukan tugasnya.

Melakukan ini memiliki banyak keuntungan. Jika server web memiliki kebocoran memori, itu dapat dideteksi karena jejak memorinya tidak boleh bertambah. Jika server web mogok, identitas saya tidak sesuai dengan itu. Jika seseorang mencoba melakukan serangan penolakan layanan, mereka tidak dapat menggunakan sumber daya status server web untuk melakukannya, karena server web tidak mengalokasikan status apa pun untuk mereka di antara sesi. Ini semua bertujuan untuk membuat server web stabil. Dengan begitu, ketika mulai berjalan, ia tetap berjalan.

Sekarang tentu saja, saya mengonsumsi sumber daya dalam basis data, tetapi sumber daya tersebut pertama-tama telah diperiksa terhadap kelonggaran saya oleh sesuatu yang stabil yang dapat kita andalkan untuk melindungi basis data dari web liar dan wol: server web yang memberlakukan aturan bisnis dan tanpa kewarganegaraan.

aplikasi web harus stateless

Omong kosong. Permintaan web harus tanpa kewarganegaraan. Atau lebih tepatnya, permintaan web tidak memiliki kewarganegaraan.

Tapi, mengatakan bahwa seluruh aplikasi harus stateless adalah omong kosong.

setiap permintaan diperlakukan sebagai transaksi independen.

Ya persis . Atau lebih tepatnya, ya, tentu saja . Melalui HTTP, setiap permintaan secara inheren tidak tergantung dari semua permintaan lainnya. Menambahkan "status" ke HTTP mengharuskan Anda secara eksplisit mengidentifikasi, menyimpan, dan mengambil "status" untuk setiap permintaan "status". Dan itu membutuhkan upaya, menurunkan kinerja, dan menambah kompleksitas.

Dan, untuk alasan itu, setiap permintaan yang bisa stateless "harus" stateless.

Akibatnya, Sesi dan Cookies harus dihindari (karena keduanya stateful). Pendekatan yang lebih baik adalah menggunakan Token

Beberapa hal: Token dapat dikaitkan dengan penyimpanan sesi juga. Cookie tidak perlu dikaitkan dengan penyimpanan sesi. Token sering disimpan dalam cookie. Dan, terkadang sesi hanyalah alat yang tepat untuk pekerjaan itu.

Itu berarti bahwa setidaknya kadang-kadang , sesi dan cookie sama "lebih baik" dengan token!

[Token] tidak memiliki kewarganegaraan karena tidak ada yang disimpan di server.

Baiklah, itu saja. Itulah dogma "tanpa kewarganegaraan" sebenarnya. Meskipun, untuk lebih jelasnya, ini bukan tentang menyimpan "tidak ada" di server, ini tentang tidak menyimpan status sesi di server.

Kotak masuk Gmail saya dalam keadaan, misalnya. Dan sebaiknya disimpan di server! Tapi, ini bukan status sesi .

Jadi, alih-alih memiliki server yang dapat mengambil pengenal kecil dan mencari tahu siapa Anda dan sebagainya, aplikasi kewarganegaraan ingin diingatkan siapa Anda dan apa yang Anda lakukan dengan setiap permintaan berdarah. Status aplikasi masih ada, klien hanya bertanggung jawab untuk memegangnya.

Sekarang, jika keadaan itu kecil, itu mungkin OK. Dalam beberapa kasus itu sangat bagus.

Dan kemudian, tentu saja, ada hal-hal yang kita harapkan menjadi negara ...

bagaimana aplikasi web bisa stateless ketika ada data yang disimpan untuk sesi saya (seperti barang-barang di keranjang belanja)? Apakah ini sebenarnya disimpan dalam database di suatu tempat dan kemudian secara berkala dibersihkan?

Dua pilihan. Entah Anda memiliki sesi, atau Anda menyangkal!

... Tapi serius. Anda biasanya tidak menyimpan keranjang dalam cookie. Sesuatu seperti kereta belanja akan disimpan dalam sesi "tradisional", atau akan disimpan sebagai Cartobjek, dengan semacam ID yang digunakan server untuk menariknya ke permintaan berikutnya. Agak seperti .. uhh ... ... err ... sesi.

Untuk yang benar-benar serius: Ada tingkat besar di mana "keadaan" adalah apa yang kita sebut ketika dua agen yang berkomunikasi dapat mengontekstualisasikan pesan dalam percakapan. Dan sebuah sesi, secara tradisional dipahami, adalah apa yang biasanya kita sebut mekanisme yang dengannya hal ini terjadi.

Saya berpendapat bahwa, terlepas dari apakah Anda menggunakan token atau "sesi," untuk setiap permintaan yang ditangani oleh server Anda, Anda harus mengontekstualisasikan permintaan untuk memenuhinya, atau tidak. Jika konteksnya tidak perlu, jangan ambil. Jika konteksnya adalah diperlukan, Anda lebih baik memilikinya terdekat!

Dan kemudian sebagai pertanyaan terkait, apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) Sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?

Mungkin keduanya. Tetapi, secara umum, mereka melakukan persis apa yang Anda lakukan: Mereka mengatur cookie untuk mengidentifikasi catatan "status" dalam database "sesi" besar-besaran.

Jika memungkinkan, saya menduga mereka mendorong klaim identitas dasar menjadi "token" berumur pendek untuk menghindari pertengkaran yang tidak perlu pada penyimpanan terpusat. Tetapi, fakta bahwa banyak dari layanan ini mengizinkan saya untuk "keluar dari semua lokasi lain" adalah indikator yang baik bahwa, jika mereka menggunakan token sama sekali, mereka setidaknya "didukung" oleh model sesi semi-tradisional .

Statefulness tidak selalu merupakan hal yang buruk, tetapi Anda perlu memahami perbedaan antara aplikasi stateful dan stateless. Singkatnya, aplikasi stateful menjaga informasi tentang sesi saat ini, dan aplikasi stateless tidak. Informasi yang disimpan secara permanen sebagai bagian dari akun pengguna mungkin atau mungkin tidak disimpan dalam suatu sesi, tetapi menyimpan informasi yang terkait dengan akun pengguna tidak dengan sendirinya membuat aplikasi menjadi stateful. Statefulness mengharuskan server mempertahankan informasi tentang sesi pengguna saat ini di luar apa yang dipertahankan oleh browser klien. Misalnya, klien dapat mengotentikasi dan diberi cookie JSESSIONID, yang kemudian dikirimkan ke server dengan setiap permintaan. Jika server mulai menyimpan hal-hal dalam lingkup sesi aplikasi berdasarkan JSESSIONID ini, itu menjadi stateful.

Kewarganegaraan

Dengan stateless, maksud kami adalah server dan klien tidak menjaga informasi terkini tentang sesi pengguna. Klien dan server dapat menggunakan beberapa bentuk token untuk menyediakan otentikasi antara permintaan, tetapi tidak ada informasi terkini lainnya yang disimpan. Kasus penggunaan yang umum untuk solusi semacam itu mungkin adalah situs berita tempat sebagian besar pengguna (konsumen baru) mengonsumsi informasi tetapi tidak menghasilkan informasi yang kembali ke situs tersebut. Dalam kasus seperti itu, situs tidak perlu menyimpan informasi tentang sesi pengguna saat ini. Perhatikan bahwa situs tersebut mungkin masih menggunakan cookie untuk mengidentifikasi pengguna dan menyimpan informasi tentang penggunaan situs tersebut oleh pengguna tersebut, tetapi itu mungkin masih dianggap sebagai stateless karena semua yang direkam dapat bersifat transaksional, misalnya tautan apa yang diklik pengguna, yang mungkin direkam oleh server, tetapi tidak dikelola dalam sesi pengguna.

Statefulness di server

Di server, aplikasi stateful menyimpan informasi status tentang pengguna saat ini. Pendekatan ini umumnya melibatkan penggunaan cookie untuk mengidentifikasi sistem pengguna sehingga keadaan dapat dipertahankan di server di antara permintaan. Sesi dapat diotentikasi atau tidak, tergantung pada konteks aplikasi. Aplikasi server stateful menawarkan keuntungan dari caching informasi status pengguna di server, mempercepat pencarian dan waktu respons halaman. Di sisi bawah, menyimpan informasi dalam ruang lingkup sesi mahal, dan pada skala itu menjadi sangat intensif sumber daya. Ini juga menciptakan vektor serangan potensial bagi peretas untuk mencoba dan membajak pengidentifikasi sesi dan mencuri sesi pengguna. Aplikasi server stateful juga memiliki tantangan melindungi sesi pengguna terhadap gangguan layanan yang tidak terduga, misalnya kegagalan server.

Statefulness pada klien

Menggunakan JavaScript dan teknologi browser modern seperti sessionStorage, aplikasi sekarang dapat dengan mudah menyimpan informasi status tentang sesi pengguna pada perangkat pengguna itu. Secara keseluruhan, aplikasi mungkin masih dianggap stateful, tetapi pekerjaan mempertahankan status telah dipindahkan ke klien. Pendekatan ini memiliki keuntungan besar (untuk pemelihara aplikasi Web) dibandingkan mempertahankan status pada server karena setiap pengguna, pada dasarnya, mempertahankan status mereka sendiri, dan tidak ada beban pada infrastruktur server. Pada skala web, pilihan arsitektur semacam itu memiliki dampak besar untuk biaya perangkat keras dan listrik. Harganya jutaan dolar per tahun untuk mempertahankan status di server. Pindah ke sistem yang mempertahankan status klien dapat menghemat jutaan dolar per tahun.

Token v. Cookie

Cookie bertindak sebagai pengidentifikasi untuk perangkat / browser klien. Mereka dapat digunakan untuk menyimpan segala macam hal, tetapi umumnya mereka menyimpan beberapa bentuk pengidentifikasi, seperti CFID / CFTOKEN di aplikasi CFML. Cookie dapat diatur untuk hidup di browser pengguna untuk waktu yang lama, memungkinkan untuk melakukan hal-hal seperti mempertahankan otentikasi pada aplikasi di antara sesi browser. Cookie juga dapat diatur ke memori saja sehingga mereka kedaluwarsa ketika pengguna menutup browser.

Token umumnya semacam mengidentifikasi informasi tentang pengguna yang dihasilkan di server (menggunakan enkripsi untuk mengacak informasi), diteruskan ke klien, dan dikembalikan ke server dengan permintaan berikutnya. Mereka mungkin diteruskan di header permintaan dan tanggapan, yang merupakan pola umum dalam aplikasi satu halaman. Idealnya, setiap permintaan / respons menghasilkan pembuatan token baru, sehingga token tidak dapat dicegat dan digunakan nanti oleh penyerang.

Aplikasi Halaman Tunggal dan status klien

Dengan SPA, informasi status dimuat ke browser klien dan dipertahankan di sana. Ketika keadaan berubah, misalnya Anda memposting pembaruan ke akun media sosial Anda, klien menyampaikan transaksi baru itu ke server. Dalam hal ini, server menyimpan pembaruan itu ke penyimpanan data yang persisten seperti database, dan menyampaikan informasi apa pun kembali ke klien yang perlu disinkronkan dengan server berdasarkan pembaruan (misalnya ID untuk pembaruan).

Perhatikan bahwa pola penyimpanan ini pada klien menawarkan keuntungan untuk pengalaman online / offline di mana Anda dapat terputus dari server sementara masih memiliki aplikasi yang agak dapat digunakan. Twitter adalah contoh yang bagus untuk kasus ini, di mana Anda dapat meninjau apa pun yang dimuat sisi klien dalam umpan Twitter Anda, bahkan jika Anda terputus dari aplikasi server Twitter. Pola ini juga menciptakan kompleksitas dalam sinkronisasi antara server dan klien, yang merupakan subjek tersendiri. Kompleksitas dari solusi adalah tradeoff untuk dapat mempertahankan keadaan pada klien.

Statefulness pada klien membuat aplikasi web merasa dan berperilaku lebih seperti aplikasi desktop tradisional. Tidak seperti aplikasi desktop, Anda biasanya tidak akan memiliki semua informasi akun Anda dimuat ke dalam sesi klien Anda di browser. Melakukan hal itu dalam banyak kasus akan menjadi tidak praktis dan menghasilkan pengalaman buruk. Bisakah Anda bayangkan mencoba memuat seluruh kotak Gmail ke browser? Sebagai gantinya, klien menyimpan informasi seperti apa label / folder yang Anda lihat dan di mana dalam daftar email di folder yang Anda cari. Menyeimbangkan informasi negara mana yang harus dipertahankan dan apa yang diminta sesuai kebutuhan adalah tantangan rekayasa lain dari pola ini, dan sekali lagi, ini mewakili pertukaran antara kepraktisan dan memberikan pengalaman pengguna yang baik.

Kereta belanja dan sejenisnya

Adapun spesifik seperti gerobak belanja, itu sangat tergantung pada solusinya. Keranjang belanja dapat disimpan dalam database di server, mungkin hanya disimpan dalam ruang lingkup sesi di server, atau bahkan dapat disimpan di klien. Amazon memiliki gerobak belanja persisten untuk pengguna yang masuk, dan gerobak "sementara" untuk pengguna anonim, meskipun gerobak ini persisten sampai batas tertentu.

Ketika Anda berbicara tentang sesuatu seperti Google, yang sebenarnya adalah sekelompok aplikasi berbeda yang hidup di bawah merek yang sama, mereka mungkin tidak berbagi arsitektur yang sama, dan masing-masing dibangun dengan cara yang paling memenuhi kebutuhan penggunanya. Jika Anda ingin mempelajari cara membangun situs, buka alat pengembang di browser Anda dan lihatlah. Periksa kuki, tonton lalu lintas jaringan, dan lihat cara kerjanya.

Maaf jika jawaban ini sedikit mengoceh, tetapi status adalah subjek yang kompleks.

Sesi dan cookie tidak harus dihindari. Anda masih dapat memilikinya dengan aplikasi web stateless.

Ada perbedaan besar antara Java dan Ruby on Rails. Aplikasi Java akan menyimpan sesi dalam memori menggunakan kunci sesi yang disimpan dalam cookie. Ini cepat untuk mengambil status pengguna dan keranjang belanja. Namun, Anda harus selalu menekan server yang sama dengan sesi Anda.

Aplikasi Rails menyimpan id pengguna dalam cookie yang ditandatangani dan dienkripsi. Itu tidak bisa dirusak. Saat Anda memuat halaman, aplikasi web mengambil status, pengguna, dan keranjang belanja Anda dari database. Ini lebih lambat, tetapi kuncinya adalah, Anda dapat menekan instance apa pun ! Ini memungkinkan Anda untuk memulai kembali, menskala, mematikan contoh sesuka hati. Sangat mudah. Itu juga dapat dibuat lebih cepat dengan database cache bersama, dalam memori, seperti Redis. Atau Anda dapat menyimpan keranjang belanja di cookie, asalkan cukup kecil.

Jadi Anda bisa mencapai kewarganegaraan, melalui teknik-teknik pintar, dan menambahkan kemampuan untuk mengukur sesuka hati.

The Protokol adalah stateless.

Tetapi dari situ tidak serta-merta mengikuti bahwa aplikasi yang menggunakan protokol harus stateless.

Berikut adalah beberapa jawaban StackOverflow terkait yang menjelaskan perbedaan dengan baik:

• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/stateless-web-application-an-urban-legend/34677668#34677668

Ketika merujuk pada stateless - mis. Dalam Layanan HTTP RESTful - ini akan menghindari menyimpan keadaan di sisi server. Paling-paling, itu termasuk juga menghindari menyimpan negara dalam database atau penyimpanan persisten lainnya di backend. Untuk memperjelas saya berbicara tentang keadaan bukan data secara umum. Tampaknya beberapa pria mencampuradukkan semuanya.

Komunikasi tanpa kewarganegaraan memiliki beberapa manfaat terutama mengenai skalabilitas dan ketersediaan.

Pendekatan yang lebih baik adalah dengan menggunakan Token, yang stateless karena tidak ada yang disimpan di server.

Itu benar (untuk protokol otentikasi dan otorisasi tertentu). Token dapat (tetapi tidak secara langsung) memberikan semua informasi dalam permintaan yang diperlukan untuk mengotentikasi pengguna atau mengotorisasi tindakan. Sebagai contoh, lihat JWT .

Jadi saya mencoba memahami, bagaimana aplikasi web bisa stateless ketika ada data yang disimpan untuk sesi saya (seperti barang-barang di keranjang belanja)? Apakah ini sebenarnya disimpan dalam database di suatu tempat dan kemudian secara berkala dibersihkan? Bagaimana cara kerjanya saat Anda menggunakan token alih-alih cookie?

Mengenai contoh keranjang belanja. Tidak ada masalah untuk menyimpan semua item keranjang di sisi klien tanpa menggunakan sesi atau cookie. Anda dapat menemukan contohnya di smashingmagazine.com . Tetapi mungkin juga untuk mewujudkan keranjang belanja tanpa kewarganegaraan dengan cookie (setidaknya jika bermacam-macam Anda tidak begitu besar dan penyimpanan 4kb sudah cukup untuk Anda).

Jangan salah paham, itu tidak berarti Anda harus menerapkan keranjang belanja tanpa kewarganegaraan dengan harga berapa pun. Amazon atau platform belanja online besar lainnya menggunakan implementasi kereta belanja stateful karena pengalaman pengguna dan kegunaan lebih penting bagi mereka daripada menyesuaikan persyaratan teknis non-fungsional seperti skalabilitas.

Secara umum, token tidak digunakan untuk menyimpan informasi seperti item keranjang. Mereka digunakan untuk otentikasi dan otorisasi tanpa kewarganegaraan.

Dan kemudian sebagai pertanyaan terkait, apakah situs web utama (Amazon, Google, Facebook, Twitter, dll.) Sebenarnya tanpa kewarganegaraan? Apakah mereka menggunakan token atau cookie (atau keduanya)?

Jika Anda bertanya apakah mereka menggunakan cookie atau token untuk otentikasi, jawabannya adalah mereka menggunakan keduanya. Untuk pengguna sebagian besar cookie untuk klien teknis sebagian besar token digunakan.

Oke, aturan yang Anda kutip secara teknis salah. Semua lapisan aplikasi web memiliki status.

Maksud aturan ini adalah "jangan pegang sisi server negara bagian per sesi".

Yakni, variabel sesi dalam ASP , yang biasanya digunakan untuk melakukan hal-hal seperti item dalam keranjang / nama pengguna, dll.

Alasannya adalah Anda kehabisan memori di server karena aplikasi Anda mendapatkan lebih banyak pengguna. Memindahkan penyimpanan ke database atau cache bersama tidak menyelesaikan masalah karena Anda masih mengalami hambatan.

Untuk mempertahankan status aplikasi per pengguna tanpa memukul masalah ini, pindahkan status ke sisi klien. Misalnya, masukkan item keranjang ke dalam cookie atau penyimpanan sisi klien yang lebih canggih.

Karena jumlah klien berskala dengan jumlah pengguna, aplikasi Anda secara keseluruhan tidak akan mengalami hambatan dan skala akan baik.