ورود

View Full Version : حرفه ای: سطح دسترسی پویا



alireza_rashvand
سه شنبه 29 اردیبهشت 1394, 22:51 عصر
با سلام
اگر بخواهیم سطح دستری کاربران رو محدود کنیم معمولا به وسیله فیلتر زیر, رول هایی رو مدیریت می کنیم.

[Authorize(Roles="Admin")]
ولی اگر بخواهیم پویا عمل کنیم چطور؟

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

از دوستان اگر کسی این چنین سطح دسترسی رو در پروژه اش پیاده کرده یا می دونه چطور باید انجام داد یا نکاتش رو می دونه خواهش می کنم کمک کنند.

ali_72
چهارشنبه 30 اردیبهشت 1394, 07:55 صبح
سلام
کاری که خودم انجام دادم این بود
اول اینکه یک جدل میسازم برای تعیین نوع عملیات insert-delete-update , ...
یه جدول دیگه دارم که اسم مدل هام توشه مثلا product - news و ....
یک جدول role هم که دارم
یه جدول واسط دارم که میگم فلان role اجازه این سری عملیات رو برای این سری مدل داره
تو کنترلرهام هم بررسی میکنم کاربر لاگین کرده اجازه عملیات رو داره یا نه
رو این قسمت کار کنی میتونی یه چیز تمیز برای همه پروژه هات بسازی
در مورد همه پروژه هام قسمت ادمین این قسمت رو اول اضافه میکنم بعد مابقی کارا پروژه انجام میدم

alireza_rashvand
پنج شنبه 31 اردیبهشت 1394, 18:12 عصر
جالب بود سپاس, هنوز برام گنگه.

مثلا اگر من بخواهم یک رول بسازم بعد به این فکر کنم این رول امکان ثبت نام داشته باشه.
خوب ما برای ثبت نام یک کنترلر(1) داریم اکشنی(2) داره که نهایت به یک ویو(3) می رسیم که یک صفحه رو برای ما نمایش میده
اگه بخواهم اجازه بدم که این فرد به این صفحه دستری داشته باشه باید چطور اطلاعات رو در دینتابیس ذخیره کنم
که 1- منو این فرد لینکی به این صفحه بده.
2- فرد بتونه وارد این صفحه بشه.(یا دیگران نتونند)

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


ببخشید اگر سوالم دقیق نیست چون هنوز خودم موضوع رو دقیق متوجه نشدم

ali_72
پنج شنبه 31 اردیبهشت 1394, 20:19 عصر
یه جدول داریم لیست عملیاتی که داری رو توش میذاری (مثلا insert - delete - update - , ....)
یه جدول داری اسم مدل هات توشه (product - account , ...)
یه جدول داری که لیست role هات توشه (و ...user - support - modir)
من یه جدول دارم که منوهام توشه که شامله id عکلیات - id مدل و مابقی مشخصاته
یه جدول دارم که شامل id role و id جدول قبلی هست
باید ActionFilterAttribute تعریف کنی و اونجا بررسی کنی که کاربری که لاگین کرده حق استفاده از اکشن مورد نظرش رو داره یا نه
امیدوارم تونسته باشم کمکی کنم

mudur2
شنبه 02 خرداد 1394, 12:29 عصر
با سلام
اگر بخواهیم سطح دستری کاربران رو محدود کنیم معمولا به وسیله فیلتر زیر, رول هایی رو مدیریت می کنیم.

[Authorize(Roles="Admin")]
ولی اگر بخواهیم پویا عمل کنیم چطور؟

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

از دوستان اگر کسی این چنین سطح دسترسی رو در پروژه اش پیاده کرده یا می دونه چطور باید انجام داد یا نکاتش رو می دونه خواهش می کنم کمک کنند.


