Existe uma possível “condição de corrida” ao usar o ASP.NET MVC TempData em um redirecionamento?

Question

Ao usar o tempdata, meu entendimento é que ele manterá o que você colocar nele por apenas uma solicitação. Portanto, ao usar o tempdata para reter dados em um redirecionamento (para usar o padrão pós-solicitação), não é possível que algum outro pedido do usuário possa entrar no servidor entre a resposta que envia o redirecionamento e o navegador do usuário solicitando a página redirecionada para? Nesse caso, o Get não teria mais o Tempdata disponível, correto?

Agora, eu entendo que algo assim acontecendo seria muito raro, mas levando em consideração que o usuário pode ter outra página aberta em outra guia, e pode haver solicitações de retorno de chamada Ajax ou cronometrado que ocorrem nessa página, de repente não Parece tão impossível para mim. É geralmente considerado muito remoto para se preocupar, ou estou entendendo mal algo?

EDIT: Para ser mais específico sobre o cenário que eu estava perguntando.

1. No Tab 1, o usuário navega para uma página com um formulário de postagem
2. No Tab 2, os navegadores do usuário para outra página no site que faz retornos de chamada Ajax em um temporizador
3. Na guia 1, o usuário publica o formulário no servidor
4. Quando o servidor recebe a postagem, ele salva alguns dados em tempdata e envia de volta uma resposta de redirecionamento
5. No Tab 2, o retorno de chamada do Ajax cronometrado acontece, enviando uma solicitação GET para o servidor. O tempdata é removido da sessão
6. No Tab 1, o navegador recebe o redirecionamento e emite uma solicitação GET
7. O servidor processa a solicitação e procura os tempdata, mas não está mais lá

Answer 1

Bem, navegando no código ASP.NET MVC mostra que, enquanto o TempData é armazenado na sessão, ele é removido da sessão quando é carregado. E é carregado no método executECore () do controlador.

Então eu acho que isso significaria que sim, você poderia ter uma condição de corrida em que uma solicitação de uma guia diferente do navegador (você teve um bom exemplo) poderia causar esse problema. Mas isso dependeria do modelo de cada navegador para lidar com solicitações. Um navegador pode serializar todas as solicitações para o mesmo servidor, para que apenas um seja executado por vez. Na realidade, eles não farão isso, no entanto, eles o capturam no máximo, que é (acho) 5 solicitações simultâneas para o mesmo servidor.

Dado que um site ASP.NET MVC pode ser solicitações de serviços para qualquer navegador (é a Web, afinal :)) É um cenário real, embora provavelmente raro, como você disse.

Answer 2

É inteiramente possível ter uma condição de corrida ao usar o tempdata. No entanto, você teria que ser "azarado" para experimentá -lo sob uso normal. Para enfrentar a condição da corrida, o seguinte deve ser verdadeiro:

1. Você precisa estar usando o tempdata para começar.
2. Você precisa ter vários Windows/Tabs do navegador/o que se abrir e compartilhar a mesma sessão do navegador.
3. Uma solicitação da segunda guia do navegador precisa "entrar" entre a solicitação e a resposta da primeira guia do navegador.

Observe que o Item #2 depende muito de qual navegador você está usando. Dependendo de como você configurou o IE, apenas porque você tem várias janelas abertas não significa que elas compartilham cookies do navegador e, portanto, eles não compartilham necessariamente sessões (que são baseadas em cookies).

No entanto, não há condição de corrida no sentido de que algo exploda se você a encontrar. Pode ser a que se refere a Haacked. Mas você posso Bata em uma condição de corrida no sentido de que você definiu alguns tempdata em uma solicitação e depois não o recuperou no próximo pedido onde você pensamento Você ia entender. Só vai ficar vazio.

Obrigado, Eilon

Answer 3

Tempdata faz uso do objeto de sessão, que não sofre esse problema, Afaik. Você encontrou um problema específico com isso?

Answer 4

Eu acho que isso nunca acontecerá, embora no início eu tenha a mesma confusão. Pense sobre isso se você executar seu aplicativo da Web MVC no modo de depuração, então você define um ponto de interrupção em uma ação de redirecionamento. E você dá um valor a Tempdata, então Você receberá o Tempdate no Redirect ViewResult e a outra visão, descobrirá que a outra solicitação nunca será responsável até que a ação de redirecionamento concluída. Então, o que significa? Solicitação única de uma vez. Então, o cenário acima que você mencionou nunca pode acontecer.