Existe-t-il une «condition de concurrence» lors de l'utilisation de Asp.Net MVC TempData dans une redirection?

Question

Lors de l’utilisation de TempData, j’ai bien compris qu’il conserverait tout ce que vous avez mis dans une seule requête. Ainsi, lorsqu’on utilise TempData pour conserver des données via une redirection (afin d’utiliser le modèle Post-Request-Get), n’est-il pas possible qu’une autre requête de l’utilisateur puisse arriver sur le serveur entre la réponse envoyant la redirection et la le navigateur de l'utilisateur demandant la page redirigée? Dans quel cas le get n’aurait plus le TempData disponible, correct?

Maintenant, je comprends que cela arrive très rarement, mais étant donné que l'utilisateur peut avoir une autre page ouverte dans un autre onglet et qu'il peut y avoir des demandes de rappel ajax ou chronométrées sur cette page, ne me semble pas si impossible. Est-ce simplement considéré généralement comme trop éloigné pour s’inquiéter, ou est-ce que je comprends mal quelque chose?

Éditer: pour être plus précis sur le scénario que je posais.

1. Dans l'onglet 1, l'utilisateur accède à une page avec un formulaire de message
2. Dans l’onglet 2, les navigateurs de l’utilisateur accèdent à une autre page du site rappels ajax sur une minuterie
3. Dans l'onglet 1, l'utilisateur poste le formulaire sur le serveur
4. Lorsque le serveur reçoit la publication, il enregistre des données dans TempData et renvoie une réponse de redirection
5. Dans l'onglet 2, le rappel ajax temporisé se produit et envoie une demande GET au serveur. Le TempData est supprimé de la session
6. Dans l'onglet 1, le navigateur reçoit la redirection et envoie une demande GET
7. Le serveur traite la requête GET et recherche le TempData, mais il n'y en a plus

Answer 1

En parcourant le code ASP.NET MVC, vous constaterez que tant que TempData est stocké dans la session, il est supprimé de la session lorsqu’il est chargé. Et il est chargé dans la méthode ExecuteCore () du contrôleur.

Donc, je pense que cela voudrait dire qu'effectivement, vous pourriez rencontrer une situation critique où une demande provenant d'un onglet de navigateur différent (vous avez un très bon exemple) pourrait être à l'origine de ce problème. Mais cela dépend du modèle de chaque navigateur pour le traitement des demandes. Un navigateur peut sérialiser toutes les demandes sur le même serveur, de sorte qu'un seul s'exécute à la fois. En réalité, ils ne le feront pas, cependant, ils le limiteront au maximum, ce qui correspond (je pense) à 5 demandes simultanées adressées au même serveur.

Etant donné qu'un site ASP.NET MVC peut être une requête de services adressée à n'importe quel navigateur (c'est le Web, après tout :)), il s'agit d'un scénario réel, bien que probablement rare, comme vous l'avez dit.

Answer 2

Il est tout à fait possible d'avoir une condition de concurrence critique lors de l'utilisation de TempData. Cependant, vous devez bien sûr être "malchanceux". en faire l'expérience dans des conditions normales d'utilisation. Pour que la condition de concurrence soit remplie, les conditions suivantes doivent toutes être remplies:

1. Vous devez commencer par utiliser TempData.
2. Vous devez avoir plusieurs fenêtres / onglets / fenêtres de navigateur ouverts et partageant la même session de navigateur.
3. Une demande du deuxième onglet du navigateur doit "se faufiler". entre la requête et la réponse du premier onglet du navigateur.

Notez que l'élément n ° 2 dépend beaucoup du navigateur que vous utilisez. Selon la configuration de votre navigateur Internet Explorer, le fait que plusieurs fenêtres soient ouvertes ne signifie pas qu'elles partagent les cookies du navigateur. Par conséquent, elles ne partagent pas nécessairement les sessions (basées sur des cookies).

Cependant, il n’ya pas de situation de concurrence critique dans le sens où quelque chose explose si vous le rencontrez. C'est peut-être ce à quoi Haacked fait référence. Mais vous pouvez remplir une condition de concurrence critique en ce sens que vous définissez un certain TempData dans une requête et que vous ne le récupérez pas dans la requête suivante où vous pensiez que vous alliez pour l'obtenir. Ça va juste être vide.

Merci, Eilon

Answer 3

TempData utilise l'objet Session, qui ne souffre pas de ce problème, autant que je sache. Avez-vous rencontré un problème spécifique avec cela?

Answer 4

Je pense que cela ne se produira jamais, même si au début j'ai la même confusion. Pensez-y si vous exécutez votre application Web MVC en mode débogage, vous définissez un point d'arrêt dans une action de redirection. valeur, alors vous obtiendrez le tempdate dans redirect viewResult et dans l’autre vue, vous constaterez que l’autre demande ne sera jamais prise en compte tant que l’action de redirection n’aura pas aboutie. Alors, que signifie-t-il? peut traiter une seule demande en une fois. Le scénario ci-dessus que vous avez mentionné ne peut jamais se produire.