دوست عزیر به سر به این (http://stackoverflow.com/questions/13574268/asp-net-dynamic-role-based-operation-access)تاپیک بزن، مشکل منو که کل کرد

alireza_rashvand
یک شنبه 03 خرداد 1394, 17:27 عصر
یه جدول داریم لیست عملیاتی که داری رو توش میذاری (مثلا insert - delete - update - , ....)
یه جدول داری اسم مدل هات توشه (product - account , ...)
یه جدول داری که لیست role هات توشه (و ...user - support - modir)
من یه جدول دارم که منوهام توشه که شامله id عکلیات - id مدل و مابقی مشخصاته
یه جدول دارم که شامل id role و id جدول قبلی هست
باید ActionFilterAttribute تعریف کنی و اونجا بررسی کنی که کاربری که لاگین کرده حق استفاده از اکشن مورد نظرش رو داره یا نه
امیدوارم تونسته باشم کمکی کنم

با اطلاعاتتان در دو کامنت قبل به این نتیجه رسیدم که شما می فرمایید
باید همچین شرطی را بتوان بررسی کرد ؟

bool set = checking(Insert, News, UserId);


if(set){}

یعنی به تابع مورد نظر(checking): نوع عملیات (مثال ثبت) و نام مدل(خبر) و id كابر رو بدیم و اون مشخص کنه اجازه داره یا نه

درسته؟

یعنی ما باید یک دیتابیس داشته باشیم که شامل فیلد های زیر بشه:
1- id رول
2- id عمليات
3- id مودل

اگر تا اینجا درست گفتم و یا اشکالی در فهمم بود لطفا بگید... متاسفانه هنوز منو رو متوجه نشدم لطفا منو رو بیشتر توضیح بدید.

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

sanay_esh
سه شنبه 05 خرداد 1394, 13:22 عصر
براحتی میتوانید از CustomActionFilterAttribute , CustomAuthorizeAttribute استفاده کنید.
با کمی جستجو به لینکهای مفیدی هم در سایت جاری و هم در سایتهای مختلف خواهید رسید.

ali_72
پنج شنبه 07 خرداد 1394, 10:59 صبح
با اطلاعاتتان در دو کامنت قبل به این نتیجه رسیدم که شما می فرمایید
باید همچین شرطی را بتوان بررسی کرد ؟

bool set = checking(Insert, News, UserId);


if(set){}

یعنی به تابع مورد نظر(checking): نوع عملیات (مثال ثبت) و نام مدل(خبر) و id كابر رو بدیم و اون مشخص کنه اجازه داره یا نه

درسته؟

یعنی ما باید یک دیتابیس داشته باشیم که شامل فیلد های زیر بشه:
1- id رول
2- id عمليات
3- id مودل

اگر تا اینجا درست گفتم و یا اشکالی در فهمم بود لطفا بگید... متاسفانه هنوز منو رو متوجه نشدم لطفا منو رو بیشتر توضیح بدید.

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

بله تا اینجا داری درست حرکت میکنی
درباره
ActionFilterAttribute تحقیق کن اینو باید بلد باشی
اون مدل ها رو هم بساز منو هم شامل id amaleyat و id model و text منو و url و ... است

alireza_rashvand
جمعه 08 خرداد 1394, 17:57 عصر
سوالي که برام در مورد منو پیش اومده و هنوز حل نشده اینه: (می خوام از دید کاربر بگم تا موضوع روشن بشه)
ما یک صفحه مدیریت کاربران ایجاد می کنیم درونش مشخص می کنیم که این کاربر چه کاری می تونه بکنه (چه نوع مودلی با چه نوع عملیاتی مثلا : ثبت خبر, حذف خبر, ویرایش خبر)

تا اینجا مشکلی نیست ولی می خوام ببینم از این جدول (1-id رول,2- id عمليات, 3- id مودل) می شه منوی کاربر رو دراورد یا نه.
من فکر می کنم باید یک جدول دیگه داشته باشیم که درونش: id مودل, id عمليات , نام کنترلر, نام اکشن داشته باشیم و جدول قبلی رو به این صورت در بیاریم
1- id كاربر
2- id رول
3- id جدول قبلی

کاربر مدیر هم از جدول بالا مثلا ثبت خبر رو انتخاب می کنه و در پس ماجرا به ما هم کمک میکنه تا منو رو بسازیم.

پس به صورت خلاصه:
جدولی ایجاد می کنیم که درونش عملیات(1) مورد نظر برسر مودل(2) مورد نظر همراه با کنترلر(3) و اکشن(4) ان رو پر می کنیم و در جدول بعد در کنار id كاربر, id رول و id جدول ایجاده شده می ریزیم هم سطح دستری کاربر رو مشخص کردیم هم منو رو می تونیم بسازیم.

نظرتون چیه؟
(دوستان دیگر هم اگر نظر دارند لطفا بیان کنند تا به یک طرح پخته برسیم)

ali_72
شنبه 09 خرداد 1394, 08:49 صبح
علیرضا جان قدم اول رو بردار و مدل هات به دقت رو برگه یا هر طور دوست داری پیاده سازی کن
اطلاعات پر کن اونوقت متوجه کم و کسری ها می شی
بعدش پیادسازی کن تو برنامه
اگه دوست داشتی کلاس های پیاده سازی شده در برنامتو می تونی اینجا بذاری دوستان هم فکری کنن
حالا نویته اونه که از اینا استفاده کنی برای اعمال سطح دسترسی اونوقته که میرسی به ActionFilterAttribute

دربارش تحقیق کن و اگه مشکل برخوردی اینجا مطرح کن

alireza_rashvand
یک شنبه 10 خرداد 1394, 00:48 صبح
علي جان قدم اولی که می گید همین تاپیک دیگه :)
یعنی برگه من , همین تاپیکه.

