ควรหลีกเลี่ยงตัวแปรเซสชันหรือไม่

ฉันเคยพึ่งพาตัวแปรเซสชั่นอย่างมากในอดีต แต่เมื่อเร็ว ๆ นี้พบว่าหลายคนไม่จำเป็นต้องใช้สิ่งต่าง ๆ เช่นพารามิเตอร์สตริงแบบสอบถาม

เพื่อนร่วมงานของฉันปฏิเสธที่จะใช้ตัวแปรเซสชั่น นี่เป็นเป้าหมายที่เป็นจริงและควรหลีกเลี่ยงตัวแปรเซสชันด้วยเหตุผลเชิงปฏิบัติหรือไม่? สามารถหลีกเลี่ยงตัวแปรเซสชันได้อย่างสมบูรณ์ (ยกเว้นคุกกี้เซสชันเพื่ออนุญาตให้เข้าสู่ระบบ) และผลลัพธ์นี้จะทำให้การออกแบบดีขึ้นหรือไม่

เหตุผลบางอย่างที่เพื่อนร่วมงานของฉันไม่ได้ใช้:

• ลักษณะที่ไม่ได้พิมพ์ของตัวแปรเซสชัน
• การหมดเวลาของเซสชันทำให้สูญเสียสถานะ
• ลักษณะขอบเขตส่วนกลางของตัวแปรเซสชัน
• โหลดเซิร์ฟเวอร์ที่ทำโหลดบาลานซ์จะสูญเสียเซสชัน (เฉพาะ. Net?)
• แอพลิเคชันพูล / เซิร์ฟเวอร์เริ่มต้นใหม่
• พวกเขาไม่จำเป็น

หากคุณมีตัวแปรเซสชั่นในใบสมัครของคุณถามตัวเองนี้:

เมื่อฉันคลิกปุ่มย้อนกลับของเบราว์เซอร์ฉันต้องการให้ตัวแปรของฉันมีค่าเท่าใด

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

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

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

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

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

ปัญหาต่อไปนี้เป็นการใช้งานเฉพาะ:

ลักษณะที่ไม่ได้พิมพ์ของตัวแปรเซสชัน

ลักษณะขอบเขตส่วนกลางของตัวแปรเซสชัน

โหลดเซิร์ฟเวอร์ที่ทำสมดุลการสูญเสียเซสชัน

แอพลิเคชันพูล / เซิร์ฟเวอร์เริ่มต้นใหม่

ตัวอย่างเช่นฉันมักทำงานใน PHP และเก็บข้อมูลเซสชันของฉันในฐานข้อมูลเชิงสัมพันธ์ ดังนั้นตัวแปรเซสชั่นของฉันถูกพิมพ์ โหลดบาลานซ์และรีสตาร์ทเซิร์ฟเวอร์ไม่ทำให้เกิดปัญหาเซสชัน

อันนี้น่าสนใจกว่า:

การหมดเวลาของเซสชันทำให้สูญเสียสถานะ

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

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

คนอื่น ๆ ได้ทำมากของจุดดี (ซึ่งผมจะหลีกเลี่ยงการทำซ้ำ) แต่มีเป็นหนึ่งในด้านของเทคนิคเพื่อนของคุณที่ยังไม่ได้รับการกล่าวถึงเลย: การรักษาความปลอดภัย

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

