Saya sedang memikirkan rancangan, tetapi saya tidak tahu sama ada terdapat rancangan matang yang serupa.
1. Pengesahan pertama pengguna
2 Buat fail bernama dengan nilai token dalam direktori token yang ditentukan
3 Kembalikan token kepada pengguna untuk disimpan
4 404 Tamat: pemprosesan logik dengan menilai sama ada fail itu wujud.
Tetapan keselamatan yang terlintas di fikiran adalah untuk melarang perangkak daripada merangkak direktori, dan memantau bilangan sambungan pengguna ke direktori untuk mengelakkan peretasan kekerasan
Adakah terdapat sebarang pepijat atau masalah prestasi dengan kaedah ini
Atau adakah a penyelesaian yang lebih baik daripada ini
Untuk penyelesaian ini, sila lihat jawapan saya yang lain: /q/10...
Walaupun penyelesaian ini tidak dianggap sebagai standard, ia adalah penyelesaian yang biasa digunakan.
Masih terdapat beberapa kekurangan, seperti:
Jika token yang dijana terlalu panjang, anda mesti mempertimbangkan sama ada ia melebihi had panjang permintaan GET semasa melakukan GET (kerana panjang URL adalah terhad), tetapi token yang terlalu pendek tidak dapat memastikan keunikan dan keselamatan yang tinggi
Sudah tentu, menggunakan token sebagai token pengguna adalah tidak selamat. Jika token dicuri oleh orang lain sebelum token tamat tempoh, orang lain boleh menyamar sebagai pengguna dan melakukan operasi tanpa log masuk.
Jika anda mahukan kaedah yang lebih selamat, ia adalah dengan menggunakan pelayan Sesi untuk mengesahkan pengguna Namun, isu silang domain Sesi sememangnya isu biasa, dan tiada masalah dengan token silang domain antara muka boleh diakses, token meminta diluluskan dalam data. Jadi pandangan peribadi saya ialah satu-satunya pilihan adalah antara keselamatan dan kemudahan penggunaan. Sudah tentu, kaedah pengesahan lain juga boleh digunakan, seperti JWT, dsb., tetapi kaedah ini lebih menyusahkan (melainkan anda tidak perlu mencipta semula roda).
1. Pelanggan menyerahkan maklumat
2. Pelayan menyemak ketepatan maklumat Jika log masuk tidak sah, log masuk gagal
3 pangkalan data seperti redis, dan menetapkan masa tamat tempoh
4. Pelayan mengembalikan token kepada pelanggan
5. Pelanggan menyimpan token
6. Kali seterusnya pelanggan meminta, ia membawa token itu token itu jika sah, ia lulus, jika ia tidak sah, pengesahan gagal