2014-10-08 17 views
6

Używam Microsoft.Owin.Security w mojej aplikacji (ASP.NET MVC v 5.2.0 na .NET 4.5). Ale tylko część bezpieczeństwa OWIN nic więcej. Gdy użytkownik chce uzyskać dostęp do chronionego adresu URL, w lokalnym, żądanie zostanie przekierowane na stronę logowania. Ale kiedy opublikować aplikację na serwerze, mam to okno zamiast przekierowania:Microsoft.Owin.Security.IAuthenticationManager nie przekierowuje do strony logowania

enter image description here

mój login i metody wylogowania są:

public void LogIn(long userId, string username, string email, bool persistent) { 
    var claims = new List<Claim>{ 
     new Claim(ClaimTypes.NameIdentifier, userId.ToString(CultureInfo.InvariantCulture)), 
     new Claim(ClaimTypes.Name, username), 
     new Claim(ClaimTypes.Email, email), 
     new Claim(ClaimTypes.IsPersistent, persistent.ToString()) 
    }; 
    var id = new ClaimsIdentity(claims, DefaultAuthenticationTypes.ApplicationCookie); 
    var ctx = HttpContext.Current.Request.GetOwinContext(); 
    var authenticationManager = ctx.Authentication; 
    authenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie); 
    authenticationManager.SignIn(new AuthenticationProperties { 
     IsPersistent = persistent 
    }, id); 
} 

public void LogOut() { 
    var ctx = HttpContext.Current.Request.GetOwinContext(); 
    var authenticationManager = ctx.Authentication; 
    authenticationManager.SignOut(); 
} 

i tu jest mój startup:

public partial class Startup { 
    public void ConfigureAuth(IAppBuilder app) { 
     app.UseCookieAuthentication(new CookieAuthenticationOptions { 
      AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
      LoginPath = new PathString("/account/log-in/"), 
      AuthenticationMode = AuthenticationMode.Active, 
      CookieHttpOnly = true, 
      CookieName = ".some-cookie-name", 
      ExpireTimeSpan = TimeSpan.FromDays(1), 
      LogoutPath = new PathString("/account/log-out/"), 
      SlidingExpiration = true, 
      ReturnUrlParameter = "continue" 
     }); 
    } 
} 

ja też mam ten wiersz w global.asax::Application_Start metody:

AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier; 

i ich konfiguracja w web.config:

<system.web> 
    <authentication mode="None" /> 
    <httpModules> 
    <remove name="FormsAuthenticationModule" /> 
    <remove name="RoleManager" /> 
    </httpModules> 
</system.web> 
<system.webServer> 
    <validation validateIntegratedModeConfiguration="false" /> 
    <modules runAllManagedModulesForAllRequests="false"> 
    <remove name="FormsAuthenticationModule" /> 
    <remove name="RoleManager" /> 
    </modules> 
</system.webServer> 

i wreszcie mam uruchomioną aplikację na 2008 R2 maszynie Windows z IIS 7.5. Czy masz pojęcie, co powinienem zrobić, aby OWIN działał poprawnie na moim serwerze, tak jak mój lokalny?

UPDATE: Żeby było jasne:

Przyjmijmy, mam następujące działania:

[AllowAnonymous] 
public ActionResult AnonymousAction() { } 

[Authorize] 
public ActionResult UsersAction() { } 

Jeden dla anonimowych użytkowników, a inny dla zalogowanych użytkowników (które są dobrze urządzone z atrybutami). Anonimowi użytkownicy mogą łatwo uzyskać dostęp do AnonymousAction bez błędów i niewłaściwych zachowań. Ale kiedy oni (mam na myśli anonimowych użytkowników) chcą uzyskać dostęp do UsersAction, zamiast przekierowywanego na stronę logowania, zobaczą okno, o którym wspomniałem powyżej.

+1

Wygląda na to, że serwer WWW (IIS) może mieć wyłączony dostęp anonimowy do witryny. –

+0

Kiedy to się dzieje, jaki jest kod statusu HTTP odbierany w skrzypku? –

Odpowiedz

1

Cóż, to było naprawdę proste. Według @trailmax's answer (dzięki niemu) zdałem sobie sprawę, że powinienem zwrócić uwagę na kod http odpowiedzi. Był to kod 401 - Unauthorized. Więc zadałem sobie pytanie, dlaczego to jest? Do czasu znalezienia this answer. Jedyne, czego potrzebowałem, to utworzenie następującego atrybutu:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)] 
public class AuthorizeAttribute : System.Web.Mvc.AuthorizeAttribute { 
    protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext) { 
     if (filterContext.HttpContext.Request.IsAuthenticated) { 
      filterContext.Result = new HttpStatusCodeResult((int)System.Net.HttpStatusCode.Forbidden); 
     } else { 
      base.HandleUnauthorizedRequest(filterContext); 
     } 
    } 
} 
2

Czy ma to coś wspólnego z adresem URL strony logowania w programie Startup? Zauważam tę linię;

LoginPath = new PathString("/account/log-in/") 

zawsze kieruje do głównego adresu URL serwera. Więc jeśli wdrażasz, powiedz;

http://myserver.com/application1 

wówczas strona logowania będzie

http://myserver.com/account/log-in/ 

ale prawdopodobnie oznaczać

http://myserver.com/application1/account/log-in/ 

Więc może chcesz spróbować czegoś podobnego;

LoginPath = new PathString("~/account/log-in/") 

ze znakiem ~. To samo dotyczy adresu URL wylogowania.

+0

Nie, to nie problem. Jest to dokładna strona logowania: http: // myserver.com/account/log-in/' –

3

Podobnie jak Erik mówi, twój IIS ma niepoprawne ustawienia, najprawdopodobniej Uwierzytelnianie nie jest poprawnie skonfigurowane.

Przejdź do swojego IIS, wybierz swoją witrynę i wybierz sekcję Uwierzytelnianie. Powinno to wyglądać następująco: Anonymous Authentication = Enabled

Upewnij się, że twoje uwierzytelnianie anonimowe jest włączone i wszystko inne jest wyłączone.

+0

Uwierzytelnianie anonimowe jest włączone. Również strony publiczne w mojej aplikacji są dostępne anonimowo. –

+0

Nie odpowiedź, ale +1. Zobacz moją odpowiedź, proszę. –

+1

Świetnie, cieszę się, że to posortowałem. To wcale nie jest trywialny problem! – trailmax

Powiązane problemy