Kata pengantar
Karena Angular adalah aplikasi satu halaman, sebagian besar sumber daya akan dimuat ke browser sejak awal, jadi Anda perlu lebih memperhatikan waktu verifikasi dan memastikan bahwa hanya pengguna yang telah lulus verifikasi yang dapat melihat antarmuka yang sesuai.
Otentikasi dalam artikel ini mengacu pada bagaimana menentukan apakah pengguna telah masuk dan memastikan bahwa kebutuhan verifikasi server dapat dipenuhi di setiap komunikasi dengan server. Perhatikan bahwa itu tidak termasuk penilaian apakah ada otoritas tertentu.
Untuk login, terutama untuk menerima nama pengguna dan kata sandi pengguna , mengirimkannya ke server untuk verifikasi , memproses respons verifikasi , dan membangun data otentikasi di sisi browser .
Dua cara untuk mengimplementasikan otentikasi identitas
Saat ini, ada dua kategori utama metode untuk mengimplementasikan otentikasi identitas:
Cookie
Halaman web browser tradisional menggunakan cookie untuk memverifikasi identitas. Bahkan, di lapisan aplikasi browser, pada dasarnya tidak perlu khawatir tentang verifikasi identitas. Pengaturan cookie diselesaikan oleh server. Saat mengirimkan permintaan, browser secara otomatis memasang informasi cookie yang sesuai. Oleh karena itu, dalam kode JavaScript, tidak perlu menulis kode khusus untuk ini. Tetapi setiap kali saya meminta, saya akan membawa semua data cookie.
Dengan penerapan CDN dan peningkatan bertahap perangkat seluler, cookie semakin tidak dapat memenuhi kebutuhan otentikasi multi-domain yang kompleks.
Kunci
Faktanya, otentikasi berbasis kunci tidak hanya muncul baru-baru ini, telah ada, bahkan lebih lama dari sejarah cookie. Ketika browser meminta server, ia melampirkan kunci ke permintaan dengan cara tertentu, seperti di header permintaan. Untuk melakukan ini, kode klien khusus harus ditulis untuk manajemen.
Standar Web Key （JSON Web Token） yang baru muncul adalah otentikasi khas menggunakan kunci.
Dalam aplikasi web, jika Anda membangun API, Anda harus memberikan prioritas untuk menggunakan metode utama.
Proses login
Login adalah langkah pertama dalam verifikasi identitas. Hanya dengan masuk dalam dapatkah data verifikasi identitas yang sesuai diatur.
Perlu menggunakan halaman login terpisah?
Ada dua cara untuk menangani halaman login:
Halaman login terpisah akan melompat ke aplikasi satu halaman setelah login selesai. Hal ini memungkinkan kontrol akses sumber daya aplikasi satu halaman untuk mencegah pengguna non-login mengakses, dan cocok untuk skenario aplikasi latar belakang atau alat manajemen. Tetapi sebenarnya mengurangi pengalaman pengguna aplikasi satu halaman
Jalankan login dalam aplikasi satu halaman , yang lebih sesuai dengan konsep desain aplikasi satu halaman dan lebih cocok untuk skenario produk populer, karena orang jahat selalu bisa mendapatkan kode front-end aplikasi satu halaman Anda.
Halaman login terpisah
Secara umum, tujuan menggunakan halaman login terpisah adalah untuk melindungi halaman yang dilompati setelah login dari diakses oleh pengguna anonim. Oleh karena itu, di halaman login, formulir dibangun, dan metode pengiriman pujian tradisional (non-Ajax) digunakan secara langsung. Setelah backend memvalidasi nama pengguna dan kata sandi dengan sukses, HTML dari halaman aplikasi satu sisi setelah login adalah output.
Dalam hal ini, Anda dapat secara langsung menempatkan informasi otentikasi di HTML output, misalnya, Anda dapat menggunakan Jade untuk membuat halaman seperti ini:
<!-dashboard.jade-> doctype htmlhtmlhtml tautan kepala (rel = "stylesheet", href = "/aset/app.e1c2c6ea9350869264da10de799dced1.css") skrip tubuh. window.token =! {json.stringify (token)}; Div.md-Padding (UI-View) Script (src = "/aset/app.84b1e53df1b4b23171da.js")Setelah nama pengguna dan verifikasi kata sandi berhasil, backend dapat menggunakan metode berikut untuk membuat dan mengeluarkan html:
return res.render ('dasbor', {token: token});Setelah aplikasi sudut diluncurkan, ia dapat berkomunikasi dengan otentikasi. Ini juga memastikan bahwa hanya pengguna yang telah berhasil masuk dapat memasukkan halaman ini.
Organisasi yang masuk ke aplikasi satu halaman
Untuk aplikasi sudut multi-view, perutean umumnya digunakan. Di dalam halaman, umumnya ada menu sidebar yang tetap atau menu navigasi atas, dan area teks dikendalikan oleh modul routing.
Kode sampel berikut menggunakan bahan sudut untuk mengatur halaman, dan modul routing menggunakan ui-router. Ketika aplikasi dibuka, ada animasi pemuatan khusus. Setelah pemuatan selesai, halaman yang ditampilkan digunakan oleh pengontrol AppController . Untuk pengguna yang tidak masuk, formulir login akan ditampilkan. Setelah login selesai, halaman dibagi menjadi tiga bagian: satu adalah navigasi remah roti teratas , yang kedua adalah menu sidebar , dan yang lainnya adalah bagian utama dari kontrol rute .
Kodenya adalah sebagai berikut:
<body ng-app = "app" tata letak = "row"> <div id = "loading"> <!-page loading prompt-> </div> <div flex tata letak = "row" ng-cloak ng-controller = "appController" ng-init = "load ()"> <div ng-if = "!,", ",", ",", "! <!-LoginForm-> </div> <div ng-if = "iSuserauth" flex layout = "row"> <md-sidenav flex = "15" md-is locked-open = "true"> <!-menu sidebar-> </md-sidenav> <md-content flex tata letak fleksibel = "colom" role = "Mainbar =" Mainbar = "Mainbar =" Mainbar = "MAIN" MAINANAV> <MD-CONTENT FLEX LAYOUT = "COLUM-" MAIN "MAINBAR =" MAIN "MAINBAR =" MAIN "MDIBAR =" MAiREL-SIDENAV> <MD-SIDENAV> <MD-SIDENAV> </md-toolbar> <md-content> <!-routing-> <v ui-view> </div> </md-content> </md-content> </div> </div> </body>
Untuk memuat animasi, mereka berada di luar AppController dan dapat disembunyikan dalam kode AppController . Ini mencapai tujuan pemuatan menghilang setelah semua CSS/JavaScript dimuat.
Ada variabel di AppController isUserAuth Itu false saat diinisialisasi. Ketika informasi sesi yang disimpan secara lokal valid, atau setelah login selesai, nilai ini akan diatur ke ture . Karena kontrol ng-if , tujuan menyembunyikan formulir login dan menampilkan konten aplikasi dapat dicapai. Perlu dicatat bahwa hanya dengan menggunakan ng-if alih-alih ng-show/ng-hide di sini, yang pertama akan benar-benar menghapus dan menambahkan elemen DOM, sedangkan yang terakhir hanya akan memodifikasi atribut CSS dari elemen DOM. Ini sangat penting. Hanya dengan cara ini kita dapat memastikan bahwa setelah masuk, konten dalam aplikasi satu halaman akan dimuat untuk mencegah kode pengontrol dalam rute saat ini dari dieksekusi langsung sebelum masuk.
Mengapa klien juga mengenkripsi kata sandi
Proses login yang ideal berdasarkan nama pengguna dan kata sandi adalah sebagai berikut:
1. Sisi browser memperoleh kata sandi yang dimasukkan oleh pengguna, menggunakan algoritma hashing seperti MD5 untuk menghasilkan kata sandi baru dengan panjang tetap, seperti md5(username + md5(md5(password))) , dan kemudian mengirimkan nilai kata sandi dan nama pengguna ke backend backend
2. Backend memperoleh garam yang sesuai berdasarkan nama pengguna, menggunakan nama pengguna dan nilai hash kata sandi, menghitung ciphertext, dan mencari database berdasarkan nama pengguna dan kata sandi
3. Jika kueri berhasil, hasilkan kunci, kembalikan ke browser, dan lakukan langkah 4
4. Backend menghasilkan garam baru, dan menghasilkan ciphertext baru berdasarkan garam baru dan nilai hash kata sandi yang dikirimkan oleh browser. Perbarui garam dan ciphertext dalam database
Mungkin 80% orang tidak dapat memahami mengapa login begitu rumit. Ini mungkin memerlukan artikel khusus untuk dijelaskan dengan jelas. Di sini saya akan menjelaskan mengapa browser hash kata sandi, dan alasannya adalah sebagai berikut:
1. Lindungi kata sandi pengguna dari sumber untuk memastikan bahwa hanya dengan melakukan catatan kunci, Anda dapat mendapatkan kata sandi asli pengguna
2. Bahkan jika jaringan menguping dan HTTPS tidak digunakan, kata sandi yang dicuri hanya setelah hashing, yang dapat memengaruhi data pengguna pada server ini paling banyak, dan tidak mempengaruhi situs web lain yang menggunakan kata sandi yang sama.
3. Bahkan pemilik server tidak dapat memperoleh kata sandi asli pengguna.
Pendekatan ini membuat risiko terbesar bagi pengguna, dan data dalam aplikasi saat ini dicuri. Kisaran kerugian tidak akan diperluas, dan tidak akan pernah ada masalah dengan CSDN atau aliran lainnya.
Masuk pemberitahuan yang berhasil
Untuk beberapa aplikasi, tidak semua halaman mengharuskan pengguna untuk masuk. Mereka mungkin hanya perlu masuk saat melakukan operasi tertentu. Dalam hal ini, setelah masuk, seluruh aplikasi harus diberitahu. Ini memungkinkan Anda untuk menggunakan fungsi siaran.
Kode sederhananya adalah sebagai berikut:
Angular .module ('app') .controller ('Logincontroller', ['$ rootscope', logincontroller]); function logincontroller ($ rootscope) {// fungsi yang disebut afterloginsuccess () {$ rootscope. $ siaran ('user.login.suc.suc () {$ rootscope. $ siaran (' user.login.suc.success () {$ rootscope. $ siaran ('user.login.suc.success () {$ rootscope. $ siaran (' user.login.suc.success () {$ rootscope. $ siaran ('user.login.suc.succes }}Di pengontrol lain, Anda dapat mendengarkan siaran ini dan melakukan operasi yang perlu dilakukan setelah login berhasil, seperti mendapatkan daftar atau detail:
$ scope. $ on ('user.login.success', function (handle, data) {// pemrosesan});Informasi otentikasi identitas
Setelah masuk dengan sukses, server mengembalikan kunci, dan permintaan API berikutnya perlu membawa kunci, dan respons yang dikembalikan oleh permintaan juga perlu diperiksa apakah itu kesalahan tentang ketidakabsahan informasi identitas. Rangkaian pekerjaan ini cukup rumit dan harus diselesaikan secara otomatis.
menyimpan
Ada kira -kira cara berikut untuk menyimpan kunci:
1.Cookies: Seperti yang disebutkan sebelumnya, ini tidak disarankan. Pada saat yang sama, ia juga memiliki batas maksimum 4K
2.SessionStorage: Halaman tab valid. Setelah ditutup atau halaman tab baru dibuka, sessionstorage tidak dapat dibagikan.
3.LocalStorage: Metode penyimpanan yang ideal. Kecuali jika data browser dibersihkan, data yang disimpan di LocalStorage akan selalu ada.
4. Layanan Singleton Angular: Jika disimpan dalam aplikasi, data akan hilang setelah menyegarkan, dan tentu saja, itu tidak dapat dibagikan di antara halaman tab.
Pendekatan yang lebih baik adalah bahwa informasi otentikasi disimpan di LocalStorage, tetapi diinisialisasi ke dalam layanan Singleton Angular ketika aplikasi dimulai.
Tambahkan informasi otentikasi ke permintaan
Tujuan dari informasi otentikasi identitas adalah untuk menunjukkan identitas ke server dan mendapatkan data. Oleh karena itu, informasi otentikasi tambahan diperlukan dalam permintaan.
Secara umum, informasi otentikasi ditempatkan di header permintaan. Jika Anda menetapkan header satu per satu di setiap permintaan, itu akan terlalu memakan waktu dan melelahkan. $httpProvider di Angular menyediakan interceptors pencegat di mana pemrosesan terpadu dari setiap permintaan dan respons dapat dicapai.
Cara menambahkan pencegat adalah sebagai berikut:
Angular .module ('app') .config (['$ httpprovider', function ($ httpprovider) {$ httpprovider.interceptors.push (httpinterceptor);}]); Definisi HttpInterceptor adalah sebagai berikut:
Angular .module ('app') .factory ('httpinterceptor', ['$ q', httpinterceptor]); function httpinterceptor ($ q) {return {// sebelum permintaan dikeluarkan, dapat digunakan untuk menambahkan berbagai permintaan informasi autentikasi: function (config) {if (if (if (if (ificorage. } return config; }, // Terjadi kesalahan saat meminta diterbitkan requestError: function (err) {return $ q.Rect (err); }, // Respons Respons: function (res) {return res; }, // Kesalahan respons yang dikembalikan, termasuk ketika backend mengembalikan respons, kode status HTTP non-200 diatur: function (err) {return $ q.Rect (err); }};}Pencegat memberikan pemrosesan siklus hidup penuh dari permintaan ke respons pengembalian, yang umumnya dapat digunakan untuk melakukan hal berikut:
1. Tambahkan data ke permintaan yang dikeluarkan secara seragam, seperti menambahkan informasi otentikasi
2. Penanganan kesalahan terpadu, termasuk kesalahan saat permintaan dikeluarkan (seperti jaringan di sisi browser tidak terhubung), dan kesalahan ketika respons dikembalikan
3. Pemrosesan respons terpadu, seperti cache beberapa data, dll.
4. Tampilkan Bilah Kemajuan Permintaan
Dalam kode contoh di atas, ketika localStorage menyertakan token nilai, nilai token ditambahkan di kepala setiap permintaan.
Kegagalan dan penanganan
Secara umum, backend harus menetapkan kode status http respons ke 401 ketika verifikasi token gagal, sehingga dapat ditangani secara seragam di responseError interceptor:
ResponseError: function (err) {if (-1 === err.status) {// Server jarak jauh tidak responsif} lain jika (401 === err.status) {// Kesalahan 401 umumnya digunakan untuk kegagalan otentikasi. Itu tergantung pada kesalahan yang dilemparkan oleh backend ketika otentikasi gagal} lain jika (404 === err.status) {// server mengembalikan 404} mengembalikan $ q.rect (err);}Meringkaskan
Bahkan, selama kode status yang dikembalikan oleh server tidak 200, responseError akan dipanggil. Di sini, kesalahan dapat ditangani secara seragam dan ditampilkan.
Konten di atas terkait dengan login dan verifikasi identitas dalam aplikasi pengembangan sudut. Saya harap ini akan membantu semua orang untuk belajar Angular.