“ ผู้ใช้ไม่ควรตัดสินใจว่าเป็นผู้ดูแลหรือไม่ ควรมีสิทธิ์หรือระบบรักษาความปลอดภัย”

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

user.isAdmin()

สิ่งนี้กระตุ้นให้เกิดความคิดเห็นซึ่งซ้ำหลายครั้งและได้รับการโหวตหลายครั้ง:

ผู้ใช้ไม่ควรตัดสินใจว่าเป็นผู้ดูแลระบบหรือไม่ สิทธิพิเศษหรือระบบความปลอดภัยควร สิ่งที่อยู่คู่กับชั้นเรียนแน่นไม่ได้หมายความว่าเป็นความคิดที่ดีที่จะทำให้มันเป็นส่วนหนึ่งของชั้นเรียนนั้น

ฉันตอบ

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

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

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

คิดเกี่ยวกับผู้ใช้เป็นกุญแจสำคัญและการอนุญาตเป็นค่า

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

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

ความคิดเห็นนั้นเป็นคำพูดที่ไม่ดี

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

ฉันจะไม่เลือกที่จะแสดงความคิดเห็นต้นฉบับในแบบที่มันเป็นคำ แต่มันจะระบุปัญหาที่อาจเกิดขึ้นตามกฎหมาย

โดยเฉพาะความกังวลที่รับประกันแยกมีการตรวจสอบกับการอนุมัติ

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

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

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

หากสิ่งเหล่านี้เป็นคลาสหรือนามธรรมรหัสความปลอดภัยของคุณซึ่งเป็นหนึ่งในเครื่องมือที่สำคัญที่สุดในการลดความเสี่ยงกลายเป็นเรื่องที่มีความเสี่ยงสูง

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

ไมโครซอฟท์และซัน / ออราเคิล (Java) หมายถึงการรวมของการตรวจสอบและอนุมัติข้อมูลเป็นความปลอดภัยของเงินต้น มันไม่สมบูรณ์แบบ แต่ทำงานได้ดีพอสมควร ใน. NET ตัวอย่างเช่นคุณมีIPrincipalสิ่งที่ห่อหุ้มวัตถุIIdentity- อดีตเป็นวัตถุนโยบาย (การอนุญาต) ในขณะที่หลังเป็นตัวตน (การรับรองความถูกต้อง) คุณพอจะตั้งคำถามกับการตัดสินใจที่จะใส่หนึ่งภายในของอื่น ๆ แต่สิ่งที่สำคัญก็คือว่ารหัสที่สุดที่คุณเขียนจะเป็นเพียงหนึ่งในแนวคิดซึ่งหมายความว่ามันเป็นเรื่องง่ายในการทดสอบและ refactor

ไม่มีอะไรผิดปกติกับUser.IsAdminฟิลด์ ... เว้นแต่จะมีUser.Nameฟิลด์ด้วย สิ่งนี้จะบ่งชี้ว่าแนวคิด "ผู้ใช้" ไม่ได้ถูกกำหนดอย่างเหมาะสมและนี่เป็นเรื่องน่าเศร้าที่เกิดข้อผิดพลาดที่พบบ่อยในหมู่นักพัฒนาซอฟต์แวร์ที่เปียกหลังใบหูเมื่อพูดถึงเรื่องความปลอดภัย โดยทั่วไปสิ่งเดียวที่ควรใช้ร่วมกันโดยข้อมูลประจำตัวและนโยบายคือ ID ผู้ใช้ซึ่งไม่ได้เกิดขึ้นโดยบังเอิญคือวิธีการนำไปใช้ในรูปแบบการรักษาความปลอดภัยทั้ง Windows และ * nix

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

รูปแบบความปลอดภัยแบบง่าย ๆดูเหมือนจะเป็นความคิดที่ดีเสมอเมื่อคุณออกแบบแอปพลิเคชั่นใหม่เป็นครั้งแรกเนื่องจาก YAGNI และสิ่งนั้น แต่มันมักจะกลับมากัดคุณในภายหลังเพราะแปลกใจแปลกใจเพิ่มคุณสมบัติใหม่ ๆ !

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

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

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

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

แต่คุณสามารถใช้สิทธิ์ enum ประเภทต่างๆและPermissionsManagerคลาสแทน บางทีคุณอาจมีวิธีการเช่นPermissionsManager.userHasPermission(User, Permission)คืนค่าบูลีน ในทางปฏิบัติมันอาจดูเหมือน (ใน java):

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

มันเทียบเท่ากับวิธีการของรางbefore_filterซึ่งให้ตัวอย่างของการตรวจสอบสิทธิ์ประเภทนี้ในโลกแห่งความเป็นจริง

Object.isX () ใช้เพื่อแสดงความสัมพันธ์ที่ชัดเจนระหว่างวัตถุและ X ซึ่งสามารถแสดงเป็นผลลัพธ์บูลีนตัวอย่างเช่น:

Water.isBoiling ()

