Apakah sesi benar-benar melanggar RESTfulness?

Apakah menggunakan sesi dalam RESTful API benar-benar melanggar RESTfulness? Saya telah melihat banyak pendapat mengarah ke arah mana pun, tetapi saya tidak yakin bahwa sesi-sesi tersebut RESTless . Dari sudut pandang saya:

• otentikasi tidak dilarang untuk RESTfulness (jika tidak akan ada sedikit penggunaan dalam layanan RESTful)
• otentikasi dilakukan dengan mengirimkan token otentikasi dalam permintaan, biasanya tajuk
• token otentikasi ini perlu diperoleh entah bagaimana dan dapat dicabut, dalam hal ini perlu diperbarui
• token otentikasi perlu divalidasi oleh server (jika tidak maka otentikasi tidak akan)

Jadi bagaimana sesi melanggar ini?

• sisi klien, sesi direalisasikan menggunakan cookie
• cookie hanyalah tajuk HTTP tambahan
• cookie sesi dapat diperoleh dan dicabut kapan saja
• cookie sesi dapat memiliki waktu hidup yang tak terbatas jika perlu
• id sesi (token otentikasi) divalidasi di sisi server

Dengan demikian, bagi klien, cookie sesi persis sama dengan mekanisme otentikasi berbasis header HTTP lainnya, kecuali bahwa cookie tersebut menggunakan Cookieheader alih-alih Authorizationatau atau beberapa header kepemilikan lainnya. Jika tidak ada sesi yang dilampirkan pada sisi server nilai cookie, mengapa itu membuat perbedaan? Implementasi sisi server tidak perlu menjadi perhatian klien selama server berperilaku tenang. Dengan demikian, cookie sendiri tidak boleh membuat REST API , dan sesi hanyalah cookie untuk klien.

Apakah asumsi saya salah? Apa yang membuat cookie sesi RESTless ?

Pertama, mari kita definisikan beberapa istilah:

• Tenang:

  Seseorang dapat mengkarakterisasi aplikasi yang sesuai dengan batasan REST yang dijelaskan dalam bagian ini sebagai "RESTful". [15] Jika suatu layanan melanggar salah satu kendala yang dipersyaratkan, itu tidak dapat dianggap TENANG.

  menurut wikipedia .

• kendala kewarganegaraan:

  Kami selanjutnya menambahkan kendala pada interaksi klien-server: komunikasi harus bersifat stateless, seperti pada gaya client-stateless-server (CSS) dari Bagian 3.4.3 (Gambar 5-3), sehingga setiap permintaan dari klien ke server harus berisi semua informasi yang diperlukan untuk memahami permintaan, dan tidak dapat memanfaatkan konteks yang tersimpan di server. Karenanya, status sesi disimpan sepenuhnya pada klien.

  sesuai dengan disertasi Fielding .

Jadi sesi sisi server melanggar batasan stateless REST, dan juga RESTfulness.

Dengan demikian, bagi klien, cookie sesi persis sama dengan mekanisme otentikasi berbasis header HTTP lainnya, kecuali bahwa cookie tersebut menggunakan header Cookie alih-alih Otorisasi atau header kepemilikan lainnya.

Dengan cookie sesi, Anda menyimpan status klien di server sehingga permintaan Anda memiliki konteks. Mari kita coba menambahkan load balancer dan instance layanan lain ke sistem Anda. Dalam hal ini, Anda harus membagikan sesi di antara instance layanan. Sulit untuk mempertahankan dan memperluas sistem seperti itu, sehingga ...

Menurut saya tidak ada yang salah dengan cookies. Teknologi cookie adalah mekanisme penyimpanan sisi klien di mana data yang disimpan dilampirkan secara otomatis ke header cookie oleh setiap permintaan. Saya tidak tahu kendala REST yang bermasalah dengan teknologi semacam itu. Jadi tidak ada masalah dengan teknologi itu sendiri, masalahnya adalah dengan penggunaannya. Fielding menulis sub-bagian tentang mengapa menurutnya cookie HTTP buruk.

Dari sudut pandang saya:

• otentikasi tidak dilarang untuk RESTfulness (jika tidak akan ada sedikit penggunaan dalam layanan RESTful)
• otentikasi dilakukan dengan mengirimkan token otentikasi dalam permintaan, biasanya tajuk
• token otentikasi ini perlu diperoleh entah bagaimana dan dapat dicabut, dalam hal ini perlu diperbarui
• token otentikasi perlu divalidasi oleh server (jika tidak maka otentikasi tidak akan)