با ActionFilterAttribute مشکلی ندارم, اصل اینکه متوجه ایده اصلی(مودل طراحی) بشم , در پیاده سازی همه کار می شه کرد همه کد ها و مثال هایی که می زنم فقط برای روشن شدن موضوعه وگرنه تو پیاده سازی ایده , می شه هر کاری کرد...

به هر حال از شما تشکر می کنم واقعا فکرم رو باز کردید, سپاس
اگر در راه پیاده سازی به مشکلی خوردم حتما بیان می کنم تا به یک نتیجه خوب برسیم و دیگران هم از این تاپیک استفاده کنند ان شا لله.

salar IT man
یک شنبه 10 خرداد 1394, 09:50 صبح
این لینک http://dotnetexpert.ir/Blog/1394/1/17/%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%85%D8%AF%D9%84-aspnet-identity-20 با استفاده از Asp.net Identity
این لینک http://www.dotnettips.info/projects/details/19 با استفاده از Forms Authentication

alireza_rashvand
یک شنبه 10 خرداد 1394, 23:48 عصر
سلام و سپاس لینک های مفیدی است
لینک اول صرفا ایجاد یک رابط(گروه) بین کاربر و رل هاست با بحث ما فرق می کنه.
لینک دوم رو نتونستم دانلود کنم اگر شما استفاده کردید لطفا خلاصه ایده ای که اجرا کرده رو بگید.

salar IT man
دوشنبه 11 خرداد 1394, 14:42 عصر
سلام و سپاس لینک های مفیدی است
لینک اول صرفا ایجاد یک رابط(گروه) بین کاربر و رل هاست با بحث ما فرق می کنه.
لینک دوم رو نتونستم دانلود کنم اگر شما استفاده کردید لطفا خلاصه ایده ای که اجرا کرده رو بگید.

دوست عزیز وقتی سیستم شما بزرگ شود لازم است جدول گروه هم اضافه شود.
میتوانید به صورت زیر عمل کنید
در کل سناریو به این صورت است که یک جدول Users , یک جدول Permissions (همان رول ها) , یک جدول Groups و ارتباط های n به n بین جداول Users و Groups و همچنین Permissions و Groups خواهد بود به این شکل:
ایده این است که اگر ما Action ای به شکل زیر داشته باشیم:


[CustomAuthorize(Roles="EditProduct")]
[DisplayName("ویرایش کالا")]
[HttpGet]
public ActionResult EditProduct(int productId){


// Todo


}


