EF jette l'erreur AspNetUsers après le délai d'autorisation Owin

Question

J'ai annulé l'autorisation dans mon AccountController pour une application MVC5. Il fonctionne très bien l'exploitation forestière et fermer une session, obtenir le contexte, etc. Cependant, si les délais d'autorisation, à la place de me rediriger vers la page Login, il jette l'erreur:

Invalid object name 'dbo.AspNetUsers'.

Je ne suis pas à l'aide EF dans l'authentification, mais plutôt un service, donc je n'ai pas ces tables. Cependant, je ne peux pas trouver où il frappe ce code pour lancer l'erreur.

AccountController.cs:

public async Task<ActionResult> Login(LoginViewModel model, string returnUrl) 
    { 
     if (!ModelState.IsValid) 
     { 
      return View(model); 
     } 

     var userRequest = new RequestObject 
     { 
      Name = model.Username, 
      Password = model.Password 
     }; 

     try 
     {     
      var result = await client.LoginUserAsync(userRequest); 

      if (result == 0) 
      { 
       var user = new User 
       { 
        Name = model.Username 
       }; 

       OwinSignIn(user); 

       return RedirectToAction("Index", "Home"); 
      } 
     } 
     catch (Exception) 
     { 
      // TODO: log error 
     } 

     ModelState.AddModelError("", "Invalid login attempt."); 
     return View(model); 
    } 


    private void OwinSignIn(User user, bool isPersistence = false) 
    { 
     var claims = new[] { 
      new Claim(ClaimTypes.Name, user.Name) 
     }; 

     var identity = new ClaimsIdentity(claims, DefaultAuthenticationTypes.ApplicationCookie); 

     var result = client.GetUserRoles(userRequest); 
     var roles = result.Roles.ToList(); 

     if (roles.Any()) 
     { 
      var roleClaims = roles.Select(r => new Claim(ClaimTypes.Role, r.Name)); 
      identity.AddClaims(roleClaims); 
     } 

     AuthenticationManager.SignIn(new AuthenticationProperties { IsPersistent = isPersistence }, identity); 
    } 

Encore une fois, ce ne faire si je suis connecté et attendre que l'autorisation d'expirer. Je ne suis pas sûr de la méthode que je n'ai pas mise à jour pour m'assurer que tout retourne à la page Login - je pense qu'il y a quelque chose qui vérifie que la session est toujours valide quelque part mais je ne sais pas où.

Merci.

MISE À JOUR:

Si je retire l'appel OnValidateIdentity, le problème disparaît. Je ne sais pas si cela peut être fixe ou si la suppression est ok ...

 app.UseCookieAuthentication(new CookieAuthenticationOptions 
     { 
      AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
      LoginPath = new PathString("/Account/Login"), 
      Provider = new CookieAuthenticationProvider 
      { 
       // Enables the application to validate the security stamp when the user logs in. 
       // This is a security feature which is used when you change a password or add an external login to your account. 
       OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
        validateInterval: TimeSpan.FromMinutes(30), 
        regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager)) 
      } 
     });  

Answer 1

Je comprends que vous avez déjà trouvé une solution à votre problème. Si vous n'utilisez pas EF pour conserver les données de vos utilisateurs, vous pouvez retirer la plupart des paquets Identity de votre solution et ne laisser que les fichiers OWIN requis.

Raison vous voyez cet effet est parce que ce bit:

OnValidateIdentity =  
    SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
         validateInterval: TimeSpan.FromMinutes(30), 
         regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager)) 

Il est exécuté sur une demande toutes les 30 minutes et vérifie si le cookie en cours est le même que les données dans la base de données. En réalité, il appelle la valeur par défaut ApplicationUserManager qui est câblée par défaut dans l'EF et attend par défaut que la table AspNetUsers soit présente. Non, vous ne trouverez pas cette chaîne dans votre solution - cette table est définie sur IdentityDbContext et est fournie par la partie EF d'Identity.

Je suppose qu'il sera prudent de faire votre ApplicationDbContext pour hériter de DbContext plutôt que de IdentityDbContext - cela supprimera toute possibilité de frapper les tables manquantes dont vous n'avez pas besoin. Après cela, vous pouvez supprimer ApplicationUserManager (comme il s'attend IdentityDbContext).

J'ai blogged à propos de l'utilisation de AD en tant que service pour configurer le cookie OWIN - une partie de ceci pourrait vous être utile.