• การแก้ไขเซสชัน : การโจมตีที่ทรงพลังซึ่งง่ายกว่าเล็กน้อยหากคุณเพียงแค่ให้ผู้ใช้คลิกลิงก์ที่มีข้อมูลที่จำเป็นอยู่แล้วใน URL (แทนที่จะพยายามให้ผู้ใช้ใช้เครื่องที่ตั้งค่าคุกกี้ไว้อย่างเหมาะสม)
• การฉีด SQL (หรืออินพุตที่เป็นอันตรายอื่น ๆ ) : อย่าเชื่อถือสิ่งที่มาจากผู้ใช้ ตัวแปรเซสชันมีข้อได้เปรียบที่ไม่เคยออกจากเซิร์ฟเวอร์ดังนั้นผู้ใช้จึงไม่สามารถเปลี่ยนแปลงได้โดยตรง ในขณะที่คุณควรทำความสะอาดข้อมูลก่อนที่จะใส่ลงในเซสชั่นคุณสามารถไว้วางใจค่าที่คุณได้รับหลังจากนั้น หากทุกอย่างถูกส่งผ่านสตริงเคียวรีคุณมีการตรวจสอบจำนวนมากที่คุณต้องทำเพื่อให้แน่ใจว่าคุณไม่ได้รับอินพุตที่เป็นอันตราย
• การขัดข้อมูลโดยใช้อินพุตปลอม : คล้ายกับการฉีด SQL คุณส่งข้อมูลไปมากี่ครั้ง? มันสำคัญแค่ไหน? ฉันสามารถเปลี่ยนพฤติกรรมของแอพของคุณโดยเปลี่ยนค่าในสตริงการสืบค้นได้หรือไม่ ฉันจะเสียหายข้อมูลบนเซิร์ฟเวอร์ของคุณโดยการเปลี่ยนค่าหรือไม่ หากฉันจัดการให้ข้อมูลบนเซิร์ฟเวอร์เสียหายจะมีผลกับผู้ใช้รายอื่นหรือไม่ (หากคำตอบของคุณคือ "ไม่" คำตอบของฉันคือ "คุณแน่ใจหรือไม่คุณมีสถานที่มากมายที่คุณต้องตรวจสอบ")

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

ตัวแปรเซสชั่นนั้นเหมือนกับตัวแปรโกลบอลระดับพื้นฐานระดับหนึ่ง ภาระนั้นอยู่ที่ผู้ใช้ในการติดตามพวกเขาสิ่งที่อยู่ในขอบเขตและวิธีการใช้งานของพวกเขา; เหมือนใน BASIC รุ่นเก่า ทำไมบางคนถึงได้ลดการใช้กลไกที่ได้รับการออกแบบมาอย่างชัดเจนว่าเป็นส่วนสำคัญและสำคัญมากของโมเดลการเขียนโปรแกรม (ASP, MVC และอื่น ๆ )

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

นั่นไม่ใช่สิ่งที่เราทำเมื่อเรากำลังเขียนโปรแกรม แต่อย่างใด?

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

เมื่อทำงานกับตัวแปรเซสชั่นคุณเพียงแค่ต้องติดตามเมื่อพวกเขาได้รับการตั้งค่าและ unset เช่นนี้จะกำหนดกระแสตรรกะของแอพลิเคชัน มันเหมือนกับการจัดการหน่วยความจำในภาษาอย่าง C

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

HTTP ตามที่ระบุไว้ก่อนหน้านี้คือ Stateless และ Session Variable break ที่ การออกแบบ HTTP ที่ไร้สัญชาติช่วยการแคชทรัพยากร สำหรับทรัพยากรที่เปิดเผยต่อสาธารณะ

เป็นไปได้ในการออกแบบเว็บไซต์โดยไม่มีตัวแปรเซสชัน แต่มันยากขึ้น ที่ยากที่สุด (IMHO) คือการเข้าสู่ระบบ / ออกจากระบบแฟนซีการรับรองความถูกต้องของ HTTP ไม่มีเครื่องมือที่จำเป็นในการตรวจสอบความถูกต้องผ่านแบบฟอร์ม HTML (คุณอาจแฮ็คบางอย่างด้วย javascript - XHR ถึงhttps: // untel: passowrd@mydomain.com ) มันยิ่งยากที่จะออกจากระบบและใช้งานร่วมกับเบราว์เซอร์ข้ามได้ มีการถกเถียงกันว่ารายการ ma3 ของ willing เกี่ยวกับเรื่องนั้น แต่ถ้าฉันจำได้อย่างถูกต้อง

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

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