نقد مخطط قاعدة بيانات نظام المصادقة الخاص بي؟

Question

أقوم بتصميم تطبيق ويب RESTful الذي سيوفر نظام مصادقة للعديد من التطبيقات الأخرى.ستقوم التطبيقات الأخرى بالاستعلام عن هذا التطبيق من خلال HTTP واستعادة XML الذي يصف المستخدمين المصادق عليهم.

يحتاج تطبيق المصادقة إلى تتبع أي المستخدمين مسموح لهم بذلك افعل ما على التطبيقات التي.

أنا أعمل على مخطط قاعدة البيانات.أدناه هو تصميمي الأولي.(افترض أن كل جدول يحتوي على id عمود.)

applications  # The various client apps that will query this auth system.
------------
name

users         # Table simplified for discussion
-----
username
password
email

roles
-----
name
application_id

roles_users
-----------
role_id
user_id

الفكرة هي أن شخصًا ما حاول أداء وظيفة إدارية في تطبيق "Equipment Inventory".لذا فإن "مخزون المعدات" سيقول لنظام المصادقة "احصل على المستخدم مع اسم المستخدم XXX وكلمة المرور YYY." ثم سوف ينظر إلى العائد (عبر Activeresource) User الكائن والتحقق مما إذا كان roles تحتوي المصفوفة على أ Role باسم "ADMIN" الذي ينتمي في حد ذاته إلى Application كائن باسم "مخزون المعدات".

أو ربما سيكون من الأفضل القضاء على applications الجدول ولها العديد من الأدوار، على سبيل المثال، "equipment_inventory_admin", "equipment_inventory_readonly", "job_tracker_admin"، إلخ.

ما هو الأهم، تطبيع كيان التطبيق أو تبسيط بنية الجدول؟ربما بعد كل هذه الكتابة، أجبت للتو على سؤالي، ولكن التعليقات أو الاقتراحات ستكون موضع ترحيب كبير.

Answer 1

يبدو المخطط عاقلًا ، سترسل

<login><username>abc</username><password>xyz</password><app>51</app></login>

وتعود

<auth> <user> <username>abc</a> <lastlogin>123456464</lastlogin> </user> <app> <name>Equipment Inventory</name> <version>3.1.5e</version> </app> <roles> <role>admin</role> <role>manager</role> <role>dataentry</role> </roles> </auth>

أو

<auth><error type="1"></auth>

Answer 2

بالتأكيد فصل المصادقة عن الترخيص.(يبدو أنك تفعل ذلك؛يقع جدول "المستخدم" في المصادقة، بينما يقع الباقي + user.id في التفويض)

كلمات المرور:أنت لا تخزنهم في مكان واضح، أليس كذلك؟تخزين تجزئة MD5 (+ ملح لمنع الهجمات) سيكون أكثر أمانًا.

كان كيربيروس يكون الاحتمال؟(ربما يمكن تكييفها للعمل عبر HTTP كطبقة نقل)

Answer 3

أنا شخصياً أميل إلى الخطأ في جانب التطبيع.على الأقل في تجربتي، تتم إضافة نوع من الوحدات الإضافية في المستقبل.من الأسهل بكثير إضافة سطر إضافي في التطبيق وجداول جديدة تمامًا حسب الضرورة ثم تحرير المخطط الحالي والاضطرار إلى تحديث جميع أكواد الوصول إلى البيانات ذات الصلة.

يحرر:في نظرة ثانية يمكنك دمج جدول الأدوار وجدول role_users.يمكن أن يكون مكانًا واحدًا يحدد الأدوار وكيف يمكن للمستخدمين الوصول إليها لكل تطبيق.