Apakah sesi benar-benar melanggar RESTfulness?


491

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 ?


5
Saya telah membahas masalah yang sebenarnya di sini: stackoverflow.com/questions/1296421/rest-complex-applications/…
Will Hartung

5
Untuk menambah itu, jika Anda hanya menggunakan sesi untuk otentikasi, lalu mengapa tidak menggunakan header yang disediakan? Jika tidak, dan Anda menggunakan sesi untuk keadaan percakapan lainnya, maka itu melanggar batasan Stateless REST.
Will Hartung

2
@Terima kasih. Sepertinya Anda sedang berbicara tentang sesi untuk menyimpan sementara data yang dikirimkan pengguna, sementara dalam kasus saya, saya hanya membicarakannya sebagai detail implementasi untuk otentikasi. Mungkinkah ini dari mana perselisihan itu berasal?
tipuan

3
@ menerima satu-satunya poin saya adalah bahwa jika Anda akan menggunakan header untuk mewakili token otentikasi, HTTP menyediakan satu di luar cookie umum. Jadi, mengapa tidak menggunakannya dan simpan semantik gratis yang Anda dapatkan (siapa pun yang melihat payload dapat melihat ada token otentikasi yang ditetapkan untuknya).
Will Hartung

7
Tentu, tetapi mengapa tidak membuat header Anda sendiri, atau membajak beberapa header lainnya untuk token auth. Gunakan tajuk X-XYZZY. Itu hanya sintaks, kan? Header menyampaikan informasi. Header Otorisasi lebih "mendokumentasikan diri sendiri" daripada cookie Anda, karena "semua orang" tahu untuk apa header Auth. Jika mereka hanya melihat JSESSIONID (atau apa pun), mereka tidak dapat membuat asumsi, atau lebih buruk, membuat asumsi yang salah (apa lagi yang ia simpan dalam sesi, apa lagi yang digunakan untuk ini, dll). Apakah Anda menyebutkan variabel Anda dalam kode Aq12hsg? Tidak, tentu saja tidak. Hal yang sama berlaku di sini.
Will Hartung

Jawaban:


299

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

  • 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

  • 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.


5
Ya, Anda sepenuhnya benar. Karena saya telah mengirimkan pertanyaan ini, saya benar-benar datang untuk melihatnya. Cookie sesi bukanlah sesuatu yang istimewa ketika dilihat dalam detail teknis, tetapi itu menghilangkan hutan untuk pepohonan. Terima jawaban Anda karena grafik yang bagus. ;)
deceze

1
Ok, saya pikir ulang, respon dari layanan REST tidak boleh tergantung pada otorisasi, jadi saya pikir 2 solusi pertama adalah 100% oke, dan yang lain baik-baik saja jika layanan menggunakan informasi hanya untuk memutuskan apakah itu memungkinkan permintaan atau tidak. Jadi saya pikir izin pengguna harus berpengaruh pada representasi sumber daya saat ini.
inf3rno

1
Saya akan membuat pertanyaan tentang ketergantungan pada representasi. Saya akan memperpanjang jawaban ini segera setelah saya mendapatkan solusi yang tepat.
inf3rno

3
@ inf3rno, memang benar bahwa layanan sepenuhnya TENANG tidak dapat bergantung pada cookie sesi untuk otentikasi dengan cara yang secara tradisional diterapkan. Namun, Anda dapat menggunakan cookie untuk melakukan otentikasi jika cookie tersebut berisi semua informasi keadaan yang nantinya diperlukan oleh server. Anda juga dapat membuat cookie aman dari gangguan dengan menandatanganinya dengan pasangan kunci publik / pribadi. Lihat komentar saya di bawah ini.
jcoffland

3
Saya tidak mengerti mengapa semua orang tampaknya menerima komentar Anda harus menyimpan kata sandi di sisi klien dan mengirimkannya dengan setiap permintaan. Ini adalah praktik yang sangat buruk dan membahayakan data sensitif pelanggan Anda. Kata sandi yang tidak rusak (yang harus dikirim berulang kali) tidak boleh disimpan di mana pun. Jika kami menerima ini maka Anda menggunakan token seperti yang dilakukan sebagian besar sistem otentikasi, dalam hal apa pun mekanisme yang kami gunakan untuk skala repositori token sebagian besar akan memiliki masalah skalabilitas yang sama dengan skalabilitas sesi apa pun.
lvoelk

334

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.


