Forum
Aktif konular
Üyeler
Kurallar
Arama
ASP.NET Mvc De Authorized In Rol Özelliğini Kullanmak ASP.NET Mvc De Authorized In Rol Özelliğini Kullanmak
-
Mvc 5 teki hazır üyelik sistemini kullanmıyorum. Proje başlarken hiç yaratılmasın dedim yani.Users diye bir sınıf yazdım kullanıcı adı ve şifre var kullanıcı istek yapınca controllerda bakıyorum eğer veritabanında varsa kullanıcı adı ve şifre FormsAuthentication.SetAuthCookie(kullaniciadi , false); diyerek cookie yaratıyorum. Bazı methodların baş kısmınada [authorized] yazdım üyelik gerektiren alanları bu şekilde yaptım.Ancak authorized in role özelliğini kullanmak için ne yapmam lazım?
-
yeni yeni anliyorum role provider sinifinda getrolesforusers diye bir fonksiyon var.biz bir controllerın tepesine yada actionmethod un uzerine
[authorized(roles="admin")] falan yazarsak bu getrolesforusers direk cagrilio.bu kendi kendine cagriliomus.onu farkettim. bizim yapmamiz gerekende bu getrolesforusers fonksiyonunu override etmek.bunun icine istedigimizi yazmak arastirmaya devam ediorum konuyla ilgili her türlü bilgiye açım.en son tespitlerimi topluca yazicam mvc ye yeni baslayan arkadaslar icin
-
yeni gordum sorunu hocam aynen oyle yapiyorsun,hatta username yazarak bile erisim verebilirsin. bu authorized in da customization u var, evde olsam ornek gonderirdim.. custom ile daha genis bir kontrol saglayabilirsin
edit: bu almanca klavyeye de bi alisamadim,
unbalanced tarafından 16/Tem/15 12:21 tarihinde düzenlenmiştir -
@unbalanced hocam dediğin şekilde authorized in de customization olayına baktım anladım olayı. Bu linkten okudum http://stackoverflow.com/questions/23055403/asp-net-mvc-user-authorize-in-controller burda adam verdiği örnekte her defasında database e gidiyo bu biraz sacma değilmi bi controllerın tepesine yada action method un tepesine custom bir authorized yazıcam sonra her gelen istekte ,ilgili authorized metodu calıscak metodun içindede veritabanına gitmiş bu linkteki örnekte.Onun yerine bi cookie yada sessiondan okusa daha mantıklı olmaz mı?
Birde custom role olayında getRolesForUsers metodunun çalışma seklini çözdüm ancak diğer metodlara bakamadım pek MembershipProvider ve RoleProvider sınıflarında yer alan diğer metotlar hangi durumlarda tetikleniyor ??
Ayrıca debug atarak denedim 4-5 defa public override string[] GetRolesForUser(string username) bu fonksıyon 2 defa arka arkaya çalışıyor.Eğer döndürdüğü string dizisinde method için gerekli rol varsa 1 kere çalışıyor.Ancak döndürdüğü rol dizisinde işe yarar rol yoksa aynı method tekrar çagrılıyor.
-
yazayımda konuyu kaybetmeyeyim. gece 12 den sonra eve gelince ufak bir örnekvari bir şey yollayayım geç olmadıysa..
Gerçi geç olduysa da daha sonra bu konuyu arayan biri görür gene iş görülür :) -
hocam mvc de yeniyim bende sorduğun olayı az çok anladım fakat kodları paylaşabilir misin sorun olmazsa veya örnek kod varsa elinde ?
-
Yarın yazayım hocam yaptığım tespitleri ve anladığım yerleri kodlarla birlikte.
Hannibal_King tarafından 20/Tem/15 03:02 tarihinde düzenlenmiştir -
Şimcik..
Bu yetki kontrolü yapmak istediğimiz Controller başına ya da Action başına yazdığımız [Authorize] zımbırtısı Controller/Action çalıştırılmadan bi çalışıyor. Temel olarak , doğrulama başarılı olursa Controller/Action çalışıyor, false gelirse çalışmıyor.
Bu kontrolü rol adları , yetki adları vs gibi şeylere göre yapabiliyoruz. Genelde örneklerde [Authorize(Roles="Admin"] olarak geçiyor. Authorize yerine kendi isimlendirdiğimiz halini kullanalım. Mesela, [TmzDemoYetkilendirme(TDEylemErisimIslemi = "{DB93B6CB-8320-4082-A9D2-13D03B239BBF}")] Niye Rol, Yetki vs gibi isim kullanmadığımızı da o kısımda göreceğiz.
Kendi kullandığımız şekliyle örnek koyayım. Senaryomuz düz mantıkla şöyle,
- kullanıcı login oluyo, şifre hede hödö doğruluk kontrolü yapılıyor sonucunda kullanıcının rollerini, ardından bu rollere bağlı yetkileri çekip session a gömüyoruz.
- Yekilendirme için kullancağımız bi sınıf ekliyoruz. (örnekte, TmzDemoYetkilendirme). Bunu “AuthorizeAttribute” ten türetip resimlerdeki gibi “AuthorizeCore” u override ediyoruz.
- Yetki kontrolü yapmak istedimiz Controller/Action dan önce kontrolümüzü yapıyoruz. (Örnekte ki hali => [TmzDemoYetkilendirme(TDEylemErisimIslemi = "{DB93B6CB-8320-4082-A9D2-13D03B239BBF}")]
Resimlerle örnekleyelim;
Resim : DB tarafı
DB tarafı : Rol tablomuz, Ekranlar için tablomuz(EkranEylem tablosu) ve bu iki tablonun eşleştirildiği bir tablomuz var.(EkranEylem_Rol. Aşağıdaki tablo, adı tam çıkmamış) Kullanıcının sahip olduğu rollerin yetkisi olan ekranları bu şekilde belirleyebiliyoruz. Böyle ara tablo vs yerine direk admin, kullanıcı vs gibi rol adları üzerinden de yetki kontrolü yapabiliriz aslında ama onun yerine EkranEylem tablosundaki “KimlikBilgisi” alanına bir guid basıp, bir rol için bir Action’a yetki ekleneceği zaman kodu açıp o Action’ın başına rol adı vs ekleme yapıp dekrar deploy atmaktansa , koda girmeden veritabanı üzerinden “X Rol_ID li kişiye Y EkranEylemID li 54xx54-xs6x6s7-x7sx yetkisini ver” işlemini yapabiliriz
Velhasıl gelelim kod tarafına. Önce bi login olalım.
Resim Login - Session
Login - Session : Login in post işleminde görüldüğü gibi Kullanıcının rolünü ve yetkiListesi olarakta o role ait yetkileri sessiona alıyoruz.
Resim : RoleBagliYetkiler
RoleBagliYetkiler : Rol_ID ile gidip Role bağlı yetkilerin, EkranEylem tarafındaki “KimlikBilgisi” bilgisini alıyoruz. Doğrulamayı bu alan üstünden yapıyoruz çünkü.
Resim : Custom sınıfımız
Custom sınıfımız : Yetki kontrolümüzü yapacağımız kendimize ait sınıfı resimdeki gibi ekliyoruz. Tabi bunu “AuthorizeAttribute” ten türetiyoruz. İçerisinde kontrol edeceğimiz değeri barındırsın diye bi yavrucak tanımlıyoruz. (Örnekte bu yavrucak “TDEylemErisimIslemi” )
Burada AuthorizeCore(HttpContextBase httpContext) ve HandleUnauthorizedRequest(AuthorizationContext filterContext) metotları var. Bunları override edicez sadece. AuthorizeCore yetki kontrolünü yaparken yapılacak şeyleri içerecek, “HandleUnauthorizedRequest” ise adı üstünde yetkisi olmayan yerlere gelen istekleri handle etmek için kullanacağımız yer. Artık kişiselleştirmek vs bize kalmış, sağına soluna bir şeyler ekleyerek vs J
Biraz hızlı oldu örnek, anca vakit bulabilip yazabildim kusura bakmayınuz. Eve geç gelip bir de film izleme sözüm olunca hızlı hızlı anca bu akdar hazırlayabildim bir şeyler.
Eksik ya da atladığım , adam gibi açıklayamadığım yer olursa sorar işi düşüpte bunu okuyan mürit :)
Şunu niye böyle yapıyon la mal şöyle yapsana daha mantıklı diyen varsa oda uyarırsa sevinirim :) Ek bilgi ek bilgidir :) -
Çok detaya boğulmak istemeyenler için webmatrix membership provider tavsiyemdir. oldukça basit bir kullanımı var.
-
MaviGozluDev bunu yazdı
Şimcik..
Bu yetki kontrolü yapmak istediğimiz Controller başına ya da Action başına yazdığımız [Authorize] zımbırtısı Controller/Action çalıştırılmadan bi çalışıyor. Temel olarak , doğrulama başarılı olursa Controller/Action çalışıyor, false gelirse çalışmıyor.
Bu kontrolü rol adları , yetki adları vs gibi şeylere göre yapabiliyoruz. Genelde örneklerde [Authorize(Roles="Admin"] olarak geçiyor. Authorize yerine kendi isimlendirdiğimiz halini kullanalım. Mesela, [TmzDemoYetkilendirme(TDEylemErisimIslemi = "{DB93B6CB-8320-4082-A9D2-13D03B239BBF}")] Niye Rol, Yetki vs gibi isim kullanmadığımızı da o kısımda göreceğiz.
Kendi kullandığımız şekliyle örnek koyayım. Senaryomuz düz mantıkla şöyle,
- kullanıcı login oluyo, şifre hede hödö doğruluk kontrolü yapılıyor sonucunda kullanıcının rollerini, ardından bu rollere bağlı yetkileri çekip session a gömüyoruz.
- Yekilendirme için kullancağımız bi sınıf ekliyoruz. (örnekte, TmzDemoYetkilendirme). Bunu “AuthorizeAttribute” ten türetip resimlerdeki gibi “AuthorizeCore” u override ediyoruz.
- Yetki kontrolü yapmak istedimiz Controller/Action dan önce kontrolümüzü yapıyoruz. (Örnekte ki hali => [TmzDemoYetkilendirme(TDEylemErisimIslemi = "{DB93B6CB-8320-4082-A9D2-13D03B239BBF}")]
Resimlerle örnekleyelim;
Resim : DB tarafı
DB tarafı : Rol tablomuz, Ekranlar için tablomuz(EkranEylem tablosu) ve bu iki tablonun eşleştirildiği bir tablomuz var.(EkranEylem_Rol. Aşağıdaki tablo, adı tam çıkmamış) Kullanıcının sahip olduğu rollerin yetkisi olan ekranları bu şekilde belirleyebiliyoruz. Böyle ara tablo vs yerine direk admin, kullanıcı vs gibi rol adları üzerinden de yetki kontrolü yapabiliriz aslında ama onun yerine EkranEylem tablosundaki “KimlikBilgisi” alanına bir guid basıp, bir rol için bir Action’a yetki ekleneceği zaman kodu açıp o Action’ın başına rol adı vs ekleme yapıp dekrar deploy atmaktansa , koda girmeden veritabanı üzerinden “X Rol_ID li kişiye Y EkranEylemID li 54xx54-xs6x6s7-x7sx yetkisini ver” işlemini yapabiliriz
Velhasıl gelelim kod tarafına. Önce bi login olalım.
Resim Login - Session
Login - Session : Login in post işleminde görüldüğü gibi Kullanıcının rolünü ve yetkiListesi olarakta o role ait yetkileri sessiona alıyoruz.
Resim : RoleBagliYetkiler
RoleBagliYetkiler : Rol_ID ile gidip Role bağlı yetkilerin, EkranEylem tarafındaki “KimlikBilgisi” bilgisini alıyoruz. Doğrulamayı bu alan üstünden yapıyoruz çünkü.
Resim : Custom sınıfımız
Custom sınıfımız : Yetki kontrolümüzü yapacağımız kendimize ait sınıfı resimdeki gibi ekliyoruz. Tabi bunu “AuthorizeAttribute” ten türetiyoruz. İçerisinde kontrol edeceğimiz değeri barındırsın diye bi yavrucak tanımlıyoruz. (Örnekte bu yavrucak “TDEylemErisimIslemi” )
Burada AuthorizeCore(HttpContextBase httpContext) ve HandleUnauthorizedRequest(AuthorizationContext filterContext) metotları var. Bunları override edicez sadece. AuthorizeCore yetki kontrolünü yaparken yapılacak şeyleri içerecek, “HandleUnauthorizedRequest” ise adı üstünde yetkisi olmayan yerlere gelen istekleri handle etmek için kullanacağımız yer. Artık kişiselleştirmek vs bize kalmış, sağına soluna bir şeyler ekleyerek vs J
Biraz hızlı oldu örnek, anca vakit bulabilip yazabildim kusura bakmayınuz. Eve geç gelip bir de film izleme sözüm olunca hızlı hızlı anca bu akdar hazırlayabildim bir şeyler.
Eksik ya da atladığım , adam gibi açıklayamadığım yer olursa sorar işi düşüpte bunu okuyan mürit :)
Şunu niye böyle yapıyon la mal şöyle yapsana daha mantıklı diyen varsa oda uyarırsa sevinirim :) Ek bilgi ek bilgidir :)attribute sınıfı nasıl yazılır ona bi bakmam gerek onun dışında anladım hocam daha önce attribute sınıfı yazmamıştım. onun dışında mantığı anladım saol hocam :)
-
@MaviGozluDev hocam gayet güzel açıklamış.Bende bişeyler yazacaktım ama gerek kalmamış gayet net anlatmış.1-2 soru sorayım bende.
1-) Login metodunda argüman olan string returnUrl kısmındaki returnUrl nerden geldi onu biz nerde tanımladık.Sistem nasıl anladı returnurl i
2-)kullanıcı başarı ile login olduktan sonra kullanıcı hakkında ekstra verılerı session da tuttuk.Ancak session ın bir timeout süresi var ve bu süre 20 dakika olsa eğer kullanıcı 19. dakikada site ile etkileşime girse dahisession kesinlikle yok olur diye biliyorum.Yani kendi kendine yenilenmiyor diye biliyorum.Bunun yerine formsauthentication extension isimli paketi indirdim nugettan.Bunda setauthcookie derken daha fazla parametre giriyoruz.Saklamak istediğimiz verileride koleksiyon şeklinde setauthcookie ye argüman olarak veriyoruz.Bunu denedim gayet güzel calısıo. ama sessionları kontrol etmeliyiz bence eger nullsa tekrar veritabanından verılerı cekmek lazım.
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla