2010-01-26 12 views
7

Po przejrzeniu sekcji MVC na CodePlex zauważyłem, że atrybut [Authorize] w MVC zwraca HttpUnauthorizedResult(), gdy autoryzacja się nie powiedzie (codeplex AuthorizeAttribute class).MVC Autoryzuj atrybut + HttpUnauthorizedResult + FormsAhentication

W źródle HttpUnauthorizedResult() z CodePlex jest kod (nie mam pozwolenia na wpisanie innego adresu URL, ponieważ mój przedstawiciel nie jest wystarczająco wysoki, ale zastępuje numery z powyższego adresu URL numerem 22929 # 266476):

// 401 is the HTTP status code for unauthorized access - setting this 
// will cause the active authentication module to execute its default 
// unauthorized handler 
context.HttpContext.Response.StatusCode = 401; 

W szczególności komentarz opisuje domyślny nieautoryzowany moduł obsługi modułu uwierzytelniania.

Nie mogę znaleźć żadnych informacji na temat tego domyślnego nieautoryzowanego programu obsługi. W szczególności nie używam FormsAuthentication i gdy autoryzacja nie powiedzie się, otrzymuję nieprzyjemną stronę błędu IIS 401.

Czy ktoś wie o tym domyślnym nieautoryzowanym module obsługi, a w szczególności o tym, w jaki sposób funkcja FormsAuthentication włącza się, aby go zastąpić?

Piszę bardzo prostą aplikację dla mojej drużyny piłkarskiej, która potwierdza lub zaprzecza, czy może zagrać konkretny mecz. Jeśli włączę FormsAuthentication w web.config przekierowanie działa, ale nie używam FormsAuthentication i chciałbym wiedzieć, czy istnieje obejście.

+0

Jakiego rodzaju uwierzytelniania używasz? – Zote

+0

Czy chcesz w ogóle autoryzować? Jaki jest wynik końcowy, jeśli chodzi o uwierzytelnianie? –

+1

Napisałem swój własny mały moduł uwierzytelniania, który przypisuje Tożsamość i Role. [Autoryzuj] musi sprawdzić, czy użytkownik może odwiedzić stronę, aby potwierdzić, że może grać w konkretnym meczu. Jeśli nie mogą grać w oparciu o rolę, zamiast podawać błąd 401, który jest całkiem nieużyteczny, chcę dać im więcej użytecznych informacji o tym, dlaczego nie mogą grać. Przesłonięcie tego 401 wydaje się logicznym sposobem na zrobienie tego, ale jestem zaskoczony, jak mało jest dokumentacji o tym domyślnym nieautoryzowanym handlerku – Anthony

Odpowiedz

11

Jeśli masz Reflektor, spójrz na System.Web.Security.FormsAuthenticationModule.Init(). Ta metoda przechwytuje Application_EndRequest i wywołuje OnLeave(). Metoda OnLeave() sprawdza, czy kod odpowiedzi to HTTP 401. Jeśli tak, to moduł wykonuje przekierowanie zamiast bulgotania 401 do klienta. (Ta logika jest tym, co ten komentarz nazywa "domyślnym nieautoryzowanym handler'em"). W twoim konkretnym przypadku ASP.NET pozwala bąblowi 401 na klienta, ale IIS przechwytuje go i wyświetla brzydką stronę błędu.

Możesz zrobić coś bardzo podobnego z poziomu Global.asax. Utwórz metodę Application_EndRequest; ta metoda zostanie wywołana na końcu każdego żądania obsługiwanego przez Twoją aplikację. Stąd możesz robić, co chcesz. Jeśli chcesz sprawdzić, czy odpowiedź to 401 i przekierować je na inną stronę, możesz to zrobić tutaj.

+0

Dzięki Levi - tak naprawdę nie użyłem Reflektora, ale przyjrzę się temu. Powinienem był podejrzewać, że mogło to być coś zahaczającego o zdarzenie EndRequest, choć wydaje się dość nieporządnym sposobem wykonania przekierowania. Domyślam się, że inną opcją byłoby utworzenie niestandardowej klasy autoryzacji, która w przypadku niepowodzenia autoryzacji wywoła inną metodę niż HttpUnauthorizedResult(), która może zwrócić inną akcję ActionResult (która może być stroną z informacją o niepowodzeniu autoryzacji)? – Anthony

+1

To by działało. Jeśli podążasz tą trasą, podklas AuthorizeAttribute i nadpisaj metodę HandleUnauthorizedRequest(). Jedyną realną korzyścią z zahaczenia EndRequest jest to, że zaszyfrowanie EndRequest pozwala przechwytywać awarie autoryzacji z innych części aplikacji, a nie tylko [Authorize]. – Levi

+0

Myślę, że zahaczenie EndRequest brzmi jak lepsze wykorzystanie czasu, ponieważ, jak mówisz, może obejmować więcej aplikacji.Czytałem również o AuthorizeAttribute i potencjalnych problemach z buforowaniem wyjściowym - jest nawet komentarz na ten temat w źródle codeplex, chociaż w rzeczywistości, jeśli mam czas, to chyba nie zaszkodzi by zrobić oba rodzaje autoryzacji. Chociaż zacznę od EndRequest. Dzięki za pomoc Levi. – Anthony

Powiązane problemy