web-dev-qa-db-fra.com

ASP.NET Core 2.0 désactiver le challenge automatique

Après la mise à niveau de mon projet ASP.NET Core vers la version 2.0, les tentatives d'accès aux points de terminaison protégés ne renvoient plus 401, mais sont redirigées vers un point de terminaison (non existant) afin de permettre à l'utilisateur de s'authentifier.

Le comportement souhaité est que l'application retourne simplement un 401. Auparavant, je définissais AutomaticChallenge = false lors de la configuration de l'authentification, mais selon cet article le paramètre n'est plus pertinent (en fait, il n'existe plus).

Mon authentification est configurée comme ceci:

Startup.cs.ConfigureServices ():

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
                .AddCookie(o =>
                {
                    o.Cookie.Name = options.CookieName;
                    o.Cookie.Domain = options.CookieDomain;
                    o.SlidingExpiration = true;
                    o.ExpireTimeSpan = options.CookieLifetime;
                    o.TicketDataFormat = ticketFormat;
                    o.CookieManager = new CustomChunkingCookieManager();
                });

Configurer ():

app.UseAuthentication();

Comment désactiver l'activation automatique afin que l'application renvoie 401 lorsque l'utilisateur n'est pas authentifié?

c#authenticationasp.net-coreasp.net-core-mvc
14
severin

Comme le soulignent certaines des autres réponses, il n'existe plus de paramètre permettant de désactiver le défi automatique avec l'authentification par cookie. La solution consiste à remplacer OnRedirectToLogin:

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
        .AddCookie(options =>
         {                 
             options.Events.OnRedirectToLogin = context =>
             {
                 context.Response.Headers["Location"] = context.RedirectUri;
                 context.Response.StatusCode = 401;
                 return Task.CompletedTask;
             };
         });

Cela pourrait changer à l'avenir: https://github.com/aspnet/Security/issues/1394

22
severin

Après quelques recherches, j'ai trouvé que nous pouvons traiter ce problème avec l'approche ci-dessous:

Nous pouvons ajouter deux schémas d’authentification Identity et JWT; et utiliser le schéma d’identité pour l’authentification et utiliser le schéma JWT pour contester, JWT ne redirigera pas vers un itinéraire de connexion pendant la contestation.

services.AddIdentity<ApplicationUser, IdentityRole>().AddEntityFrameworkStores<ApplicationDbContext>();

services.AddAuthentication((cfg =>
{
    cfg.DefaultScheme = IdentityConstants.ApplicationScheme;
    cfg.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})).AddJwtBearer();
19
Zheng Xing

Comme pour @Serverin, la définition de OnRedirectToLogin du cookie d'application a fonctionné, mais doit être effectuée dans l'instruction suivante. AddIdentity dans Startup.cs: ConfigureServices:

services.ConfigureApplicationCookie(options => {
  options.Events.OnRedirectToLogin = context => {
    context.Response.Headers["Location"] = context.RedirectUri;
    context.Response.StatusCode = 401;
    return Task.CompletedTask;
  };
});
4
sammarcow

Selon this article:

Dans 1.x, les propriétés AutomaticAuthenticate et AutomaticChallenge étaient destinées à être définies sur un même schéma d'authentification. Il n'y avait pas de bon moyen de faire respecter cela.

En 2.0, ces deux propriétés ont été supprimées en tant qu'indicateurs sur l'instance individuelle AuthenticationOptions et ont été transférées dans la classe AuthenticationOptions de base. Les propriétés peuvent être configurées dans l'appel de méthode AddAuthentication dans la méthode ConfigureServices de Startup.cs.

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme);

Vous pouvez également utiliser une version surchargée de la méthode AddAuthentication pour définir plusieurs propriétés. Dans l'exemple de méthode surchargé suivant, le schéma par défaut est défini sur CookieAuthenticationDefaults.AuthenticationScheme. Le schéma d'authentification peut également être spécifié dans vos attributs individuels [Autoriser] ou dans vos stratégies d'autorisation.

services.AddAuthentication(options => {
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
});

Définissez un schéma par défaut dans la version 2.0 si l'une des conditions suivantes est remplie:

  • Vous voulez que l'utilisateur soit automatiquement connecté
  • Vous utilisez l'attribut [Authorize] ou les règles d'autorisation sans spécifier les schémas

La méthode AddIdentity constitue une exception à cette règle. Cette méthode ajoute des cookies pour vous et définit les schémas d'authentification et de défi par défaut sur le cookie d'application IdentityConstants.ApplicationScheme. En outre, il définit le schéma de connexion par défaut sur le cookie externe IdentityConstants.ExternalScheme.

J'espère que cela vous aidera.

4
Sergey

C'est le code source de CookieAuthenticationEvents.OnRedirectToLogin:

public Func<RedirectContext<CookieAuthenticationOptions>, Task> OnRedirectToLogin { get; set; } = context =>
{
    if (IsAjaxRequest(context.Request))
    {
        context.Response.Headers["Location"] = context.RedirectUri;
        context.Response.StatusCode = 401;
    }
    else
    {
        context.Response.Redirect(context.RedirectUri);
    }
    return Task.CompletedTask;
};

Vous pouvez ajouter un en-tête "X-Requested-With: XMLHttpRequest" à la demande lors de l'appel API de votre client.

3
Zack

Je ne sais pas comment générer l'erreur 401, cependant si vous utilisez le:

o.AccessDeniedPath = "{path to invalid}";

Cela vous permettra de rediriger quelque part lorsque le défi a échoué.

0
Gary Holland