ساخت جداول احراز هویت و اختیارات

[IMANAZADI]

با سلام
یک بحث بدجوری گیجم کرده
در بحث authorization, authentication ترتیب ارتباطات بین جداول به چه صورت است


جداول زیر رو در نظر بگیرید
user
roles
group
permission




فرض کنیم یک فروم داریم شامل چند انجمن
هر انجمن چند مدیر و هر مدیر در انجمن خود مجوز های خاص خود را دارد
و الی آخر ....

مثل همین سایت برنامه نویس


کدامیک از موارد زیر صحیح می باشد
هر یوزر چند نقش دارد بعد هر نقش عضو چند گروه است و هر گروه مجوز خاصی دارد ؟؟؟
یا هر یوزر عضو چند گروه است هر گروه چند نقش دارد و هر نقش هم مجوز خاصی دارد ؟؟؟؟
یا موارد دیگه .....

[SabaSabouhi]

با سلام
یک بحث بدجوری گیجم کرده
در بحث authorization, authentication ترتیب ارتباطات بین جداول به چه صورت است


جداول زیر رو در نظر بگیرید
user
roles
group
permission




فرض کنیم یک فروم داریم شامل چند انجمن
هر انجمن چند مدیر و هر مدیر در انجمن خود مجوز های خاص خود را دارد
و الی آخر ....

مثل همین سایت برنامه نویس


کدامیک از موارد زیر صحیح می باشد
هر یوزر چند نقش دارد بعد هر نقش عضو چند گروه است و هر گروه مجوز خاصی دارد ؟؟؟
یا هر یوزر عضو چند گروه است هر گروه چند نقش دارد و هر نقش هم مجوز خاصی دارد ؟؟؟؟
یا موارد دیگه .....

سلام
برای این کار نمی‌شه یه روش رو عنوان کرد به عنوان روش قطعی و صحیح.
هر روشی نقطه قوت و ضعف خودش رو داره.
اما در کل انتخاب 4 جدول شما درسته. و به این شکل انجام می‌شه:
1. «کاربران» در این جدول فهرست کاربران و Hash شده‌ی کلمه‌ی عبور ( گذر واژه ) اون‌ها رو نگه‌داری می‌کنه
2. «گروه‌ها» کاربران عضو گروه‌ها می‌شن
3. «نقش‌ها» گروه‌ها نقش دارن.
4. «دسترسی‌ها» نقش‌ها هم دسترسی دارن.

این یه سیستم کامل هست. اما مشکلی که داره اینه که برای جاهای کوچیک یه کم دست و پا گیره هست
و Adminهای اون‌ها رو که ممکنه افراد حرفه‌ای نباشن رو اذیت می‌کنه.
من خودم همیشه اجازه‌ی میان‌بر رو می‌دم، یعنی اجازه می‌دم که دسترسی به غیر از «نقش» به «گروه» و «کاربر» هم داده بشه.

صبا صبوحی

[golbafan]

یک نکته جالب درباره آقای صبوحی هست که خیلی خوبه:

در توضیحاتشون همیشه از شماره استفاده میکنن 1234... :تشویق:

[IMANAZADI]

این دیاگرام درسته ؟؟؟
128888

در جدول permission غیر از نام فیلد دیگری هم باید گذاشت یا نه ؟؟؟؟

یک چیزه دیگه
در گروه چه نام های میتوان زد
در نقش ها چه ؟
در مجوز ها چه ؟


مثلا adminstrator , edit , engineering هر کدام باید در کدام جدول باشند

[SabaSabouhi]

این دیاگرام درسته ؟؟؟
128888

در جدول permission غیر از نام فیلد دیگری هم باید گذاشت یا نه ؟؟؟؟

یک چیزه دیگه
در گروه چه نام های میتوان زد
در نقش ها چه ؟
در مجوز ها چه ؟


مثلا adminstrator , edit , engineering هر کدام باید در کدام جدول باشند

