در مورد دسترسی‌های داینامیک تعداد اندکی مقاله در نت موجود است . بنده هم آنها را مطالعه کرده ام .
ابتدا سورس
SmartStore را بررسی کردم و پیاده هم کردم .. ولی روشی استاتیک داشت و با افزودن هر اکش و کنترلر باید به صورت دستی آنها را در
قسمت مربوطه اضافه میکردید. خب به هر حال دید خیلی خوبی برای ادامه آموزش
ساخت برنامه ای با قابلیت پلاگین پذیری ، به بنده داد(حتما وصله ای برای آن ارائه خواهم کرد).
در پروژه
IRISMembership به این سلسله مراتبی در نظر گرفته شده بود هر دو جدول مدل Permission و Role ،
به این روش هم پیاده کردم ولی همان اواسط کار منصرف شدم از این کار.
دلایل:
1-نهایت عمق درخت مربوط به Permissionها 1 خواهد بود ، چرا که اگر کنترلر را پدری برای Actionها در نظر بگیریم همینجا درخت ما با برگ هایی از نوع Actionهای ما به نهایت عمق خود خواهد رسید.بس دلیلی نداد خود را درگیر مباحث مربوط به مدل‌های خود ارجاع کنیم.
2-منطقی است که Roleها یا همان گروه‌های کاربری مد نظر ما در پروژه به صورت چند سطحی باشد ولی با این حال بنده در این پروژه همچین قصدی ندارم.
روشی که آن را پیاده کردم در نهایت :
مدل‌های Permission ، Role و User هر سه با هم به صورت چند به چند مرتبط شده اند.ارتباط Permission و Role طبیعی است. من تصمیم گرفتم که این امکان هم باشد تا به صورت مستقیم ، یک دسترسی را به کاربری نسبت دهیم ، لذا ارتباط چند به چند مابین User و Permission به این دلیل است.
در
ابتدای کار تمام کنترلر هایی را که مزین به
[MVCAuthorize] و [DisplayName] هستند را واکشی کرده و سپس Actionهای مربوط به آنها را همینطور.
دسترسی‌های ما همان Actionهای موجود خواهد بود. مسئله ای که در تمام مقالات هم که به صورت داینامیک ارائه شده اشاره نشده است این بود:
برخی از اکش‌ها وابسته به اکشن‌های دیگر هستند. مثلا اکشن CheckUserName را در نظر بگیرید ، این اکشن هم در ثبت کاربر هم در ویرایش آن نقش ایفا میکند. اولین چیزی که به ذهن خودم هم رسید این بود که همان روش سلسله مراتبی .. اما تصمیم گرفتم به پراپرتی تحت عنوان DependeciesActionNames در فیلتر شخصی سازی شده پروژه قرار دهم . این پراپرتی در واقع برای Action هایی که توسط سایر اکشن‌ها مورد استفاده قرار میگیرند ، مقدار دهی خواهد شد. مثلا اکش مربوط به CheckUserName به صورت زیر خواهد بود.
[MvcAuthorize(DependencyActionNames = "Edit,Create")]
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]
public virtual JsonResult UserNameExist(string userName, int? id)
ولی بقیه اکشن‌ها به این فیلتر مزین نیستند و فقط
کنترلر مربوطه مزین است ، چون آنها به عنوان Permission در سیستم ثبت شده اند. زمانی که درخواستی به این اکشن UserNameExist میرسد ، در فیلتر MVCAuthorizeAttribute چک خواهد شد که آیا این کاربر به
DependencyActionNames ها آن دسترسی دارد یا خیر..
آیا ایده دیگری دارند دوستان؟ یا مشکلی در این تحلیل است لطفا نظر بدید.
