15

Budując aplikację MVC3, a firma TPTB chce, abyśmy używali własnego dostawcy autoryzacji. Jednak w trakcie opracowywania tego dostawcy auth jest to trochę uciążliwe, ponieważ może spowodować błąd aż do wyłączenia/ponownego uruchomienia przeglądarki, lub będzie wymagać ponownego zalogowania się na każdej kompilacji.Ominąć lub wyłączyć [Authorize (Role = "")] podczas programowania?

Na razie właśnie dodałem <authentication mode="None"/> do web.config, który działa poprawnie dopóki nie napotkam akcji lub kontrolera, który używa filtru [Authorize(Roles = "Admin")] (może to być dowolna rola, a nie tylko Admin). Kiedy trafi jedną z nich, po prostu renderuje pustą stronę.

Czy istnieje sposób globalny i tymczasowo wyłączyć te filtry? Lub po prostu dać użytkownikowi wszystkie role, gdy jestem w fazie rozwoju?

EDIT

Pozwól clarify- ja rzeczywiście przenoszenie na dużej aplikacji z MVC2 do MVC3. Jest w nim mnóstwo wartości [Authorize(Roles="Admin")] i [Authorize(Roles="Admin,Editor")]. Wolałbym nie zmieniać tych wszystkich, jeśli to możliwe.

Czy powinienem po prostu utworzyć małego dostawcę niestandardowych ról, który automatycznie nadaje wszystkie role?

+1

odpowiedź Anri jest lepsza, ponieważ nie pozwalają na zastosowanie proxy HTTP wykorzystać, aby uzyskać prawa administratora na serwerze. – AgentFire

Odpowiedz

22

można napisać niestandardowy Autoryzacja filtr, który nie będzie wykonywał żadnych sprawdza, czy żądanie pochodzi od localhost:

public class MyAuthorizeAttribute : AuthorizeAttribute 
{ 
    protected override bool AuthorizeCore(HttpContextBase httpContext) 
    { 
     if (httpContext.Request.Url.IsLoopback) 
     { 
      // It was a local request => authorize the guy 
      return true; 
     } 

     return base.AuthorizeCore(httpContext); 
    } 
} 
+0

Dzięki, właśnie to zrobiłem. Szybko zdałem sobie sprawę, że wyszukiwanie/zamiana atrybutu Autoryzuj było dużo łatwiejsze niż cokolwiek innego, co rozważałem! –

+2

co z raczej sprawdzaniem Request.IsLocal? Myślę, że jest bardziej "kuloodporny". – mare

+0

Powinieneś dodać #if DEBUG wokół zwracanego całego bloku if - w przeciwnym razie otwierasz potencjalny problem utraty danych w produkcji. Co może powstrzymać nikczemnego administratora przechodzącego do IE w produkcji i pisania http://127.0.0.1/refundCC?CC=1234689&amount=infinity – stevieg

12

można dziedziczyć AuthorizeAttribute i oddzielnych realizacjami z dyrektywą #if DEBUG.

public class MyAuthorizeAttribute: AuthorizeAttribute 
{ 
#if DEBUG 
    protected override bool AuthorizeCore(HttpContextBase httpContext) 
    { 
     return true; 
    } 
#endif 
} 

Albo #define YOUR_OWN_FLAG włączyć zachowanie i wyłączać w dowolnej kompilacji, debugowania lub zwolnienia.

5

For Web API:

public class MyAuthorizeAttribute : System.Web.Http.AuthorizeAttribute 
{ 
    protected override bool IsAuthorized(HttpActionContext actionContext) 
    { 
     return actionContext.Request.RequestUri.IsLoopback || base.IsAuthorized(actionContext); 
    } 
} 
+0

Testowanie pętli zwrotnej jest niesamowite, haha, dlaczego nie pomyślałem o tym –

Powiązane problemy