Circuit.isOpen ()

User.isAdmin () ถือว่าความหมายเดียวของ 'ผู้ดูแลระบบ' ในทุกบริบทของระบบซึ่งผู้ใช้เป็นผู้ดูแลระบบในทุกส่วนของระบบ

ในขณะที่ฟังดูง่ายพอโปรแกรมโลกแห่งความเป็นจริงแทบจะไม่เหมาะกับโมเดลนี้แน่นอนที่สุดจะมีข้อกำหนดสำหรับผู้ใช้ในการจัดการทรัพยากร [X] แต่ไม่ใช่ [Y] หรือสำหรับผู้ดูแลระบบประเภทต่าง ๆ (โครงการ ] ผู้ดูแลระบบเทียบกับผู้ดูแลระบบ [ระบบ])

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

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

ไม่เป็นปัญหา ...

User.isAdmin()ฉันไม่เห็นปัญหากับ ฉันชอบมันPermissionManager.userHasPermission(user, permissions.ADMIN)มากกว่าซึ่งในชื่อศักดิ์สิทธิ์ของ SRP ทำให้รหัสชัดเจนน้อยลงและไม่เพิ่มมูลค่าใด ๆ

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

... แต่ทำไมคุณถึงอยากรู้

ที่กล่าวมาดูเหมือนว่าฉันจะไม่ค่อยรู้ว่าผู้ใช้เป็นผู้ดูแลหรือไม่สามารถตอบคำถามอื่น ๆ ได้เช่นว่าผู้ใช้จะได้รับอนุญาตให้ดำเนินการบางอย่างหรือไม่เช่นอัปเดตวิดเจ็ต หากเป็นกรณีนี้ฉันต้องการมีวิธีใน Widget เช่นisUpdatableBy(User user):

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

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

[แก้ไข]

ปัญหาเกี่ยวกับการไม่ได้มีUser.isAdmin()และการใช้PermissionManager.userHasPermission(...)

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

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

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

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

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

ทำไมคลาสเฟรมเวิร์คจำนวนมากถูกปิดผนึก?

โดยเฉพาะอย่างยิ่งเอริคยกประเด็น:

4) ปลอดภัย จุดรวมของความแตกต่างคือคุณสามารถผ่านวัตถุที่มีลักษณะเหมือนสัตว์ แต่ในความเป็นจริงแล้วยีราฟ มีปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นที่นี่

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

นี้อาจดูเหมือนสัมผัส แต่ฉันคิดว่ามัน dovetails กับจุดโปสเตอร์อื่น ๆ ได้ยกขึ้นเกี่ยวกับSOLID หลักการเดียวรับผิดชอบ พิจารณาคลาสที่เป็นอันตรายต่อไปนี้เป็นเหตุผลที่จะไม่ใช้User.IsAdminวิธีการหรือคุณสมบัติ

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

จริงอยู่มันเป็นเรื่องที่ค่อนข้างยืดเยื้อ: ยังไม่มีใครแนะนำIsAmdminวิธีการเสมือนจริง แต่อาจเกิดขึ้นได้หากสถาปัตยกรรมผู้ใช้ / บทบาทของคุณสิ้นสุดลงด้วยความซับซ้อนที่แปลกประหลาด (หรืออาจจะไม่ใช่ลองพิจารณาpublic class Admin : User { ... }: คลาสนี้อาจมีรหัสที่ด้านบน) การรับไบนารีที่เป็นอันตรายเข้ามาไม่ใช่การโจมตีแบบเวกเตอร์ทั่วไปและมีความเป็นไปได้ที่จะเกิดความสับสนวุ่นวายมากกว่าห้องสมุดผู้ใช้ที่คลุมเครือ อาจเป็นข้อผิดพลาดของการเพิ่มระดับสิทธิ์ที่เปิดประตูสู่ความเป็นจริงของเชนันนิแกน ในที่สุดหากอินสแตนซ์ไบนารีหรือวัตถุที่เป็นอันตรายไม่สามารถหาเวลามาใช้งานได้มันก็ไม่ได้ไกลเกินกว่าที่จะจินตนาการว่า "Privilege หรือระบบรักษาความปลอดภัย" ถูกแทนที่ในลักษณะที่คล้ายคลึงกัน

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

โอ้และเพื่อความแม่นยำสำหรับบันทึกฉันเห็นด้วยกับสัจพจน์ในคำถาม:“ ผู้ใช้ไม่ควรตัดสินใจว่าเป็นผู้ดูแลระบบหรือไม่ . สิทธิประโยชน์หรือการรักษาความปลอดภัยระบบควร” เป็นUser.IsAdminวิธีการที่เป็นความคิดที่ไม่ดีถ้าคุณกำลังเรียกใช้รหัสในระบบของคุณไม่ได้อยู่ในการควบคุม 100% ของรหัส - Permissions.IsAdmin(User user)คุณแทนควรจะทำอย่างไร

ปัญหาที่นี่คือ:

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

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