Pandangan Anda cukup solid. Satu-satunya masalah adalah dengan konsep membuat token otentikasi di server. Anda tidak perlu bagian itu. Yang Anda butuhkan adalah menyimpan nama pengguna dan kata sandi pada klien dan mengirimkannya dengan setiap permintaan. Anda tidak perlu melakukan ini lebih dari HTTP auth basic dan koneksi terenkripsi:

• Gambar 1. - Otentikasi tanpa kewarganegaraan oleh klien tepercaya

Anda mungkin memerlukan cache auth-in-memory di sisi server untuk mempercepat, karena Anda harus mengotentikasi setiap permintaan.

Sekarang ini bekerja dengan baik oleh klien tepercaya yang ditulis oleh Anda, tetapi bagaimana dengan klien pihak ke-3? Mereka tidak dapat memiliki nama pengguna dan kata sandi dan semua izin pengguna. Jadi, Anda harus menyimpan secara terpisah izin apa yang dapat dimiliki oleh klien pihak ketiga oleh pengguna tertentu. Jadi pengembang klien dapat mendaftarkan mereka sebagai klien pihak ketiga, dan mendapatkan kunci API yang unik dan pengguna dapat mengizinkan klien pihak ketiga untuk mengakses beberapa bagian dari izin mereka. Seperti membaca nama dan alamat email, atau daftar teman-teman mereka, dll ... Setelah mengizinkan klien pihak ke-3 server akan menghasilkan token akses. Token akses ini dapat digunakan oleh klien pihak ke-3 untuk mengakses izin yang diberikan oleh pengguna, seperti:

• Gambar 2. - Otentikasi stateless oleh klien pihak ketiga

Jadi klien pihak ke-3 bisa mendapatkan token akses dari klien tepercaya (atau langsung dari pengguna). Setelah itu dapat mengirim permintaan yang valid dengan kunci API dan token akses. Ini adalah mekanisme auth pihak ketiga yang paling dasar. Anda dapat membaca lebih lanjut tentang detail implementasi dalam dokumentasi setiap sistem auth pihak ketiga, misalnya OAuth. Tentu saja ini bisa lebih kompleks dan lebih aman, misalnya Anda dapat menandatangani detail setiap permintaan di sisi server dan mengirim tanda tangan bersama dengan permintaan, dan seterusnya ... Solusi sebenarnya tergantung pada kebutuhan aplikasi Anda.

Pertama-tama, REST bukan agama dan tidak boleh didekati seperti itu. Meskipun ada keuntungan untuk layanan RESTful, Anda hanya harus mengikuti prinsip REST sejauh hal itu masuk akal untuk aplikasi Anda.

Yang mengatakan, otentikasi dan negara sisi klien tidak melanggar prinsip REST. Sementara REST mensyaratkan bahwa transisi status menjadi stateless, ini mengacu pada server itu sendiri. Pada intinya, semua REST adalah tentang dokumen. Gagasan di balik kewarganegaraan adalah bahwa SERVER adalah kewarganegaraan, bukan klien. Setiap klien yang mengeluarkan permintaan yang identik (header, cookie, URI, dll) yang sama harus dibawa ke tempat yang sama dalam aplikasi. Jika situs web menyimpan lokasi pengguna saat ini dan mengelola navigasi dengan memperbarui variabel navigasi sisi server ini, maka REST akan dilanggar. Klien lain dengan informasi permintaan yang identik akan dibawa ke lokasi yang berbeda tergantung pada kondisi sisi server.

Layanan web Google adalah contoh luar biasa dari sistem RESTful. Mereka membutuhkan header otentikasi dengan kunci otentikasi pengguna untuk diteruskan pada setiap permintaan. Ini sedikit melanggar prinsip REST, karena server melacak status kunci otentikasi. Keadaan kunci ini harus dipertahankan dan memiliki semacam tanggal kedaluwarsa / waktu setelah itu tidak lagi memberikan akses. Namun, seperti yang saya sebutkan di bagian atas posting saya, pengorbanan harus dilakukan untuk memungkinkan aplikasi untuk benar-benar berfungsi. Yang mengatakan, token otentikasi harus disimpan dengan cara yang memungkinkan semua klien yang mungkin untuk terus memberikan akses selama masa berlaku mereka. Jika satu server mengelola keadaan kunci otentikasi ke titik di mana server lain yang seimbang tidak dapat mengambil alih memenuhi permintaan berdasarkan kunci itu, Anda sudah mulai benar-benar melanggar prinsip-prinsip REST. Layanan Google memastikan bahwa, kapan saja, Anda dapat mengambil token otentikasi yang Anda gunakan pada ponsel Anda terhadap server keseimbangan beban A dan tekan server keseimbangan beban B dari desktop Anda dan masih memiliki akses ke sistem dan diarahkan ke sumber daya yang sama jika permintaannya identik.

