MVC5 (VS2012) Identité CreateIdentityAsync - Valeur ne peut pas être null
J'essaye de configurer l'authentification OAuth pour un MVC5 site (en VS2012).
J'utilise Couramment NHibernate. J'ai créer mon propre Userstore et passer dans un objet de référentiel pour l'accès NHibernate objet de session. Je passe mon magasin par défaut dans le réseau usermanager fournisseur. Ceci a par la suite travaillé pour un enregistrement local et la connexion. Je n'essaie pas de configuration connexion /inscription avec Facebook.
Il obtient un succès. Ajoute un utilisateur dans la table user, ajoute un enregistrement dans les connexions du tableau, puis explose. Je n'ai pas implémente les réclamations dans le magasin de l'utilisateur, ou de mettre une collecte des réclamations dans l'objet utilisateur. (je ne sais pas si c'est réellement nécessaire, j'ai été le décapage de tout ce que peut-être aller de mal à trouver la source du problème).
La ligne qui explose est, (dans le compte contrôleur):
var identity = await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
à l'intérieur de cette méthode:
private async Task SignInAsync(IdentityUser user, bool isPersistent)
c'est la fin de la trace de la pile
[ArgumentNullException: Value cannot be null.
Parameter name: value]
System.Security.Claims.Claim..ctor(String type, String value, String valueType, String issuer, String originalIssuer, ClaimsIdentity subject, String propertyKey, String propertyValue) +14108789
System.Security.Claims.Claim..ctor(String type, String value, String valueType) +62
Microsoft.AspNet.Identity.<CreateAsync>d__0.MoveNext() +481
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() +49
Web.Controllers.<SignInAsync>d__42.MoveNext() in d:\Google Drive\Development\GoalManagement\Web\Controllers\AccountController.cs:375
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
Web.Controllers.<ExternalLoginConfirmation>d__35.MoveNext() in d:\Google Drive\Development\GoalManagement\Web\Controllers\AccountController.cs:311
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) +144
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +84
public class IdentityUser : IUser
{
public IdentityUser()
{
Logins = new List<IdentityUserLogin>();
}
public string Id { get; set; }
public string UserName { get; set; }
public string PasswordHash { get; set; }
public string SecurityStamp { get; set; }
public IList<IdentityUserLogin> Logins { get; set; }
}
public class IdentityUserLogin
{
public string LoginProvider { get; set; }
public string ProviderKey { get; set; }
}
Je peux inclure mon userstore code si vous le souhaitez: je n'ai pas mis dans comme c'est un gros fichier, et pourrait nuire à la question.
Je ne suis pas sûr pourquoi, il est même en essayant de créer l'objet de revendication et pourquoi il est fait exploser. Comme je n'ai que VS2012 j'ai été patcher tous ensemble à partir d'exemples en ligne principalement.
Comme suggéré par @Chaussure j'ai hérité de UserManager
:
public class NHibernateAspnetUserManager<TUser> : UserManager<TUser> where TUser : IdentityUser
{
public NHibernateAspnetUserManager(IUserStore<TUser> store) : base(store)
{
}
public override Task<ClaimsIdentity> CreateIdentityAsync(TUser user, string authenticationType)
{
ClaimsIdentity identity = new ClaimsIdentity();
return Task.FromResult(identity);
}
}
Il maintenant n'est plus renvoyait un message d'erreur mais n'est pas réellement authentifier moi comment jamais combien de fois j'ai utiliser le Facebook s'inscrire /se connecter.
Pour résumer. Avec @Chaussure info, j'ai essayé les deux primordial UserManager.CreateIdentityAsync
avec:
public override Task<ClaimsIdentity> CreateIdentityAsync(TUser user, string authenticationType)
{
var identity = new ClaimsIdentity();
identity.AddClaim(new Claim(ClaimTypes.Name, user.UserName));
return Task.FromResult(identity);
}
et aussi d'essayer de mettre en œuvre IUserClaimStore avec le retour par défaut (liste vide).
La première ne sera pas grâce à une erreur, mais il n'est pas authentifié. Le plus tard sera encore au travers de l'étrange demande "du Système.De sécurité.Les revendications.Demande..ctor" erreur
MODIFIER
Trouvé pourquoi le ctor erreur est survenu. L'utilisateur de l'objet a été de revenir sans l'ID de sorte que le défaut UserManager
était de s'énerver. Fixe et utilisé par défaut UserManager
qui maintenant n'est plus renvoyait un message d'erreur, mais ne peut toujours pas se connecter l'utilisateur. L'identité de l'objet, il retourne semble bon de ce que je peux dire.
- J'ai utilisé le construit dans le usermanager... essayé d'utiliser resharper de le décompiler, mais rien de readbale sortit à l'autre extrémité.
Vous devez vous connecter pour publier un commentaire.
J'ai eu le même message d'erreur dans le passé, mais seulement quand j'ai créé l'utilisateur avec Entity Framework, Outil de Migration. Lors de la création d'un utilisateur et de signature à l'intérieur du site, je n'avais pas d'erreur.
Mon erreur était que je n'étais pas fournir une SecurityStamp avec la migration.
Cette propriété est définie, tout a fonctionné.
var user = userManager.FindByNameAsync("some_username").Result; user.SecurityStamp = Guid.NewGuid().ToString(); signInManager.SignIn(user, false, false);
J'ai eu un problème similaire. La Solution a été de définir la SecurityStamp-la Propriété de l'Utilisateur de l'Entité.
Contexte: Le client veut avoir de l'Administrateur/Utilisateur-Comptes avec des mots de passe dans la base de données et un tas d'autres utilisateurs - qui doit être en mesure de se connecter sans mot de passe dans un fichier XML...
J'ai donc hériter de l'Entité Cadre UserStore, remplacer FindByIdAsync et FindByNameAsync, recherche dans le fichier XML pour l'utilisateur et le retour à un nouvel Utilisateur de l'Entité. (si aucun utilisateur n'a été trouvé par l'implémentation par défaut)
J'ai eu la même Exception que Jon lors de la création d'un ClaimsIdentity.
Après quelques recherches, j'ai trouvé que mon Utilisateur nouvellement créé-les Entités n'ont pas de SecurityStamp. Et la asp.net par défaut UserManager s'attend à un SecurityStamp et veut en faire une Réclamation dans le ClaimsIdentity.
Après la définition d'une valeur à la propriété - j'ai utilisé une chaîne de caractères qui contient un préfixe et le nom d'utilisateur - tout fonctionne bien pour moi.
J'ai fait la même chose que @user3347549.
Il m'a fallu un certain temps à comprendre où l'erreur a été effectivement venir, bravo à dotPeek pour que!
Je suis en utilisant ma propre mise en œuvre de UserManager et UserStore, parce que je voulais Guid types (uniqueidentifier MSSQL) que les clés, et pas de chaîne (mais ils sont juste des espaces réservés pour les Guid)
Grâce à cette lien et plus précisément cette réponse, à laquelle j'ai inclus à titre de référence dans le cas où le lien s'en va, par HaoK (@Hao Kung ici DONC):
J'ai mis en place mon propre ClaimsIdentityFactory (qui ressemble exactement la même de ce que je comprends dans dotPeek) et juste modifié une ligne dans la CreateAsync méthode
La ligne j'ai modifié a été de
à
Je n'ai pas encore de comprendre ce que cela signifie, mais au moins ça marche pour l'instant et je peux continuer de tester mon application. Je suis en supposant que cette erreur s'affiche parce que je n'ai pas entièrement mis en œuvre une partie de l'Identité de la pile. Pour utiliser cette nouvelle usine, tapez simplement ceci dans le UserManager constructeur:
La valeur par défaut
UserManager
tentera d'obtenir les revendications et ajouter/supprimer des revendications même si vous n'avez pas mis en œuvre. Si vous n'avez pas besoin de réclamations, la solution que j'ai trouvé est de mettre en place votre propreUserManager
ou de mettre en œuvre "ne rien faire" méthodes dans votreUserStore
.UserStore
? C'est là où ils vont, non pas dans leUserManager
UserManager
et de mettre en œuvre votre propreUserStore
. De toute façon vous aurez besoin d'un customUserStore
J'ai eu à mettre en œuvre ClaimsIdentityFactory et définir le UserManager.ClaimsIdentityFactory propriété c'est à dire dans AccountController classe.
Dans mon cas, c'était quelque chose de totalement différent. C'était une question de Owin code de démarrage de la commande
Mon buggy code:
Il s'avère,
AppSignInManager
essayait d'initAppUserManager
qui est toujoursnull
parce qu'il n'a pas été ajouté à Owin encore.En changeant tout simplement l'ensemble, tout a fonctionné comme un charme