Pertanyaan Bagaimana saya mengimplementasikan login dalam layanan web yang tenang?


Saya sedang membangun aplikasi web dengan lapisan layanan. Lapisan layanan akan dibangun menggunakan desain RESTful. Pemikirannya adalah bahwa suatu saat di masa depan kita dapat membangun aplikasi lain (iPhone, Android, dll.) Yang menggunakan lapisan layanan yang sama dengan aplikasi web. Pertanyaan saya adalah ini - bagaimana saya mengimplementasikan login? Saya pikir saya mengalami kesulitan pindah dari desain berbasis kata kerja yang lebih tradisional ke desain berbasis sumber daya. Jika saya membangun ini dengan SOAP saya mungkin akan memiliki metode yang disebut Login. Dalam REST saya harus memiliki sumber daya. Saya mengalami kesulitan memahami bagaimana saya harus membuat URI saya untuk login. Seharusnya seperti ini:

http: // myservice /{username}? p = {password}

EDIT: Aplikasi web ujung depan menggunakan kerangka ASP.NET tradisional untuk otentikasi. Namun pada beberapa titik dalam proses otentikasi saya perlu memvalidasi kredensial yang disediakan. Dalam aplikasi web tradisional saya akan melakukan pencarian basis data. Tetapi dalam skenario ini saya memanggil layanan daripada melakukan pencarian basis data. Jadi saya butuh sesuatu di layanan yang akan memvalidasi kredensial yang disediakan. Dan selain memvalidasi kredensial yang disediakan saya mungkin juga memerlukan beberapa jenis informasi tentang pengguna setelah mereka berhasil diautentikasi - hal-hal seperti nama lengkap mereka, ID mereka, dll. Saya harap ini membuat pertanyaan lebih jelas.

Atau saya tidak memikirkan hal ini dengan cara yang benar? Saya merasa sulit untuk menjelaskan pertanyaan saya dengan benar.

Corey


76
2018-01-05 19:13


asal


Jawaban:


Seperti yang ditunjukkan S.Lott, ada dua hal yang terlipat di sini: Login dan otentikasi

Otentikasi berada di luar lingkup di sini, karena ini banyak dibahas dan ada kesepakatan bersama. Namun, apa yang sebenarnya kita butuhkan untuk klien berhasil mengotentikasi dirinya terhadap layanan web yang TEPAT? Benar, semacam token, sebut saja token akses.

Klien) Jadi, yang saya butuhkan hanyalah akses-token, tetapi bagaimana cara mendapatkan RESTfully seperti itu?
Server) Mengapa tidak menciptakannya begitu saja?
Klien) Bagaimana caranya?
Server) Bagi saya akses-token tidak lain adalah sumber daya. Dengan demikian, saya akan membuatkan satu untuk Anda sebagai ganti nama pengguna dan kata sandi Anda.

Dengan demikian, server dapat menawarkan URL sumber daya "/ accesstokens", untuk mem-posting nama pengguna dan kata sandi ke, mengembalikan tautan ke sumber daya yang baru dibuat "/ accesstokens / {accesstoken}". Sebagai alternatif, Anda mengembalikan dokumen yang berisi token akses dan href dengan tautan sumber daya:

<token akses
  id = "{access token id masuk di sini; mis. GUID}"
  href = "/ accesstokens / {id}"
/>

Kemungkinan besar, Anda tidak benar-benar membuat akses-token sebagai subresource dan dengan demikian, tidak akan menyertakan tanggapannya.
Namun, jika Anda melakukannya, klien dapat menghasilkan tautan atas namanya atau tidak? Tidak!
Ingat, layanan tautan web layanan yang benar-benar TEPAT bersama-sama dengan cara yang dapat ditelusuri oleh klien tanpa perlu membuat tautan sumber daya apa pun.

Pertanyaan terakhir yang mungkin Anda miliki adalah apakah Anda harus POST nama pengguna dan kata sandi sebagai bentuk HTML atau sebagai dokumen, mis. XML atau JSON - itu tergantung ... :-)


56
2018-01-17 09:55



Anda tidak "masuk". Anda "mengotentikasi". Dunia yang berbeda.

Anda memiliki banyak alternatif otentikasi.

Autentikasi HTTP Basic, Digest, NTLM, dan AWS S3

  • Otentikasi HTTP Dasar dan Intest. Ini menggunakan HTTP_AUTHORIZATION tajuk. Ini sangat bagus, sangat sederhana. Tetapi dapat menyebabkan banyak lalu lintas.

  • Otentikasi Nama Pengguna / Tanda Tangan. Terkadang disebut "ID dan KEY" otentikasi. Ini bisa menggunakan string kueri.

    ?username=this&signature=some-big-hex-digest 

    Ini adalah tempat-tempat seperti yang digunakan Amazon. Nama pengguna adalah "id". "Kunci" adalah intisari, mirip dengan yang digunakan untuk otentikasi HTTP Digest. Kedua belah pihak harus menyetujui intisari untuk melanjutkan.

  • Beberapa jenis otentikasi berbasis cookie. OpenAM, misalnya, dapat dikonfigurasi sebagai agen untuk mengotentikasi dan menyediakan cookie yang dapat digunakan oleh server web Anda yang TEPAT. Klien akan mengotentikasi terlebih dahulu, dan kemudian memberikan cookie dengan setiap permintaan RESTful.


