การเข้าถึงพอร์ทัล APM: เซสชันของแอปพลิเคชันเป็นของใคร

การเผยแพร่แอปพลิเคชันอินทราเน็ตผ่าน BIG-IP APM Portal Access เป็นการตัดสินใจเกี่ยวกับเซสชัน ไม่ใช่การคัดลอกเซิร์ฟเวอร์เสมือน พอร์ทัลรับผู้ใช้เข้าไป โปรไฟล์การเขียนใหม่คงคำขอที่เลือกไว้บนเส้นทางของเกตเวย์ และแอปพลิเคชันยังคงมีเซสชันของตัวเอง ห้าการตรวจสอบแยกการออกแบบที่ทำงานอย่างคาดเดาได้ออกจากการออกแบบที่ฝ่ายช่วยเหลือรับรู้เรื่องหมดเวลาไปทีละผู้ใช้ ทำตามลำดับและหยุดที่ข้อแรกที่ไม่จริง

การตรวจสอบ 1: ทรัพยากรถูกเผยแพร่ ไม่ใช่แค่ลิงก์

บุ๊กมาร์กใน webtop พิสูจน์ว่าผู้ใช้เห็นรายการ แต่ไม่ได้พิสูจน์ว่าแอปพลิเคชันถูกเผยแพร่ ให้หาโปรไฟล์การเข้าถึง โปรไฟล์การเขียนใหม่ และเซิร์ฟเวอร์เสมือนที่รวมทั้งสองเข้าด้วยกัน แล้วยืนยันว่าการกำหนดทรัพยากรชี้ไปที่แอปพลิเคชันที่คุณคิด ถ้าขาดหรือขัดแย้งกันในสามอย่างนี้ ส่วนที่เหลือของรายการก็ไม่มีความหมาย

กรณีเผยแพร่ครึ่งเดียวดูลปกติที่จุดเข้า เซิร์ฟเวอร์เสมือนถือโปรไฟล์การเข้าถึง ขณะที่โปรไฟล์การเขียนใหม่จำกัดอยู่ที่ URI ของทรัพยากรอื่น รายการใน webtop จึงปรากฏและหน้าแรกโหลดได้ จากนั้นคำขอของเส้นทางย่อยก็ออกจากเส้นทางของเกตเวย์และไปถึง backend โดยตรง ภาพตรงข้ามคือทรัพยากรที่กำหนดให้แอปพลิเคชันผิด: บุ๊กมาร์กเปิดขึ้น และเปิดสิ่งที่ไม่มีใครอนุมัติ

การตรวจสอบ 2: เซสชันของ backend เป็นสถานะแยกต่างหาก

backend อาจต้องการการพิสูจน์ตัวตนของตัวเองแม้ APM จะถือว่าผู้ใช้ลงชื่อเข้าแล้ว การผสานรวม SSO ที่รองรับจะสร้างความสัมพันธ์นั้นให้คุณ แต่การยอมรับการลงชื่อเข้าพอร์ทัลไม่ได้ทำให้ทุกแอปพลิเคชันยอมรับข้อมูลประจำตัวเดียวกันหรือคุกกี้เซสชันเดียวกัน ถ้าไม่ได้กำหนดค่า SSO สำหรับทรัพยากร แอปพลิเคชันจะขอการลงชื่อเข้าของตัวเองภายในพอร์ทัลที่พิสูจน์ตัวตนแล้ว

การปิด SSO เพื่อเปลี่ยนข้อความที่มองเห็นเป็นทางลัดที่พบบ่อยและไม่ดี: มันเปลี่ยนการออกแบบการพิสูจน์ตัวตนโดยไม่แตะวงจรชีวิตที่สร้างข้อความนั้น ควรตัดสินแทนว่าการลงชื่อเข้า backend ควรปรากฏหรือไม่ และถ้าควร ให้ทำเป็นส่วนที่ชัดเจนของโฟลว์ที่เผยแพร่

การตรวจสอบ 3: มีนาฬิกาสองเรือน และไม่ใช่นาฬิกาเรือนเดียวกัน

