Pada asasnya, bahagian hadapan menyulitkan data untuk mengurangkan kebolehbacaan, seperti data sensitif pengguna, untuk tujuan perlindungan privasi. Jika anda lulus seesion_id, tidak perlu menyulitkannya. Bagi kaedah md5 yang disebutkan di atas, ia adalah salah (untuk lulus seesion_id), kerana seesion_id itu sendiri digunakan sebagai kunci, dan md5 ialah kaedah hash (tidak boleh dipulihkan jika bahagian belakang ingin menggunakannya, ia boleh digunakan secara langsung). . Datang dan gunakannya, lapisan md5 anda tidak bermakna (jika ia dirampas, gunakannya terus)

Isu token yang anda nyatakan terletak pada cara bahagian belakang melaksanakan bahagian pengesahan, sama ada untuk memulihkan sesi untuk menyimpan maklumat atau menggunakan token untuk mengesahkan kuasa panggilan antara muka. Ia berbeza-beza bergantung pada cara bahagian belakang dilaksanakan.

Sesi disimpan oleh kuki yang diletakkan dalam penyemak imbas, dan bergantung pada masa tamat tempoh kuki penyemak imbas untuk mengawal masa pengekalan log masuk (perspektif pelanggan).

Untuk kandungan yang lain, sila rujuk kuki vs token sesi ini

Sulitkan beberapa lapisan lagi, md5 terlalu mudah.

Token, anda hanya boleh mempunyai tarikh yang disulitkan MD5 semasa log masuk, kemudian masukkannya ke dalam redis, dan kemudian sekatnya dalam pemintas untuk membuat pertimbangan

Selagi tiada kandungan sensitif (kata laluan, dll.) disimpan, tiada masalah untuk saya. Adalah disyorkan untuk menggunakan jwt yang popular Terdapat perpustakaan yang dilaksanakan dalam pelbagai bahasa, dan ia sangat mudah digunakan.

Id sesi hanyalah tanda, dan md5 adalah berlebihan.

sessionid Bukankah ia adalah token teks biasa yang disulitkan?

Sangat baik, gunakan jwt. Beri perhatian untuk mengesahkan kesahihan token.