Intinya adalah bahwa Anda perlu memastikan token otentikasi Anda divalidasi terhadap penyimpanan dukungan semacam (database, cache, apa pun) untuk memastikan bahwa Anda mempertahankan sebanyak mungkin properti REST.

Saya harap semua itu masuk akal. Anda juga harus memeriksa bagian Kendala dari artikel wikipedia tentang Representasi State Transfer jika Anda belum melakukannya. Hal ini sangat mencerahkan sehubungan dengan apa yang sebenarnya diperdebatkan oleh prinsip-prinsip REST dan mengapa.

Cookie bukan untuk otentikasi. Mengapa menemukan kembali roda? HTTP memiliki mekanisme otentikasi yang dirancang dengan baik. Jika kami menggunakan cookie, kami menggunakan HTTP sebagai protokol transport saja, jadi kami perlu membuat sistem pensinyalan kami sendiri , misalnya, untuk memberi tahu pengguna bahwa mereka memberikan otentikasi yang salah (menggunakan HTTP 401 akan salah karena kami mungkin tidak akan suplai Www-Authenticateke klien, karena spesifikasi HTTP memerlukan :)). Perlu juga dicatat bahwa Set-Cookiehanya rekomendasi untuk klien. Isinya mungkin atau mungkin tidak disimpan (misalnya, jika cookie dinonaktifkan), sementara Authorizationtajuk dikirim secara otomatis pada setiap permintaan.

Poin lain adalah bahwa, untuk mendapatkan cookie otorisasi, Anda mungkin ingin memberikan kredensial terlebih dahulu? Jika demikian, bukankah itu akan menjadi RESTless? Contoh sederhana:

• Anda mencoba GET /atanpa cookie
• Anda mendapatkan permintaan otorisasi
• Anda pergi dan otorisasi entah bagaimana suka POST /auth
• Anda mendapatkan Set-Cookie
• Anda coba GET /a dengan cookie. Tetapi apakah GET /aberperilaku idempoten dalam kasus ini?

Singkatnya, saya percaya bahwa jika kita mengakses beberapa sumber daya dan kita perlu mengautentikasi, maka kita harus mengautentikasi pada sumber daya yang sama , bukan di tempat lain.

Sebenarnya, RESTfulness hanya berlaku untuk RESOURCES, seperti yang ditunjukkan oleh Pengidentifikasi Sumber Daya Universal. Jadi untuk membicarakan hal-hal seperti header, cookie, dll. Sehubungan dengan REST tidak benar-benar tepat. REST dapat bekerja melalui protokol apa pun, meskipun secara rutin dilakukan melalui HTTP.

Penentu utama adalah ini: jika Anda mengirim panggilan REST, yang merupakan URI, maka setelah panggilan berhasil ke server, apakah URI mengembalikan konten yang sama, dengan asumsi tidak ada transisi yang telah dilakukan (PUT, POST, DELETE) ? Tes ini akan mengecualikan kesalahan atau permintaan otentikasi dikembalikan, karena dalam kasus itu, permintaan belum membuatnya ke server, yang berarti servlet atau aplikasi yang akan mengembalikan dokumen yang sesuai dengan URI yang diberikan.

Demikian juga, dalam kasus POST atau PUT, dapatkah Anda mengirim URI / muatan yang diberikan, dan terlepas dari berapa kali Anda mengirim pesan, itu akan selalu memperbarui data yang sama, sehingga GET berikutnya akan menghasilkan hasil yang konsisten?

REST adalah tentang data aplikasi, bukan tentang informasi tingkat rendah yang diperlukan untuk mendapatkan data yang ditransfer.

Dalam posting blog berikut, Roy Fielding memberikan ringkasan yang bagus dari seluruh ide REST:

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

