มีเหตุผลใดที่จะไม่ไปจาก Javascript ฝั่งไคลเอ็นต์โดยตรงกับฐานข้อมูลหรือไม่?

สำเนาซ้ำที่เป็นไปได้:
เขียนแอปพลิเคชัน“ เซิร์ฟเวอร์น้อยกว่า” บนเว็บ

ดังนั้นสมมติว่าฉันจะสร้างโคลน Exchange Stack และฉันตัดสินใจที่จะใช้สิ่งที่ต้องการ CouchDB เป็นที่เก็บแบ็กเอนด์ของฉัน หากฉันใช้การพิสูจน์ตัวตนในตัวและการอนุญาตระดับฐานข้อมูลมีเหตุผลใดที่จะไม่อนุญาตให้ Javascript ฝั่งไคลเอ็นต์เขียนโดยตรงไปยังเซิร์ฟเวอร์ CouchDB ที่เปิดเผยสู่สาธารณะ เนื่องจากนี่เป็นแอปพลิเคชั่น CRUD และตรรกะทางธุรกิจประกอบด้วย "ผู้เขียนเท่านั้นที่สามารถแก้ไขโพสต์ของพวกเขา" ฉันไม่เห็นความต้องการมากที่จะมีเลเยอร์ระหว่างสิ่งที่ฝั่งไคลเอ็นต์และฐานข้อมูล ฉันเพียงแค่ใช้การตรวจสอบด้าน CouchDB เพื่อให้แน่ใจว่าไม่มีใครใส่ข้อมูลขยะและตรวจสอบให้แน่ใจว่ามีการตั้งค่าการอนุญาตอย่างถูกต้องเพื่อให้ผู้ใช้สามารถอ่านข้อมูล _user ของตนเองได้ การเรนเดอร์จะทำได้โดยฝั่งไคลเอ็นต์โดยบางสิ่งเช่น AngularJS โดยพื้นฐานแล้วคุณสามารถมีเซิร์ฟเวอร์ CouchDB และหน้าแบบ "คงที่" และคุณก็พร้อมที่จะไป คุณไม่จำเป็นต้องมีการประมวลผลด้านเซิร์ฟเวอร์ใด ๆ เพียงแค่สิ่งที่สามารถแสดงหน้า HTML ได้

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

แก้ไข: ดูเหมือนว่ามีการสนทนาที่คล้ายกันที่นี่: การเขียนเว็บ "เซิร์ฟเวอร์น้อยกว่า" แอปพลิเคชัน

แก้ไข: การอภิปรายที่น่าประทับใจจนถึงตอนนี้และฉันขอขอบคุณข้อเสนอแนะของทุกคน! ฉันรู้สึกว่าฉันควรเพิ่มสมมติฐานทั่วไปสองสามข้อแทนที่จะเรียกเฉพาะ CouchDB และ AngularJS โดยเฉพาะ ดังนั้นสมมติว่า:

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

ทำตามที่คุณแนะนำให้สร้างการเชื่อมต่อระหว่างภาษาฝั่งไคลเอ็นต์และฐานข้อมูลของคุณ

มันสามารถใช้ได้ - มีโค้ดน้อยกว่าในการเขียนและบำรุงรักษาและในทางทฤษฎีแล้วการดีบั๊กอาจจะเร็วขึ้นเล็กน้อย

ในทางตรงกันข้ามมันทำให้แง่มุมอื่น ๆ ยากขึ้น หาก / เมื่อคุณต้องการเปลี่ยนเทคโนโลยีเหล่านั้นคุณจะมีเวลามากขึ้นเพราะการมีเพศสัมพันธ์ที่แน่นหนาระหว่างกัน

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

ฉันจะไม่แนะนำที่นี่และหลายคนจะบอกคุณอย่างบ้าคลั่ง แต่ก็สามารถทำได้

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

หากคุณต้องการหลักฐานสนับสนุนมีความกังวลมากมาย - ไม่ใช่ทั้งหมดที่ไม่สามารถคาดเดาได้ ไม่เรียงลำดับโดยเฉพาะนี่คือบางส่วน:

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

... และฉันแน่ใจว่ามีข้อกังวลอื่น ๆ และฉันแน่ใจว่าจะมีทางออกให้มากที่สุด - ถ้าไม่ใช่ทั้งหมดที่เกี่ยวข้อง แต่มีรายการให้คุณเริ่มต้น!

เหตุผลเดียวที่ดีที่สุดที่ฉันจินตนาการได้คือ: เพราะวิธีนี้ไม่ได้รับการสนับสนุนโดยตรงหรือแนะนำโดยบุคคลที่เกี่ยวข้อง

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

ฉันไม่ได้บอกว่ามันเป็นไปไม่ได้ ฉันแค่บอกว่ามันไม่เหมือนกับ "การคิดค้นวงล้อใหม่" และอื่น ๆ เช่นการสร้างการโต้ตอบระหว่างไคลเอนต์กับเซิร์ฟเวอร์บนเบราว์เซอร์