[CustomAuthorize(Roles="EditProduct")]
[DisplayName("ویرایش کالا")]
[HttpPost]
public ActionResult EditProduct(EditProductViewModel viewModel){


// Todo


}


میتوان با استفاده از Reflection در هنگام اولین اجرا ، تمام نقش های مربوط به Attribute مشخص شده را به عنوان Permissions ثبت کرد
در واقع مدیریت باید گروه را به صورت داینامیک اضافه کند و به صورت دستی Permissions ها را اضافه نمیکند فقط هر گروه را که اضافه میکند ، Permission هایش را هم ست میکند.

و کاربر مورد نظر را به گروه مربوطه نسبت میدهید.

در داخل CustomAuthorize هم تمام گروه های کاربری کاربر مورد نظر را میکشید بیرون و تمام نقش های مربوط به تمام گروه های او را میتوانید بررسی کنید که آیا میتواند به صفحه مورد نظر دسترسی داشته باشد یا خیر.

بحث شما سطح دسترسی پویا بود و این روشی است که الان خیلی از CMS های بزرگ هم از آن استفاده میکند.
شما مقالاتی که دادم رو خوب مطالعه نکردید!

اینجا رو ببینید http://typecastexception.com/post/2014/08/10/ASPNET-Identity-20-Implementing-Group-Based-Permissions-Management.aspx

اینجا http://typecastexception.com/post/2014/02/19/ASPNET-MVC-5-Identity-Implementing-Group-Based-Permissions-Management-Part-I.aspx
اینجا http://typecastexception.com/post/2014/02/19/ASPNET-MVC-5-Identity-Implementing-Group-Based-Permissions-Management-Part-II.aspx

سورس https://github.com/rabbal/AspNetGroupBasedPermissions

اینم پروژه که خودم به صورت CMS و pluggable توسعه میدم از همین روش استفاده میکنم.https://github.com/rabbal/RabbalShopCMS




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

alireza_rashvand
جمعه 15 خرداد 1394, 19:15 عصر
از شما بازهم تشکر می کنم بسيار مفيد بود.

مقاله ای که دادید رو خونده بودم و حرف های شما هم دقیقا همان حرف ها بود.

