Artikel yang menerangkan secara terperinci cara melaksanakan pengesahan perkhidmatan mikro

Artikel ini membawakan anda pengetahuan yang berkaitan tentang pengesahan terutamanya memperkenalkan idea pelaksanaan pengesahan dalam perkhidmatan mikro. Adakah terdapat penyelesaian yang baik untuk mencapai ini? Mari kita lihat bersama-sama, saya harap ia akan membantu semua orang.

Sesetengah rakan baru sahaja bertanya soalan ini di WeChat, jadi saya datang untuk bersembang dengan anda Artikel ini terutamanya bercakap tentang idea dengan rakan, tanpa menulis kod saya artikel dan sepatutnya boleh menulis kod artikel ini sendiri. Sudah tentu, idea itu hanyalah pengalaman praktikal saya sendiri dan mungkin bukan penyelesaian yang paling sempurna. Rakan dialu-alukan untuk membincangkannya dalam komen.

1. Pengesahan dan kebenaran

Pertama sekali, rakan-rakan tahu bahawa tidak kira sama ada kita belajar Shiro atau Spring Security, tidak kira apa fungsi yang ada, terdapat dua teras:

• Pengesahan

• Keizinan

Jadi, kami mengendalikan isu pengesahan dalam perkhidmatan mikro, dan kami juga boleh menggunakan kedua-dua ini aspek yang perlu dipertimbangkan.

1.1 Pengesahan

Pengesahan, secara terang-terangan, bermaksud log masuk. Log masuk Web tradisional ialah penyelesaian Cookie+Session, yang bergantung pada memori tempatan pelayan Dalam perkhidmatan mikro, kerana bilangan perkhidmatan yang banyak, penyelesaian ini jelas tidak sesuai lagi.

Sesetengah rakan mungkin berkata untuk menggunakan Redis+SpringSession untuk perkongsian sesi Ini adalah satu cara, tetapi ia bukan penyelesaian terbaik kerana prestasi dan kebolehskalaan penyelesaian ini agak lemah.

Oleh itu, adalah disyorkan untuk menggunakan token untuk pengesahan dalam perkhidmatan mikro Anda boleh memilih token JWT, yang juga merupakan penyelesaian yang biasa digunakan pada masa ini. Walau bagaimanapun, rakan-rakan yang biasa dengan JWT tahu bahawa log masuk tanpa kewarganegaraan tulen tidak dapat mencapai log keluar, yang sangat menyusahkan, oleh itu, dalam aplikasi praktikal, hanya menggunakan JWT Secara amnya, adalah perlu untuk menggabungkannya dengan Redis untuk menukar JWT yang dihasilkan aksara. Rentetan juga disimpan pada Redis dan masa tamat tempoh ditetapkan Apabila menentukan sama ada pengguna log masuk, anda perlu menyemak sama ada rentetan JWT wujud pada Redis, kemudian menghuraikan rentetan JWT boleh dihuraikan dengan jayanya, tidak akan ada Masalah, jika tidak dapat dihuraikan dengan jayanya, bermakna token itu haram.

Cara mencampurkan log masuk stateful + log masuk tanpa state ini mungkin kelihatan agak tidak jelas, tetapi buat masa ini, kaedah kompromi ini dianggap sebagai penyelesaian yang boleh dilaksanakan.

Sebenarnya, penyelesaian di atas, secara terang-terangan, tidak berbeza dengan Cookie+Sesi tradisional pelayan dan penyemak imbas JsessionId antara pelayan digantikan dengan rentetan JWT Id tradisional dihantar melalui Cookie, dan JWT semasa dihantar melalui pengepala permintaan selepas ditetapkan secara manual oleh pembangun boleh diperbaharui secara automatik; tetapi kini JWT digunakan untuk memperbaharui secara manual Setiap kali permintaan sampai ke pelayan, semak masa tamat tempoh token pada Redis.

Ini adalah pilihan skim pengesahan.

1.2 Keizinan

