Dalam dua hari terakhir, karena saya menggunakan Ajax di ujung depan untuk memulai permintaan pembaruan asinkron, saya menemukan bahwa Ajax akan mengekspos alamat antarmuka backend. Tentu saja, masalah ini tidak bisa dihindari, dan ujung depan adalah teks biasa. Sayangnya, saya mengajukan berbagai pertanyaan di grup Baidu, Google, dan QQ. Mereka semua mengatakan bahwa masalahnya hanya dapat diselesaikan melalui verifikasi keamanan. Sebagai seorang pemula, pilihan pertama adalah sesi tentu saja. Ada verifikasi token, kerangka kerja shrio, dll. Online. Teman yang tertarik dapat mencari tutorial online untuk dipelajari.
Sesi adalah mekanisme cache untuk server yang ada, yang dapat memverifikasi apakah pengguna telah masuk. Saya menuliskan apa yang saya pelajari sehingga para pemula dapat menghindari jalur lentur dan secara langsung mengunggah kode ~
Pertama, permintaan HttpServletRequest request perlu ditambahkan ke parameter antarmuka login SSM untuk mendapatkan sesi yang dibawa oleh permintaan.
Kedua, atur sesi dalam kode antarmuka login, HttpSession session = request.getSession(true); // Kalimat ini adalah untuk mendapatkan sesi, benar berarti bahwa jika tidak ada sesi, buat sesi baru tanpa mengisinya.
session.setAttribute("logined","success"); // Kalimat ini adalah menulis logo. Anda juga dapat mengatur akun logged-in dalam sesi tersebut untuk mencegah gangguan jahat dengan informasi akun lain saat memulai permintaan modifikasi.
Ketiga, bagaimana cara memverifikasi di antarmuka? Parameter permintaan HTTPServletRequest juga perlu untuk mendapatkan sesi yang dibawa oleh klien yang memulai permintaan HTTP. HttpSession session = request.getSession(); session.getAttribute("logined") untuk membaca apakah ada kunci login. Jika tidak ada login, konten yang diminta tidak akan diberikan, dan informasi akan dikembalikan langsung untuk mengingatkan pengguna untuk masuk.
Masalah Lingkup Sesi Proyek SSM
Deskripsi: Setelah pengguna masuk ke dalam sistem berhasil, memasukkan informasi yang relevan pengguna ke dalam domain sesi untuk panggilan mudah, dan bernama XX.
Ketika pengguna masuk ke sistem ini, ia perlu memodifikasi informasi pribadinya. Setelah modifikasi selesai, informasi pribadi yang dimodifikasi pengguna di halaman meja depan dicap ulang ke domain sesi ini untuk menimpa sesi sebelumnya. Dengan cara ini, ketika pengguna masuk lagi atau memeriksa, informasi setelah dia mengubahnya.
Analisis: Ketika pengguna ingin memodifikasi informasi pribadinya setelah memodifikasi informasi pribadinya (memodifikasi informasi pribadi dan memodifikasi kata sandi pribadi tidak ada di halaman yang sama), kata sandi lama yang dimasukkan akan diminta untuk salah, karena tidak ada kata sandi pribadi saat memodifikasi informasi pribadi. Artinya, ketika pengguna memodifikasi informasinya sendiri dan memasukkan informasinya ke dalam sesi, kata sandi pribadi dienkapsulasi dengan nilai kosong, dan kata sandi nyata untuk login pengguna tidak dapat diperoleh saat ini.
Solusi: Jika Anda ingin memodifikasi kata sandi pribadi Anda dengan lancar setelah memodifikasi informasi pribadi Anda, Anda harus menambahkan domain tersembunyi dari kata sandi pengguna ke halaman tempat Anda memodifikasi informasi pribadi Anda. Dengan cara ini, kata sandi login pribadi akan dienkapsulasi ke dalam objek dengan informasi yang dimodifikasi oleh pengguna, dan akan dimasukkan ke dalam domain sesi. Dengan cara ini, dorongan internal dalam domain sesi dapat dipanggil saat memodifikasi kata sandi, dan kata sandi tidak akan kosong.
Di atas adalah semua konten artikel ini. Saya berharap ini akan membantu untuk pembelajaran semua orang dan saya harap semua orang akan lebih mendukung wulin.com.