23
2018-01-05 19:22



Pertanyaan bagus, berpose bagus. Saya sangat suka jawaban Patrick. Saya menggunakan sesuatu seperti

- / users / {username} / loginsession

Dengan POST dan GET yang ditangani. Jadi saya memposting sesi login baru dengan kredensial dan saya kemudian dapat melihat sesi saat ini sebagai sumber daya melalui GET.

Sumber daya adalah sesi masuk, dan yang mungkin memiliki token akses atau kode auth, kedaluwarsa, dll.

Anehnya, pemanggil MVC saya sendiri harus menyajikan token kunci / pembawa melalui header untuk membuktikan bahwa ia memiliki hak untuk mencoba dan membuat sesi login baru karena situs MVC adalah klien dari API.

Edit

Saya pikir beberapa jawaban dan komentar lain di sini adalah memecahkan masalah dengan rahasia bersama di luar band dan hanya mengautentikasi dengan header. Itu bagus dalam banyak situasi atau untuk panggilan layanan-ke-layanan.

Solusi lain adalah untuk mengalirkan token, OAuth atau JWT atau yang lain, yang berarti "login" telah dilakukan oleh proses lain, mungkin UI login normal di browser yang didasarkan pada bentuk POST.

Jawaban saya adalah untuk layanan yang berada di belakang UI itu, dengan asumsi Anda ingin login dan auth dan manajemen pengguna ditempatkan dalam layanan REST dan tidak di kode MVC situs. Ini adalah layanan login pengguna.

Ini juga memungkinkan layanan lain untuk "masuk" dan mendapatkan token yang kedaluwarsa, daripada menggunakan kunci yang dibagikan sebelumnya, serta menguji skrip dalam CLI atau Postman.


1
2018-06-05 19:35



Sejak sedikit berubah sejak 2011 ...

Jika Anda terbuka untuk menggunakan alat pihak ke-3, dan sedikit menyimpang dari REST sedikit untuk UI web, pertimbangkan http://shiro.apache.org.

Shiro pada dasarnya memberi Anda filter servlet bertujuan untuk otentikasi serta otorisasi. Anda dapat menggunakan semua metode login yang terdaftar oleh @ S.Lott, termasuk otentikasi berbasis formasi sederhana.

Filter sisa URL yang memerlukan otentikasi, dan Shiro akan melakukan sisanya.

Saya saat ini menggunakan ini dalam proyek saya sendiri dan itu telah bekerja cukup baik bagi saya sejauh ini.

Inilah hal lain yang mungkin diminati orang. https://github.com/PE-INTERNATIONAL/shiro-jersey#readme


0
2018-06-12 15:46



Hal pertama yang harus dipahami tentang REST adalah bahwa akses sumber daya berbasis Token. Tidak seperti cara tradisional, akses diberikan berdasarkan validasi token. Dengan kata sederhana jika Anda memiliki hak token, Anda dapat mengakses sumber daya. Sekarang ada banyak hal lain untuk pembuatan dan manipulasi token.

Untuk pertanyaan pertama Anda, Anda dapat mendesain API Restfull. Kredensial (Nama pengguna dan kata sandi) akan diteruskan ke lapisan layanan Anda. Lapisan layanan kemudian memvalidasi kredensial ini dan memberikan token. Kredensial dapat berupa nama pengguna / kata sandi sederhana atau dapat berupa sertifikat SSL. Sertifikat SSL menggunakan protokol OAUTH dan lebih aman.

Anda dapat mendesain URI seperti ini- URI untuk permintaan token-> http: // myservice / beberapa direktori / token? (Anda dapat lulus Credentilals di URI ini untuk Token)

Untuk menggunakan token ini untuk akses sumber daya, Anda dapat menambahkan ini [Otorisasi: Pembawa (token)] ke header http Anda.

Token ini dapat digunakan oleh pelanggan untuk mengakses berbagai komponen lapisan layanan Anda. Anda juga dapat mengubah periode kedaluwarsa token ini untuk mencegah penyalahgunaan.

Untuk pertanyaan kedua Anda, satu hal yang dapat Anda lakukan adalah memberikan token yang berbeda untuk mengakses komponen sumber daya yang berbeda dari lapisan layanan Anda. Untuk ini, Anda dapat menentukan parameter sumber daya di token Anda, dan izin besar berdasarkan bidang ini.

Anda juga dapat mengikuti tautan ini untuk informasi lebih lanjut- http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api


0
2018-02-25 10:06



Saya menghadapi masalah yang sama sebelumnya. Login tidak diterjemahkan dengan baik ke desain berbasis sumber daya.

Cara saya biasanya mengatasinya adalah dengan memiliki sumber daya Login dan melewati username dan kata sandi pada parameter string, pada dasarnya lakukan

Mendapatkan http: // myservice / login? u ={username} & p = {password}

Responsnya adalah semacam sesi atau string autentikasi yang kemudian dapat diteruskan ke API lain untuk validasi.

Sebuah alternatif untuk melakukan GET pada sumber daya login adalah melakukan POST, REST puritan mungkin tidak akan menyukai saya sekarang :), dan meneruskan kredibilitas dalam tubuh. Tanggapannya akan sama.


-4
2018-01-05 19:18