Keizinan dalam perkhidmatan mikro juga boleh dilakukan menggunakan rangka kerja Shiro atau Spring Security, yang menjimatkan masalah. Memandangkan tindanan teknologi perkhidmatan mikro ialah produk keluarga Spring, disyorkan agar semua orang memilih Spring Security terlebih dahulu dari segi rangka kerja kebenaran (jika ada rakan yang tidak biasa dengan Spring Security, anda boleh membalas ss di latar belakang WeChat akaun rasmi, ada tutorial) .

Sudah tentu, jika anda rasa Spring Security lebih rumit dan ingin melakukannya sendiri, anda boleh. Jika anda melakukannya sendiri, anda juga boleh menggunakan idea Spring Security Salah satu projek terbaru Song Ge adalah seperti ini:

Selepas permintaan sampai ke perkhidmatan mikro, mula-mula cari pelbagai maklumat. tentang pengguna semasa, termasuk pengguna semasa Maklumat seperti peranan dan kebenaran yang dimiliki kemudian disimpan dalam objek ThreadLocal yang terikat pada urutan semasa. Sebaliknya, sesuaikan anotasi kebenaran dan anotasi peranan, huraikan anotasi ini dalam aspek dan semak sama ada pengguna semasa mempunyai peranan/keizinan yang diperlukan, dsb.

Sudah tentu, jika anda menggunakan Spring Security, anda tidak memerlukan anotasi tersuai untuk perkara di atas Anda hanya boleh menggunakan yang disertakan dengan Spring Security, dan anda juga boleh mengalami lebih banyak pengalaman dalam Spring Ciri keselamatan.

2. Perkhidmatan pengesahan

Jadi di manakah pengesahan dan kebenaran dilakukan?

Mari bincang tentang pengesahan dahulu boleh dibahagikan kepada dua langkah mudah:

• Log Masuk

• Pengesahan

2.1 Log Masuk

Secara umumnya, kami boleh melakukan perkhidmatan pengesahan berasingan untuk log masuk. Apabila permintaan log masuk mencapai gerbang, kami memajukannya kepada perkhidmatan pengesahan untuk menyelesaikan operasi pengesahan.

Dalam perkhidmatan pengesahan, kami menyemak sama ada nama pengguna/kata laluan OK dan sama ada status pengguna OK Jika tiada masalah, jana rentetan JWT dan pada masa yang sama simpan data ke dalam Redis , dan kemudian rentetan JWT dikembalikan.

Jika sistem mempunyai fungsi pendaftaran, fungsi pendaftaran juga akan dilengkapkan pada perkhidmatan mikro ini.

2.2 Pengesahan

Pengesahan merujuk kepada pengesahan sama ada pengguna telah log masuk apabila setiap permintaan tiba.

Sudah tentu ini boleh dilakukan bersama-sama dengan 2.1, tetapi Brother Song tidak mengesyorkannya. Masalahnya ialah jika ia adalah permintaan untuk membuat pesanan, permintaan ini pada asalnya dimajukan kepada perkhidmatan pesanan melalui gerbang Walau bagaimanapun, pada masa ini, perkhidmatan dalam Bahagian 2.1 mesti dipanggil pada gerbang untuk pengesahan log masuk tiada masalah, ia akan dimajukan kepada Dari segi perkhidmatan pesanan, ini jelas sangat memakan masa dan tidak munasabah.

Cara yang lebih baik ialah dengan mengesahkan secara langsung sama ada token yang diminta adalah sah pada gerbang Pengesahan ini sendiri juga agak mudah untuk mengesahkan sama ada token itu sah, kami hanya perlu menyemak sama ada token itu wujud pada Redis . Selagi token JWT berjaya dihuraikan, operasi ini boleh dilakukan pada gerbang.

Mengambil Gerbang sebagai contoh, kami boleh menyesuaikan penapis global dan mengesahkan token setiap permintaan dalam penapis global Jika pengesahan lulus, permintaan akan dimajukan, jika tidak, permintaan itu tidak akan dimajukan.

