ในช่วงสองวันที่ผ่านมาเนื่องจากฉันใช้ Ajax ที่ส่วนหน้าเพื่อเริ่มคำขอการอัปเดตแบบอะซิงโครนัสฉันพบว่า Ajax จะเปิดเผยที่อยู่อินเตอร์เฟสของแบ็กเอนด์ แน่นอนปัญหานี้หลีกเลี่ยงไม่ได้และส่วนหน้าเป็นข้อความธรรมดา น่าเสียดายที่ฉันถามคำถามต่าง ๆ ในกลุ่ม Baidu, Google และ QQ พวกเขาทั้งหมดกล่าวว่าปัญหาสามารถแก้ไขได้ผ่านการตรวจสอบความปลอดภัยเท่านั้น ในฐานะสามเณรตัวเลือกแรกคือเซสชั่นแน่นอน มีการตรวจสอบโทเค็นเฟรมเวิร์ก Shrio ฯลฯ ออนไลน์ เพื่อนที่สนใจสามารถค้นหาบทเรียนออนไลน์เพื่อเรียนรู้
เซสชั่นเป็นกลไกแคชสำหรับเซิร์ฟเวอร์ที่มีอยู่ซึ่งสามารถตรวจสอบได้ว่าผู้ใช้ได้ลงชื่อเข้าใช้หรือไม่ฉันเขียนสิ่งที่ฉันเรียนรู้เพื่อให้ผู้เริ่มต้นสามารถหลีกเลี่ยงเส้นทางการดัดและอัปโหลดรหัสโดยตรง ~
ขั้นแรกต้องเพิ่มคำขอ HttpServletRequest request ในพารามิเตอร์อินเตอร์เฟสการเข้าสู่ระบบ SSM เพื่อให้ได้เซสชันที่ดำเนินการตามคำขอ
ประการที่สองตั้งค่าเซสชันในรหัสอินเตอร์เฟสเข้าสู่ระบบ, HttpSession session = request.getSession(true); // ประโยคนี้คือการรับเซสชันจริงหมายความว่าหากไม่มีเซสชันให้สร้างเซสชันใหม่โดยไม่ต้องกรอกข้อมูล
session.setAttribute("logined","success"); // ประโยคนี้คือการเขียนโลโก้ นอกจากนี้คุณยังสามารถตั้งค่าบัญชีที่เข้าสู่ระบบในเซสชั่นเพื่อป้องกันการดัดแปลงข้อมูลของบัญชีอื่นอย่างร้ายกาจเมื่อเริ่มคำขอแก้ไข
ประการที่สามวิธีการตรวจสอบในอินเทอร์เฟซ? นอกจากนี้ยังจำเป็นต้องใช้พารามิเตอร์การร้องขอ HTTPSERVLETREQUEST เพื่อรับเซสชันที่ดำเนินการโดยไคลเอนต์ที่เริ่มต้นคำขอ HTTP HttpSession session = request.getSession(); session.getAttribute("logined") เพื่ออ่านว่ามีคีย์เข้าสู่ระบบหรือไม่ หากไม่มีการเข้าสู่ระบบเนื้อหาที่ร้องขอจะไม่ได้รับและข้อมูลจะถูกส่งคืนโดยตรงเพื่อเตือนผู้ใช้ให้เข้าสู่ระบบ
ปัญหาขอบเขตเซสชันโครงการ SSM
คำอธิบาย: หลังจากผู้ใช้เข้าสู่ระบบได้สำเร็จแล้วให้นำข้อมูลที่เกี่ยวข้องของผู้ใช้ลงในโดเมนเซสชันเพื่อการโทรง่ายและมีชื่อว่า XX
เมื่อผู้ใช้เข้าสู่ระบบนี้เขา/เธอจำเป็นต้องปรับเปลี่ยนข้อมูลส่วนบุคคลของเขา/เธอ หลังจากการแก้ไขเสร็จสมบูรณ์ข้อมูลส่วนบุคคลที่ได้รับการแก้ไขของผู้ใช้ในหน้าแผนกต้อนรับจะถูกประทับตราอีกครั้งในโดเมนเซสชันนี้เพื่อเขียนทับเซสชันก่อนหน้า ด้วยวิธีนี้เมื่อผู้ใช้เข้าสู่ระบบอีกครั้งหรือตรวจสอบข้อมูลหลังจากที่เขา/เธอเปลี่ยนแปลง
การวิเคราะห์: เมื่อผู้ใช้ต้องการแก้ไขข้อมูลส่วนบุคคลของเขาหลังจากแก้ไขข้อมูลส่วนบุคคลของเขา (การแก้ไขข้อมูลส่วนบุคคลและการแก้ไขรหัสผ่านส่วนบุคคลไม่ได้อยู่ในหน้าเดียวกัน) รหัสผ่านเก่าที่ป้อนจะได้รับแจ้งให้ผิดเพราะไม่มีรหัสผ่านส่วนบุคคลเมื่อแก้ไขข้อมูลส่วนบุคคล นั่นคือเมื่อผู้ใช้แก้ไขข้อมูลของตัวเองและใส่ข้อมูลของเขาลงในเซสชันรหัสผ่านส่วนบุคคลจะถูกห่อหุ้มด้วยค่าที่ว่างเปล่าและรหัสผ่านจริงสำหรับการเข้าสู่ระบบของผู้ใช้ไม่สามารถรับได้ในเวลานี้
วิธีแก้ปัญหา: หากคุณต้องการแก้ไขรหัสผ่านส่วนบุคคลของคุณอย่างราบรื่นหลังจากแก้ไขข้อมูลส่วนบุคคลของคุณคุณต้องเพิ่มโดเมนที่ซ่อนอยู่ของรหัสผ่านผู้ใช้ในหน้าเว็บที่คุณแก้ไขข้อมูลส่วนบุคคลของคุณ ด้วยวิธีนี้รหัสผ่านเข้าสู่ระบบส่วนบุคคลจะถูกห่อหุ้มลงในวัตถุด้วยข้อมูลที่แก้ไขโดยผู้ใช้และจะถูกยัดเข้าไปในโดเมนเซสชัน ด้วยวิธีนี้การกดภายในในโดเมนเซสชันสามารถเรียกได้เมื่อแก้ไขรหัสผ่านและรหัสผ่านจะไม่ว่างเปล่า
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ของทุกคนและฉันหวังว่าทุกคนจะสนับสนุน wulin.com มากขึ้น