[مهم] form authentication جداگانه برای بخش مدیریت و کاربر

[mbasirati]

سلام

مدتی هست که این موضوع رو دارم بررسی میکنم ولی هنوز نمیدونم درستش چی هست.

ببینید معمولا هر سایتی یه بخشی داره به نام کنترل پنل مدیریت که برای مدیریت سایت هست که میتونه از این طریق محتوای سایت رو مدیریت کنه. مطلب ثبت کنه، محصول ثبت کنه، نظرات رو حذف یا تایید کنه و ... . و خب خود سایت هم ممکنه یه بخشی برای کاربران داشته باشه که کاربر عضو میشه و میتونه یه سری کارها انجام بده.

برای مثال توی یه فروشگاه اینترنتی مدیر وارد پنل مدیریت میشه و محصول ثبت میکنه، دسته بندی ها رو کم و زیاد میکنه. کاربران هم میتونن بیان ثبت نام کنن و محصولی رو خرید کنن و ...

خب طبیعیه که صفحات لاگین مدیرسایت و کاربران جداگانه طراحی میشه و ربطی به هم نداره و البته فیلدهای جدول کاربران با جدول مدیر متفاوته. مثلا توی همین مثال جدول کاربران کلی فیلد از جمله شهر و استان و آدرس و... داره که هیچکدوم توی جدول مدیریت لازم نیست. مدیر فقط یه نام کاربری و رمز عبور میخواد و بسته به مسائل دیگه دو سه فیلد دیگه.

اما آقای وحید نصیری توی کامنتهای این پست در پاسخ به یکی از کاربران گفته که این کار اضافیه و جدول ادمین باید حذف بشه و از یه جدول استفاده بشه و برای دسترسی های مختلف از رل ها استفاده بشه.

خب من این روش رو جالب نمیدونم و طبیعتا ترجیح میدم جداول کاربر و مدیر یکی نباشه، همچنین فرم های لاگین این دو. ولی خب از طرفی هم اینکه برای هر قسمت از form authentication جداگانه استفاده بشه خودش یه چالشه. الان من توی پروژم یه area دارم به نام admin که شامل بخش مدیریت وب سایت میشه و فرم لاگینی داره. و خود سایت هم یه فرم لاگین جداگانه. اگه بخوام از روش آقای نصیری برم که طبیعتا باید از یه فرم لاگین استفاده کنم و یه جدول که به نظر من و خیلیا جالب نیست. و اگرم بخوام جدا باشن باز اون چالش مطرحه.

دوستان نظرات و راه حلهاشون رو بگن تا من و کسانی که مث من این مسئله براشون مبهم و سواله بتونن استفاده کنن.

[anubis_ir]

«هیچکدوم توی جدول مدیریت لازم نیست»
خوب، نباشند. اين فيلدها را اختياري كنيد و نال پذير.
چه سيستم forms authentication و چه ASP.NET Identity جديد، هر دو يكپارچه هستند و به ازاي هر نوع كاربر موجود، يك جدول جداگانه درست نمي‌كنند. اگر اين‌ها قرار باشند به ازاي مدير يك كوكي با ساختار A و به ازاي ساير كاربران يك كوكي با ساختار B توليد كنند (دو سيستم كاملا مجزاي اعتبارسنجي)،‌ در اين صورت بايد فيلتر Authorize را از صفر بازنويسي كرد و همچنين روش توليد اين كوكي‌ها هم بايد متفاوت باشند. به علاوه كاربري كه با كوكي A لاگين شده در قسمتي كه كوكي B را قبول مي‌كند معتبر نخواهد بود (اين سيستم‌ها با كوكي رمزنگاري شده بجاي سشن كار مي‌كنند). يعني ادمين لاگين شده، در قسمت‌هاي ديگر برنامه ديگر ادمين نخواهد بود. ضمن اينكه اين مباحث به همينجا هم ختم نمي‌شوند. در يك صفحه ممكن است قسمتي از آن نياز باشد براي ادمين نمايش داده شود و قسمت‌هاي ديگر براي ساير كاربران. اينجا اگر نقش تعريف نكرده باشيد، چطور مي‌خواهيد if و else آن‌را بنويسيد؟ سيستم از يكپارچگي خارج شده. در يك صفحه هم بايد اعتبار سنجي كوكي با ساختار A كار كند و هم با ساختار كوكي B. بنابراين مجبور خواهيد شد سيستم اعتبارسنجي خاص خودتان را از صفر طراحي كنيد و همچنين مدام در حال جنگ با كل سيستم و يكپارچگي آن باشيد.
اما با همين سيستم يكپارچه‌ي فعلي هم مي‌تونيد كاربران را در چند جدول ثبت كنيد (بدون اينكه بخواهيد وارد بحث چند سيستم اعتبارسنجي جداگانه و مجزا شويد). در صفحه‌ي لاگين ادمين از جدول ادمين بخوانيد. در صفحه‌ي لاگين كاربران از لاگين كاربران (با همين كدهاي متداول). فقط قسمتي كه RoleProvider سفارشي را درست مي‌كنيد بايد به اين دو جدول دقت داشته باشيد. يكبار بايد از جدول ادمين كوئري بگيريد،‌ اگر كاربر جاري در آن نبود، از جدول كاربران كوئري بگيريد تا نقش‌ها مشخص شوند.

[hakim22]

مدیر سایت هم یکی از کاربرهای سایت هست و دلیلی برای اینکه یک صفحه ی اختصاصی برای ورود مدیر به سایت بسازید ندارید.

اول اینکه مدیر سایت فقط یک نفر یا 4 یا اصلا 40 نفر ، در برابر چند هزار کاربر دیگر سایت رقم کمی هست و هزینه ی مدیریت جدای بخش مدیریت ارزش این جدا سازی را ندارد.

مشکل دیگه در کارهایی مثل log کردن رفتار کاربرها پیش می آید. اگر کاربرهای مدیر رو از کاربرهای عادی جدا کنید برای لوگ کردن کارهای آنها هم باید جدا سازی انجام بدید.

فرض کنید یکی از اعضای مدیریت بخواد از سایت خودش (که مثلا یک فروشگاه آنلاینه) خرید کنه ، آیا باید با یک حساب کاربری دیگه هم ثبت نام کنه ؟
ممکنه یکی از کاربرهای بعدا به سطح دسترسی بالاتری ارتقا پیدا کنه ، آیا باید جای دیگه ای ثبت نام کنه ؟

بعضی وقتها سایتها نیاز دارند که اطلاعات مفصلی از کاربر داشته باشند. مثلا یک سیستم خدمات رسانی به مشتری علاوه بر اطلاعات ایمیل کاربر نیاز به جزئیات خیلی بیشتری داره ولی برای مدیر این جزئیات نیاز نیست. در اینجا شما میتوانید از یک جدول جدا برای مشتری ها استفاده کنید. مدیر و مشتری ها هر دو کاربر هستند. و برای ورود از یک جدول استفاده میکنند ولی مشتری های یک رابطه ی یک به یک با جدول دیگری به نام Customers دارند.

استفاده از Role و بهتر از آن Claims تمامی نیازهای شما برای مدیریت کاربران و مدیران به صورت یک پارچه را برطرف میکند. و نیازی به جدا سازی آنها وجود ندارد.