"Sistem yang tenang berkembang dari satu kondisi-mapan ke kondisi-mapan, dan masing-masing kondisi-mapan tersebut adalah kondisi awal yang potensial dan kondisi akhir yang potensial. Yaitu, sistem tenang adalah jumlah komponen yang tidak diketahui mematuhi komponen sederhana yang terdiri dari aturan sedemikian rupa sehingga mereka selalu berada di REST atau transisi dari satu keadaan tenang ke keadaan tenang lainnya. Setiap negara dapat sepenuhnya dipahami oleh representasi (s) yang dikandungnya dan serangkaian transisi yang disediakannya, dengan transisi terbatas pada seragam serangkaian tindakan agar dapat dipahami. Sistem ini mungkin berupa diagram keadaan yang rumit, tetapi setiap agen pengguna hanya dapat melihat satu keadaan pada satu waktu (kondisi-mapan saat ini) dan dengan demikian setiap keadaan sederhana dan dapat dianalisis secara independen. pengguna, OTOH, dapat membuat transisi mereka sendiri kapan saja (mis., masukkan URL, pilih bookmark,buka editor, dll.). "

Pergi ke masalah otentikasi, apakah itu dilakukan melalui cookie atau header, selama informasi itu bukan bagian dari muatan URI dan POST, itu benar-benar tidak ada hubungannya dengan REST sama sekali. Jadi, dalam hal status kewarganegaraan, kita berbicara tentang data aplikasi saja.

Misalnya, saat pengguna memasukkan data ke layar GUI, klien melacak bidang apa yang telah dimasukkan, yang belum, bidang apa pun yang diperlukan, dll. Ini semua KONTEKS KLIEN, dan tidak boleh dikirim atau dilacak oleh server. Apa yang bisa dikirim ke server adalah set lengkap bidang yang perlu dimodifikasi dalam sumber daya IDENTIFIKASI (oleh URI), sehingga terjadi transisi dalam sumber daya itu dari satu keadaan tenang ke yang lain.

Jadi, klien melacak apa yang dilakukan pengguna, dan hanya mengirim transisi keadaan lengkap yang logis ke server.

Transaksi HTTP, otentikasi akses dasar, tidak cocok untuk RBAC, karena otentikasi akses dasar menggunakan nama pengguna terenkripsi: kata sandi setiap kali mengidentifikasi, sedangkan yang diperlukan dalam RBAC adalah Peran yang ingin digunakan pengguna untuk panggilan tertentu. RBAC tidak memvalidasi izin pada nama pengguna, tetapi pada peran.

Anda bisa tric sekitar untuk menggabungkan seperti ini: usernameRole: password, tetapi ini adalah praktik yang buruk, dan ini juga tidak efisien karena ketika pengguna memiliki lebih banyak peran, mesin otentikasi akan perlu untuk menguji semua peran dalam penggabungan, dan setiap panggilan lagi. Ini akan menghancurkan salah satu keunggulan teknis terbesar RBAC, yaitu uji otorisasi yang sangat cepat.

Sehingga masalah itu tidak bisa diselesaikan menggunakan otentikasi akses dasar.

Untuk mengatasi masalah ini, pemeliharaan sesi diperlukan, dan tampaknya, menurut beberapa jawaban, bertentangan dengan REST.

Itulah yang saya suka tentang jawaban bahwa REST tidak boleh diperlakukan sebagai agama. Dalam kasus-kasus bisnis yang kompleks, dalam perawatan kesehatan, misalnya, RBAC benar-benar umum dan perlu. Sangat disayangkan jika mereka tidak diizinkan menggunakan REST karena semua perancang alat REST akan memperlakukan REST sebagai agama.

Bagi saya tidak ada banyak cara untuk mempertahankan sesi melalui HTTP. Seseorang dapat menggunakan cookie, dengan sessionId, atau header dengan sessionId.

Jika seseorang memiliki ide lain, saya akan senang mendengarnya.

saya pikir token harus menyertakan semua informasi yang diperlukan yang dikodekan di dalamnya, yang membuat otentikasi dengan memvalidasi token dan mendekode info https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

1. Sesi bukanlah tanpa REST
2. Apakah maksud Anda layanan REST hanya untuk penggunaan http atau saya salah bertiga? Sesi berbasis cookie harus digunakan hanya untuk layanan berbasis http sendiri! (Ini bisa menjadi masalah untuk bekerja dengan cookie, misalnya dari Mobile / Console / Desktop / dll.)
3. jika Anda memberikan layanan RESTful untuk pengembang pihak 3d, jangan pernah menggunakan sesi berbasis cookie, gunakan token sebagai gantinya untuk menghindari masalah dengan keamanan.