ที่ดีที่สุดคุณจะต้องทำงานหลายอย่างเพื่อให้ระบบทำงานในระดับพื้นฐานที่สุดเท่าที่จะเป็นไปได้ ฐานข้อมูลยอดนิยมที่ทันสมัยไม่ได้สงบหรือสร้างขึ้นเพื่อทำงานผ่าน HTTP ดังนั้นคุณจะต้องสร้างไดรเวอร์ไคลเอนต์ WebSocket (ฉันเข้าใจ) ของคุณเอง

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

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

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

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

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

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

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

ให้ความสามารถสำหรับการป้อนข้อมูลลูกค้าโดยตรงสื่อสารกับฐานข้อมูลมีขนาดใหญ่มากมีศักยภาพที่จะกรูขึ้นข้อมูล

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

การให้ผู้ใช้โต้ตอบกับฐานข้อมูลโดยตรงนั้นเป็นอันตรายกับฉันจริงๆ

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

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

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

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

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

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

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

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

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

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

ทำตามตัวอย่างโคลน stackoverflow ของคุณ:

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

บุคคลใดก็ตามสามารถจัดการโค้ดด้านไคลเอนต์และละเมิดความสมบูรณ์ของข้อมูลได้อย่างสมบูรณ์ (แม้ว่าจะถูก จำกัด เฉพาะวัตถุบางอย่างเช่นโพสต์ของตนเอง)

แก้ไขหน้าใน firebug และในบางจุดใส่บรรทัดที่คล้ายกับสิ่งนี้:

ExecDbCommand("DROP TABLE Users")

เรียกใช้

แก้ไข:

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

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

คำถามเก่าฉันรู้ แต่ฉันต้องการที่จะพูดสอดเพราะประสบการณ์ของฉันค่อนข้างแตกต่างจากคำตอบอื่น ๆ

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

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

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

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

ฉันกำลังสร้างระบบในปัจจุบันโดยใช้ CouchDB ซึ่งผู้ใช้จำเป็นต้องทำงานร่วมกันกับข้อมูลเพื่อสร้างชุดข้อมูลที่ "เผยแพร่" ผ่านเวิร์กโฟลว์ QA / QC การทำงานร่วมกันนั้นดำเนินการกับข้อมูลจำลอง (เราเรียกสิ่งนี้ว่า staging หรือฐานข้อมูลการทำงาน) และเมื่อเสร็จสมบูรณ์แล้วผู้รับผิดชอบจะดำเนินการ QA / QC กับข้อมูลและหลังจากนั้นจะถูกจำลองแบบกลับเข้าไปในพื้นที่เก็บข้อมูลหลัก

ประโยชน์มากมายไหลมาจากสิ่งนี้ซึ่งยากที่จะประสบความสำเร็จในระบบอื่น ๆ - เช่นการควบคุมเวอร์ชันการจำลองและการทำงานร่วมกัน

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

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

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

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

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

ก่อนอื่นขอขอบคุณสำหรับคำถาม OUT THE THE BOX .... :)

แต่สิ่งที่ฉันอยากจะแนะนำก็คือ; พยายามแยกระหว่าง 3 เลเยอร์ของคุณเสมอ ซึ่งเป็นการนำเสนอ / ธุรกิจและฐานข้อมูลหรือ DAO เพราะจะเป็นแนวปฏิบัติที่ดีที่สุดในข้อกำหนดและการตั้งค่าเหล่านั้นซึ่งจะมีการเปลี่ยนแปลงมากมายทุกวัน

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

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

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

ขอบคุณ

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

แต่ไม่ใช่กรณีเนื่องจากคุณใช้ฐานข้อมูลคีย์ - ค่า (เท่าที่ฉันเข้าใจ CouchDB โดยทั่วไปจะอยู่ในหมวดหมู่นั้น) อินเทอร์เฟซฐานข้อมูลนั้นเป็นประเภทของเลเยอร์กลางและได้รับการทดสอบด้วยเหตุผลด้านความปลอดภัยโดยทีมงาน Apache เนื่องจาก JavaScript API ค่อนข้างง่ายสิ่งนี้ง่ายต่อการวิเคราะห์ข้อบกพร่องที่อาจเกิดขึ้นได้มากกว่าส่วนต่อประสานที่ซับซ้อนที่แอปพลิเคชัน JSF มี

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

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

ฉันเห็นปัญหาสองข้อ:

1. คลัปแน่น:เปลี่ยนตัวเลือก DB ของคุณหรือไม่ ตอนนี้คุณต้องเปลี่ยนรหัสฝั่งไคลเอ็นต์ทั้งหมดของคุณด้วย เชื่อฉัน. เราไม่ต้องการปัญหาเพิ่มเติมเกี่ยวกับลูกค้า

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

เทียร์ระดับกลางที่บางมาก ๆ อาจเป็นวิธีที่ดีกว่า

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