Selepas lulus pengesahan dan pemajuan kepada perkhidmatan mikro tertentu, kami boleh meletakkan ID pengguna dan nama pengguna yang dihuraikan dan maklumat lain ke dalam pengepala permintaan, dan kemudian memajukannya untuk mencapai setiap perkhidmatan mikro tertentu Selepas itu, anda akan ketahui siapa yang menghantar permintaan dan peranan/keizinan yang dimiliki oleh orang ini, supaya anda boleh melakukan langkah pengesahan kebenaran yang seterusnya.

Pendekatan Songge adalah untuk mentakrifkan modul awam Semua perkhidmatan mikro bergantung pada modul awam ini mentakrifkan pemintas yang akan memintas setiap permintaan Dari pengepala permintaan Dapatkan ID pengguna daripada Redis kemudian dapatkan maklumat pengguna khusus daripada Redis dan simpannya dalam ThreadLocal Dengan cara ini, dalam panggilan kaedah berikutnya, jika anda perlu menentukan sama ada pengguna mempunyai kebenaran tertentu, anda boleh mendapatkannya melalui ThreadLocal.

Ini kira-kira proses sedemikian.

3. Perkhidmatan kebenaran

Keizinan tidak boleh dilakukan pada gerbang, ia masih perlu dilakukan pada setiap perkhidmatan mikro.

Kami secara kasar boleh membahagikan kebenaran pada perkhidmatan mikro kepada dua kategori:

• Permintaan dihantar oleh bahagian hadapan (permintaan luaran).

• Permintaan dihantar daripada perkhidmatan mikro lain (permintaan dalaman).

3.1 Permintaan luaran

Untuk permintaan luaran, hanya layan mereka mengikut pengesahan kebenaran biasa, anotasi tersuai atau menggunakan rangka kerja seperti Spring Security Ya, jika ia adalah a anotasi tersuai, anda boleh menggabungkannya dengan AOP untuk menentukan aspek untuk mengendalikan anotasi kebenaran sendiri Sudah tentu, fungsi ini pada asasnya diperlukan oleh setiap perkhidmatan mikro, supaya ia boleh diekstrak ke dalam modul awam. Hanya bergantung padanya dalam perkhidmatan mikro yang berbeza.

3.2 Permintaan Dalaman

Untuk permintaan dalaman, pengesahan biasanya tidak diperlukan dan permintaan dalaman boleh diproses secara langsung. Masalahnya ialah jika OpenFeign digunakan, data didedahkan melalui antara muka Tanpa pengesahan, kami akan bimbang tentang permintaan luaran yang memanggil antara muka ini, kami juga boleh menyesuaikan anotasi + AOP, dan kemudian meminta secara dalaman. tambah medan pengepala tambahan untuk membezakannya.

Sudah tentu, apabila permintaan dalaman tiba di perkhidmatan mikro, ia juga perlu disahkan, sama seperti apabila permintaan dimajukan dari gerbang ke setiap perkhidmatan mikro tertentu, pengesahan diperlukan, tetapi jelas sekali, kita tidak perlu gunakannya setiap kali Apabila OpenFeign memanggil perkhidmatan lain, ia menghantar sekumpulan maklumat pengesahan Kami boleh mentakrifkan pemintas permintaan OpenFeign dengan melaksanakan antara muka feign.RequestInterceptor Dalam pemintas, maklumat pengepala permintaan ditetapkan secara seragam untuk permintaan OpenFeign.

Baiklah, mengenai pengesahan dalam perkhidmatan mikro, ini adalah cara kami melakukannya pada masa ini Rakan-rakan dialu-alukan untuk meninggalkan mesej dan membincangkannya bersama.

Pembelajaran yang disyorkan: "Tutorial Video Program Mini" "Tutorial Video Java"

Atas ialah kandungan terperinci Artikel yang menerangkan secara terperinci cara melaksanakan pengesahan perkhidmatan mikro. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!