سلام
چند تا چیز به نظر می‌رسه که می‌گم.
* تو این طراحی کاربر باید تمام مراحل ( تعریف کاربر / تعریف گروه / عضویت در گروه / تعریف نقش / دادن نقش به گروه و دادن دسترسی به نقش رو حتماً انجام بده.
من قبلاً هم گفتم که این حالت ایده‌ال هست بخصوص برای جاهای بزرگ ( مثلاً بالای 200-300 نفر )، اما برای جاهای کوچیک مثل شرکت‌هایی که از مدیرعامل تا آبدارچی
جمعاً 10-12 نفر بیشتر نیستن، یه کم زیادی به نظر می‌رسه. اگه بتونی طراحی رو یه طوری عوض کنی که بشه به شخص هم دسترسی داد خیلی برای مشتری‌های
ایرانی مطلوب‌تر می‌شه.
* بجای Permission از Access استفاده کن، چون «مجوز» خاصیت‌های دیگه‌ای باید داشته باشه که اینجا نمی‌گنجه. مثلاً مجوز رو می‌شه معلق کرد، می‌تونه منقضی بشه و . . .
* Administrator رو می‌تونی یه «نقش» از پیش تعریف شده، در نظر بگیری که نیازی به مجوز نداره ( تو برنامه باید در نظر بگیری که اگه کسی نقش Admin داشت، همه مجوزها رو داره
* Edit یک دسترسی هست که باید در جدول دسترسی‌ها تعریف بشه.
* Engineering نمی‌دونم منظورت چی بود. اما اگه درست حدس زده باشم، این باید یه گروه معمولی باشه.

=> تمام دسترسی‌ها به صورت از پیش تعریف شده باید تو سیستم باشه، و برنامه‌ی شما باید اونا رو بشناسه
=> برخی از نقش‌ها باید از پیش تعریف شده باشن مثل همین مثال خودتون ( Administrator )
=> گروه‌ها و کاربران باید توسط Admin ( من ترجمه کردم «راهبر سیستم» ) ایجاد بشن.

به نظر من در نام‌گذاری هیچ محدودیتی قائل نشو، غیر از علائم مثل \ / . - $ %

** هنگام login کردن کاربر باید تمام گروه‌هایی که کاربر عضوشون هست و تمام نقش‌هایی که داره و تمام دسترسی‌هایی که داره رو جمع‌آوری کنی که
در طول اجرای برنامه مجبور نشی بارها سراغ این جدول‌ها بری.

صبا صبوحی

پانوشت: ( قابل توجه دوست خوبم golbafan ) دیدی تونستم از علائم دیگه ( غیر از شماره‌ها ) هم استفاده کنم؟ :لبخندساده:

[IMANAZADI]

قبل از هر چیزی ممنون از اینکه با حوصله و دقت جواب میدی
اینطوری که من از صحبت های شما متوجه شدم دیاگرام بالا از نظر شما مشکلی نداره . درسته ؟؟؟
فقط برای سیستم های بزرگ مورد استفاده است




اگه بتونی طراحی رو یه طوری عوض کنی که بشه به شخص هم دسترسی داد خیلی برای مشتری‌های
ایرانی مطلوب‌تر می‌شه.

اگه مثال بزنید ممنون میشم

چه عناوینی رو باید در access گنجاند ؟؟ (آیا باید نام تمام صفحات سایت رو داد)
چه عناوینی رو باید در role نشاند ؟
همانطور که متوجه شدی engineering اسم یک گروه می باشد و یا گروه دیگه ای مثل گروه مالی یا اداری یا انبار و....

[SabaSabouhi]

قبل از هر چیزی ممنون از اینکه با حوصله و دقت جواب میدی
اینطوری که من از صحبت های شما متوجه شدم دیاگرام بالا از نظر شما مشکلی نداره . درسته ؟؟؟
فقط برای سیستم های بزرگ مورد استفاده است



اگه مثال بزنید ممنون میشم

چه عناوینی رو باید در access گنجاند ؟؟ (آیا باید نام تمام صفحات سایت رو داد)
چه عناوینی رو باید در role نشاند ؟
همانطور که متوجه شدی engineering اسم یک گروه می باشد و یا گروه دیگه ای مثل گروه مالی یا اداری یا انبار و....

سلام
به نظر من دیاگرام شما از نظر کلی درسته، حالا می‌شه توش تغییراتی داد که بهینه بشه ( بسته به نوع پروژه و مخاطب شما )
اصولاً همیشه دیتابیس رو سعی می‌کنیم نرمال طراحی کنیم. اما یه دیتابیس نرمال همیشه به‌ترین پاسخ نیست. بعد از طراحی
نرمال دیتابیس می‌تونیم دیتابیس رو به جهت بهینه کردن Denormal کنیم. ( البته شاید بعضی از دوستان موافق نباشن )
که البته این کار کاملاً بستگی به شرایط داره.
به نظر من این طرح شما خیلی خوبه. حتا مایکروسافت در Active Directory همین توصیه رو می‌کنه که به شخص دسترسی ندین
به‌جاش شخص رو عضو گروه کنین و به گروه نقش بدین و به نقش هم دسترسی بدین. البته مایکروسافت از نقش استفاده نمی‌کنه
و دو نوع گروه رو بجای «گروه» و «نقش» که ما راجع بهش صحبت می‌کنیم ایجاد می‌کنه.
اما در عین حال اجازه هم می‌ده که مستقیم به شخص دسترسی بدیم.
اگه بخوای این اجازه رو به ادمین بدی که مستقیم به شخص دسترسی بده، باید تغییراتی تو این دیاگرام بدی و مثلاً یه جدول شخص-دسترسی هم
ایجاد کنی.

و اما سوال دوم: چه عناوینی رو باید در جدول دسترسی‌ها گنجوند.
خوب جواب ساده هست. هر چیزی رو که به تفکیک بخوای دسترسی بهش رو کنترل کنی.
شاید 4 تا فرم از نظر سطح دسترسی یکی باشن. می‌تونی فقط یک عنوان برای این 4 فرم به این جدول اضافه کنی
اما ممکنه یک فرمی هم باشه که غیر از دسترسی خودش، یکی از عمل‌گرهاش ( مثلاً یه دکمه ) هم دسترسی جداگانه بخواد،
پس می‌شه دو تا سطر برای یک فرم.
فرمول نمی‌شه گفت برای این. اما هر چیزی رو که بخوای کنترل کنی باید اینجا تعریف کنی.

و سوال سوم: چه عناوینی رو باید رو «نقش» قرار داد.
از دید من، دو نوع «نقش» داریم نقش سیستمی که به صورت خاص شما تو برنامه می‌شناسی ( و نیازی نیست بهش دسترسی خاصی داده بشه )
مثل ادمین. یا مثلاً مسوول کنترل یه آیتمی توی پروژه که بنا به این مسوولین امکانات خاصی از برنامه برای وی باز می‌شه و یا چیزهایی رو توی فرم‌ها
می‌بینه که دیگران نمی‌بینن. مثلاً می‌تونی یه «نقش» تعریف کنی که اگه کسی اون نقش رو داشت مقدار ستون 'Id' رو ببینه. چون معمولاً این ستون
رو تو فهرست‌ها نشون نمی‌دیم.
و نوع دوم هم «نقش»های عادی هستن که ما تعریف نمی‌کنیم. و توسط ادمین تعریف می‌شه و بستگی داره به طرز تفکر و دیدگاه ایشون.

صبا صبوحی

[IMANAZADI]

آقای صبوحی باز هم خوب و عالی:تشویق:

آیا میشه جدول نقش ها رو حذف کرد و به گروه ها دسترسی داد ؟
چون انگار جدول نقش کاربرد زیادی نداره ؟

[SabaSabouhi]

صبا خانم باز هم خوب و عالی:تشویق:

آیا میشه جدول نقش ها رو حذف کرد و به گروه ها دسترسی داد ؟
چون انگار جدول نقش کاربرد زیادی نداره ؟

سلام
1. من آقای صبوحی هستم.
2. بله که می‌شه، این یه دیاگرام نمونه هست. شما می‌تونی هر جور که تمایل داری جدول‌ها رو بسازی اما باید توجه کنی که
2.1 نیازهای کاربرت رو جواب بدی
2.2 پیچیدگی زیاد کاربر رو اذیت می‌کنه
2.3 نیازهای نرم‌افزار رو هم پوشش بدی

به نظر من، همیشه صورت مساله، راه حل رو تعریف می‌کنه. برای دو صورت مساله متفاوت ممکنه یک راه حل جواب نده
پس شما باید با توجه به نیاز خودت و مشتریت، جدول‌ها و راه حل رو انتخاب کنی.
و به‌ترین راه حل اونی هست که بتونی تو پروژه‌ی بعد هم ازش استفاده کنی و دوباره چرخ رو اختراع نکنی. ( به جهت پایین اومدن هزینه‌ی تولید نرم‌افزار )

صبا صبوحی

[IMANAZADI]

بابت اشتباهی که شد عذر میخوام (اصلاح کردم):خجالت:

ممنون از اینکه وقت گذاشتید و جواب سوال هامو دادید