โปรไฟล์การเข้าถึงของ APM มีเวลาหมดอายุเมื่อไม่ใช้งานและอายุเซสชันสูงสุด แอปพลิเคชันมีไทเมอร์ว่างของตัวเองและการหมดอายุของคุกกี้ การเพิ่มไทเมอร์ของพอร์ทัลไม่ได้ยืดเซสชันของแอปพลิเคชัน และการย่อเซสชันของแอปพลิเคชันไม่ได้ออกจากระบบพอร์ทัล

การโทรหาศูนย์ช่วยเหลือแบบคลาสสิกเกิดจากคู่ที่ไม่ตรงกัน: พอร์ทัลยังใช้ได้ เซสชันของแอปพลิเคชันใช้ไม่ได้ และผู้ใช้เห็นแบบฟอร์มลงชื่อเข้าที่ดูขัดกับพอร์ทัล นั่นคือพฤติกรรมที่ถูกต้อง ไม่ใช่ความผิดพลาด และทางแก้คือเลือกว่านาฬิกาเรือนใดควรหมดอายุก่อนสำหรับแอปพลิเคชันนี้

การตรวจสอบ 4: การออกจากระบบมีขอบเขตที่กำหนด

เขียนว่าปุ่มออกจากระบบของแอปพลิเคชันควรยุติอะไร: แค่แอปพลิเคชันนั้น ทั้งเซสชัน APM หรือเซสชันของผู้ให้บริการข้อมูลระบุตัวตนที่กว้างกว่า โปรไฟล์การเข้าถึงรองรับรายการ URI สำหรับออกจากระบบพร้อมความล่าช้าที่ไม่บังคับ และนั่นคือวิธีทำให้การออกจากระบบของแอปพลิเคชันยุติเซสชันของพอร์ทัลเมื่อเป็นข้อกำหนด ถ้าไม่มี การออกจากระบบของแอปพลิเคชันจะทิ้งพอร์ทัลให้ยังมีชีวิต และคำขอถัดไปอาจลงชื่อเข้าผู้ใช้กลับไปอย่างเงียบ ๆ

คำนึงถึงผลต่อทรัพยากรอื่นในพอร์ทัลเดียวกัน ถ้าการออกจากระบบของแอปพลิเคชันหนึ่งยุติเซสชันของอีกหกแอปพลิเคชัน ผู้ใช้จะเรียกสิ่งนั้นว่าบั๊ก เว้นแต่จะตกลงพฤติกรรมกับเจ้าของแอปพลิเคชันไว้ก่อน การปิดแท็บและกลับไปที่ webtop ไม่ใช่หลักฐานว่าอะไรสิ้นสุดลง

การตรวจสอบ 5: แอปพลิเคชันทนต่อการเขียนใหม่

Portal Access เขียนเนื้อหาเว็บที่เลือกใหม่ และการเขียนใหม่มีขอบ สิ่งอำนวยความสะดวกฝั่งไคลเอนต์สมัยใหม่ เวิร์กเกอร์เบื้องหลัง โฟลว์การอัปโหลด และการลงชื่อเข้าแบบเฟเดอเรชันอาจอยู่นอกเหนือสิ่งที่รีลีสหนึ่งจัดการ เมทริกซ์ความเข้ากันได้ตามเวอร์ชันของ F5 คือเอกสารที่ต้องอ่านก่อนผูกมัด เพราะขีดจำกัดขึ้นกับรีลีส

ทดสอบโฟลว์ที่สำคัญ ไม่ใช่หน้าแรก: ลงชื่อเข้า ไปตามทุกฟังก์ชันที่จำเป็น อัปโหลดถ้าแอปพลิเคชันอัปโหลด ปล่อยให้เซสชันที่ตั้งใจหมดอายุ และตามทุกเส้นทางการออกจากระบบ หน้าที่แสดงผลเพียงครั้งเดียวไม่ใช่หลักฐานว่าแอปพลิเคชันทำงาน

เมื่อโฟลว์ที่จำเป็นเขียนใหม่ไม่ได้ ให้เปลี่ยนไปใช้การออกแบบเฟเดอเรชัน พร็อกซีแบบย้อนกลับ หรือการเข้าถึงเครือข่ายที่มีเอกสารกำกับ พอร์ทัลเบราว์เซอร์ที่ถูกขอให้ทำตัวเป็นอุโมงค์ทั่วไปจะผ่านเดโมและตกในการตรวจสอบ