با توضیحی که اقای ali_72 (http://barnamenevis.org/member.php?156215-ali_72) دادند در نهایت به این نتیجه رسیدم که باید به این صورت عمل کرد.
جدول Role که داریم یک جدول به نام مودل ها و یک جدول عملگر ها (که ID مودل ها درونش قرار می گیره) اضافه می کنیم.
و در اخر یک جدول دیگر ایجاد می کنیم, که درونش ID رلو و ID جدول عملگرها قرار می گیره ....

بنابرین کافیه بررسی کنیم role که کاربر داره درون این جدول با عملگر مورد نظر هست یا نه.

این خلاصه تمام گفتگو های قبلی بود...


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

1- در جدول مجوزها تمام مجوز های رو ثبت می کنیم مثل ثبت کالا.
2- و بعد در جدول گروه یک گروه معرفی می کنیم(مثلا Admin) و در یک جدول واسط(B_GroupInRole) بین مجوز ها و گروه, تمام مجوز های این گروه رو به او می دهیم به نظرم باید به این جدول Group با این شرایط گفتم Role.
3- بعد هم با یک جدول رابط دیگه بین کاربر و گروه , تمام رل های کاربر رو به او می دیم.

این تحلیل است که بنده از گفته شما و ان مقاله که لینکش را دادید درک کرده ام
(و بر همین اساس در کامنت قبل عرض کردم چیزی جز یک واسط نیست)...

اگر تمایل داشتید بفرمایید ایا برداشتم درست بوده یا نه؟

اگر تحلیل بنده درست باشه نیاز به این همه تغییر همان طور که مقاله انجام داده نیست.
بصورت پیش فرض بین جدول AspNetRoles و جدول AspNetUsers جدولی واسطه به نامAspNetUserRoles وجود داره , به نظرم کافیه یک جدول Permissions ایجاد کنیم و همه مجوز ها رو درونش ثبت کنیم و یک جدول واسط داشته باشیم که به یک Role همه مجوز های مورد نیاز داده بشه.


تا قبل از این تاپیک هیچ شناخت و اگاهی از این موضوع نداشتم ولی به لطف دوستان حداقل به یک درک نسبی رسیدم و حتما این تاپیک به کار دیگر دوستان که سوال بنده را خواهند داشت خواهد امد.

salar IT man
جمعه 15 خرداد 1394, 19:56 عصر
کامنتی که بنده در همان مقاله گذاشته بودم دقیقا همین تحلیلی است که در آخر پست خود مطرح کرید :http://dotnetexpert.ir/Blog/1394/1/17/%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%85%D8%AF%D9%84-aspnet-identity-20#comment1


فقط روشی که در ابتدای پست مطرح کردید کار اضافه دارد. نیاز به جدول مدل نیست ! شما فقط یک جدول Permission اضافه کنید یا اینکه جدول Role موجود به عنوان جدول Permission باشد و یک جدول گروه کاربری(Group) در نظر بگیرید.

دلیل استفاده از جدول اضافه را هم گفتم!
بقیه اش سلیقه ای است.

alireza_rashvand
شنبه 16 خرداد 1394, 13:00 عصر
فقط روشی که در ابتدای پست مطرح کردید کار اضافه دارد. نیاز به جدول مدل نیست !
دلیل استفاده از جدول اضافه را هم گفتم!
بقیه اش سلیقه ای است.

بله, حق با شماست.
سپاس از همه دوستان.

alireza_rashvand
چهارشنبه 20 خرداد 1394, 18:07 عصر
با سلام دوباره
مقاله
Group-Based (http://typecastexception.com/post/2014/08/10/ASPNET-Identity-20-Implementing-Group-Based-Permissions-Management.aspx) رو مطالعه کردم برام سوال پیش اومده اگر دوستان می تونند لطفا کمک کنند.

تو مقاله برای ربط دادن Role به Group از این کد استفاده کرده



// Map Roles to Groups:
modelBuilder.Entity<ApplicationGroup>()
.HasMany<ApplicationGroupRole>((ApplicationGroup g) => g.ApplicationRoles)
.WithRequired()
.HasForeignKey<string>((ApplicationGroupRole ap) => ap.ApplicationGroupId);
modelBuilder.Entity<ApplicationGroupRole>().HasKey((ApplicationGroupRole gr) =>
new
{
ApplicationRoleId = gr.ApplicationRoleId,
ApplicationGroupId = gr.ApplicationGroupId
}).ToTable("ApplicationGroupRoles");




ولی به نظرم (به صورت عملی هم تست کردم) این کد فقط رابطه جدول ApplicationGroup با جدول ApplicationGroupRoles رو بر قرار می کنه نه گروه با رل.!
اگه قرار باشه رل به گروه وصل بشه باید هر دو جدول به جدول واسط وصل بشند در حالی که این کد فقط گروه رو به جدول واسط وصل می کنه.

اگر اشتباه کردم بفرمایید ولی اگر درست گفتم لطفا دوستان بفرمایند برای ارتباط دادن جدول ApplicationGroupRoles (واسط) به Role مقاله چه کار کرده؟!


سپاس.

salar IT man
چهارشنبه 20 خرداد 1394, 20:27 عصر
با سلام دوباره
مقاله
Group-Based (http://typecastexception.com/post/2014/08/10/ASPNET-Identity-20-Implementing-Group-Based-Permissions-Management.aspx) رو مطالعه کردم برام سوال پیش اومده اگر دوستان می تونند لطفا کمک کنند.

تو مقاله برای ربط دادن Role به Group از این کد استفاده کرده



// Map Roles to Groups:
modelBuilder.Entity<ApplicationGroup>()
.HasMany<ApplicationGroupRole>((ApplicationGroup g) => g.ApplicationRoles)
.WithRequired()
.HasForeignKey<string>((ApplicationGroupRole ap) => ap.ApplicationGroupId);
modelBuilder.Entity<ApplicationGroupRole>().HasKey((ApplicationGroupRole gr) =>
new
{
ApplicationRoleId = gr.ApplicationRoleId,
ApplicationGroupId = gr.ApplicationGroupId
}).ToTable("ApplicationGroupRoles");




ولی به نظرم (به صورت عملی هم تست کردم) این کد فقط رابطه جدول ApplicationGroup با جدول ApplicationGroupRoles رو بر قرار می کنه نه گروه با رل.!
اگه قرار باشه رل به گروه وصل بشه باید هر دو جدول به جدول واسط وصل بشند در حالی که این کد فقط گروه رو به جدول واسط وصل می کنه.

اگر اشتباه کردم بفرمایید ولی اگر درست گفتم لطفا دوستان بفرمایند برای ارتباط دادن جدول ApplicationGroupRoles (واسط) به Role مقاله چه کار کرده؟!


سپاس.

کاری که ایشون انجام داده یه یه جورایی خلاف شی گرایی هستش . میدونم چی میگید ولی در اصل موضوع فرقی نداره بیشتر برای این کار رو کرده چون عملیات ویرایش ارتباط های n به n (کار زمانبری است (http://www.dotnettips.info/post/1235/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%AA%D9%81%D8%B5%DB%8C%D9%84%DB%8C-%D8%B1%D8%A7%D8%A8%D8%B7%D9%87-many-to-many-%D8%AF%D8%B1-ef-code-first))فعلا با کتابخانه های ثالث امکان پذیره مانند GraphDiff . چون نیاز نداشته که با استفاده از گروه به رول ها برسه دیگه این ارتباط رو ایجاد نکرده یه جوری سلیقه ای عمل کرده ولی استاندارد که نیس! به جای استفاده از Navigation Property ها اون داره سرچ میزنه و رول های مربوط به گروه رو واکشی میکنه ، ....

در ورژن قبل به صورتی که مد نظر شماست عمل کرده :http://typecastexception.com/post/2014/02/19/ASPNET-MVC-5-Identity-Implementing-Group-Based-Permissions-Management-Part-I.aspx

ولی با این حال چون داریم یه سیستم دیگه رو برای خواسته خودمون تغییر میدیم اصولا کار هم استاندارد نیس چرا؟ چون اصلا در تحلیل که انجام میشه اصلا ارتباطی بین یوزر و رول(permission) معنی نداره و ما در اینجا این کار رو برای اینکه این ارتباط به صورت پیش فرض موجود است قبول میکنیم
:لبخندساده:

درکل فقط ایده رو گرفتید دیگه کافیه....
با خودتونه به چه شکل پیاده کنید.

alireza_rashvand
پنج شنبه 21 خرداد 1394, 01:39 صبح
سپاس.

چون نوشته بود Map Roles to Groups فکر کردم واقعا وصل کرده پس عملا گروه رو نه به کاربر وصل کرده و نه به رل .

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

کد ها رو برای دوستان مثل خودم مبتدی, می ذارم تا نحوه ارتباط رو یاد بگیریم.
کلاس زیر برای ارتباط رل و مجوز


public class Role : IdentityRole
{
public virtual ICollection<Permissions> Permissions { get; set; }
}



و این کد در انتهای کلاس مجوز برای ارتباط با رل.


public virtual ICollection<Role> Role { get; set; }



و این کد در کلاس ApplicationDbContext برای ایجاد جدول واسط


public class PermissionsMap : EntityTypeConfiguration<Permissions>
{
public PermissionsMap()
{
this.HasMany(x => x.Role)
.WithMany(x => x.Permissions)
.Map(map =>
{
map.MapLeftKey("RoleId");
map.MapRightKey("PermissionId");
map.ToTable("RolePermission");
});
}
}


protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Configurations.Add(new PermissionsMap());
base.OnModelCreating(modelBuilder);
}




فعلا متصل کردم تا ببینم در قدم های بعد چه اتفاقی می افته