Ma configuration:
Lorsqu'un utilisateur s'inscrit d'abord, je leur montre une "introduction démarrée". L'intro est supposée être exécutée une fois - je me connecte l'horodatage de la date de lancement d'introduction en tant que champ personnalisé dans la table utilisateur ASP.NET. P>
Imaginez ma surprise lorsque je me connecte (comme utilisateur le ferait) et de voir l'intro deux fois. P>
L'extrémité avant angularjs envoie correctement le message "Intro View" à l'ASP. NET API, et l'API répond avec un message de réussite. Cependant, lorsque je regarde les données brutes dans la DB, l'horodatage n'est absolument pas mis à jour. Par conséquent, l'utilisateur verra l'intro une seconde fois (à quel point l'horodatage est enregistré correctement dans la DB). P>
J'ai une solution de contournement de merde. Une fois que le client demande un jeton de porteur OAuth de mon serveur, le client demande ensuite des informations à l'utilisateur (de décider de montrer ou non la visite). attendant 100ms puis envoyant le message "Visualisation de la tournée" du serveur masque le problème. em> stry> p> Je n'ai vu aucun autre problème de stockage de données à tout moment. Parce que notre dB est sur Azure, je ne peux pas raccorder le profileur et le Audit intégré ne me donne aucune indices. P> Y a-t-il quelque chose à propos de demander le jeton qui laisse l'identité ASP.NET dans un état amusant? Et il faut une brève attente avant de pouvoir écrire à la table? Les champs personnalisés étendent-ils la configuration d'identité de base tendance à des problèmes tels que celui-ci? L'Usermanager est-il éventuellement faire quelque chose de bizarre dans sa boîte noire? P> Est-ce que quelqu'un a des suggestions pour continuer à déboguer ce problème? Ou jamais entendre parler de quoi que ce soit comme celui-ci? P> Voici le code pertinent qui devrait mettre à jour l'horodatage "Visite de la visite" dans la DB: P> ApplicationDbContext newContext = new ApplicationDbContext();
var currentUser = await (from c in newContext.Users
where c.Email == User.Identity.Name
select c).SingleOrDefaultAsync();
//update some values
await newContext.SaveChangesAsync();
3 Réponses :
Fondamentalement, le problème peut être avec l'initialisation du «Usermanager» et le fait que cette classe fonctionne sur le contexte de la DB afin que vous ayez besoin de persister les modifications apportées à ce contexte. Voici un exemple:
var dbContext = userStore.context; dbContext.saveChanges();
Eh bien, cela semble être une bonne réponse, alors je vous ai donné un +1. Je ne peux pas réellement faire reproduire le problème en ce moment, j'ai donc besoin de plus de tests pour comprendre cela. Je n'ai rien changé. Je suis parti en pensant que ceci est soit une certaine condition de race étrange (et les choses fonctionnent rapidement en ce moment) ou j'ai imaginé tout le monde ...
Plus de tests a montré que cela n'a pas résolu le problème - et je n'ai pas essayé d'éviter l'Usermanager. Mis à jour le message d'origine avec des détails. Le fait que je ne puisse pas reproduire le problème plus tôt ce matin, ressentez la course, y ... peut-être avoir quelque chose à faire avec comment chargé mon serveur / dB est ...
@waffles pouvez-vous essayer de vous exécuter une application sur la DB locale? Juste pour éliminer les problèmes d'azur?
Combien d'instances de l'application hébergée avez-vous? Comment initiez-vous votre stockage - par demande ou par application?
Basé sur votre commentaire qui attend 100 ms masque le problème, je pense que vous pouvez avoir un problème avec les multiples appels ASYNC Await. Essayez d'exécuter les appels de manière synchrone et voyez si vous avez toujours le même problème. Je suppose que le problème pourrait disparaître. Mon expérience a été que l'utilisation d'ASYNC attend peut être délicate lorsque vous appelle des méthodes asynchrones qui appellent d'autres méthodes asynchrones. Vous pouvez avoir du code qui exécute sans les résultats appropriés retournés.
Une autre bonne suggestion, mais j'ai déjà essayé cela. Aucun changement de comportement de la persistance des données. Merci quand même...
Eh bien, voici ce que j'ai fait pour résoudre le problème. J'ai totalement réfléchi à mes données utilisateur personnalisées à partir de l'identité ASP.NET intégrée. J'ai maintenant un objet distinct (et donc une table SQL séparée) qui stocke des éléments comme FirstName, Nom, LastActiCivedate, etc., etc.
Cela a résolu tout mon problème, même s'il a introduit un autre appel à la base de données dans certaines situations. Je l'ai estimé que ce n'est pas une question de performance assez importante à craindre. Je suis parti en pensant que c'était une sorte de condition de race étrange impliquant la génération d'un jeton pour un utilisateur d'identité ASP.NET, puis écrit rapidement dans une base de données Azure SQL - Seigneur sait ce que c'était exactement dans mon code qui a provoqué le problème.
Si vous avez un problème difficile à résoudre, le meilleur plan est souvent de changer le problème.
Maintenant, j'ai besoin de trouver un fil méta qui discute de quoi faire avec des points de prime lorsque vous avez soufflé le problème ...
Vous dites que l'API répond avec un "message de réussite". D'après ce que je peux voir dans votre code, vous obtiendrez une réponse de 200, ainsi que le
userinfovievismodel . Est-ce le cas? Êtes-vous également certain sur le premier appel que le jeton est envoyé avec la demande (c'est-à-direuser.identity.getuserid () vous donner le bon utilisateur)? Enfin, on pourrait valoir la peine d'ajouter la logique que vous avez commentée - il exécute avant de mettre à jour l'utilisateur, alors peut-être que quelque chose se passe là-basCorrect - 200 plus le modèle de vue. Jeton est envoyé et l'appel du client est correctement authentifié. Bonne question, cependant. Je mettrai à jour la question originale avec le code abrégé ... c'est assez banal.