6
Saya akan ulangi pernyataan awal Anda. Hanya gunakan REST jika batasan REST masuk akal untuk aplikasi Anda. Anda bebas menerapkan sebagian kendala tersebut dan Anda akan mendapatkan sebagian manfaatnya. Namun, pada saat itu Anda telah menciptakan gaya arsitektur Anda sendiri. Itu bukan hal yang buruk, pada kenyataannya itulah empat bab pertama disertasi Roy tentang, desain berprinsip. REST hanyalah satu contoh.
Darrel Miller

4
@ Darrel Poin yang cukup adil. Sejujurnya saya tidak yakin bagaimana Google melakukannya, tetapi waktu kedaluwarsa dapat disandikan ke dalam token otentikasi. Saya percaya poin saya yang lebih besar masih berdiri. Ada beberapa jenis kondisi yang harus dipertahankan dan selama Anda memahami mengapa REST membutuhkan kewarganegaraan, Anda dapat melanggarnya dengan cara yang masuk akal tanpa banyak dampak pada sisa sistem dan keuntungan dari arsitektur tenang. .
Jared Harding

7
Karena tidak ada argumen lain yang dibuat sejauh ini, saya menerima tanggapan yang ditulis dengan baik ini. Saya pikir yang penting adalah bahwa server stateless bukan berarti server stateless , sesuatu yang saya pikir sering disalahpahami atau salah diterapkan. Server dapat (dan biasanya harus ) memiliki status apa pun yang diinginkan, asalkan berperilaku idempoten .
tipuan

10
Saya telah mendengar banyak khotbah sehingga sesi tidak tenang. Otentikasi dasar HTTP adalah langkah mundur yang nyata jika Anda mencoba membuat aplikasi web.
Ben Thurley

1
@Micah Henning, Anda membuat asumsi yang salah bahwa server memerlukan informasi status untuk memvalidasi token otentikasi. Kami dapat berasumsi bahwa Anda tidak dapat memalsukan token yang ditandatangani oleh pasangan kunci publik / pribadi jika Anda tidak tahu kunci privat. Untuk memverifikasi token itu valid semua yang Anda butuhkan adalah kunci publik. Saya masih berpendapat bahwa autentikasi sepenuhnya ISTIRAH mungkin dilakukan.
jcoffland

12

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.


1
Sementara itu, saya juga lebih sering datang ke sudut pandang ini. Saya memang berpikir bahwa secara teknis itu membuat sedikit perbedaan, itu semua hanya header HTTP. Memang benar bahwa perilaku otentikasi itu sendiri tidak tenang, jika perlu login melalui alamat terpisah. Jadi cookie hanya merupakan gejala dari masalah yang lebih besar dengan sistem otentikasi.
tipuan

Ini tidak benar-benar menjelaskan fakta bahwa browser web hanya mendukung Authorization: Basicatau Digest. Jika Anda ingin melakukan sesuatu yang lebih maju daripada dasar atau mencerna auth (dan Anda harus) dalam konteks browser, maka Anda akan memerlukan sesuatu selain Authorizationheader.
Oliver Charlesworth

1
Tentu saja - jika Anda melakukan JS murni maka semuanya pada dasarnya OK (kecuali, misalnya, Websockets). Tetapi poin saya adalah bahwa auth berbasis API tidak selalu menjadi satu-satunya pertimbangan dalam skenario browser.
Oliver Charlesworth

5
GET /atanpa cookie dan dengan cookie jelas dua permintaan yang berbeda , dan itu dapat diterima bagi mereka untuk berperilaku berbeda.
TRiG

1
Untuk menambahkan ke @TRiG, ​​mengikuti logika ini, GET /adengan header otentikasi juga sama dengan GET /atanpa header otentikasi, sehingga sama-sama tidak dapat digunakan untuk REST. Jika Anda akan memperlakukan satu tajuk http secara berbeda dari tajuk lainnya, Anda akan mengatasinya paling tidak.
Jasper

7

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.


3
Saya tidak melihat bagaimana ini menjelaskan pertanyaan yang diajukan.
jcoffland

1

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.



-4
  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.

3
cookie tidak boleh digunakan untuk menyimpan kunci sesi untuk sesi di server yang menyimpan token otentikasi. tetapi jika cookie itu menyimpan token otentikasi itu sendiri itu adalah solusi yang layak. (tentu saja cookie harus httponly dan diamankan)
roberkules
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.