Qual a segurança das solicitações ocultas do AJAX com desempenho falso?


48

O que é uma solicitação AJAX oculta?

Percebi um aumento no uso de solicitações ocultas de AJAX, projetadas para fazer com que a ação de um usuário pareça acontecer imediatamente. Vou me referir a esse tipo de solicitação AJAX como sem bloqueio. É uma solicitação AJAX feita sem que o usuário esteja ciente de que está acontecendo, é executada em segundo plano e sua operação é silenciosa ( não há detalhes para indicar uma conclusão bem-sucedida da chamada AJAX ). O objetivo é fazer com que a operação pareça que aconteceu imediatamente quando realmente não terminou.

Aqui estão exemplos de solicitação AJAX sem bloqueio;

  • O usuário clica em excluir em uma coleção de emails. Os itens desaparecem imediatamente da caixa de entrada e podem continuar com outras operações. Enquanto isso, uma solicitação AJAX está processando a exclusão dos itens em segundo plano.
  • O usuário preenche um formulário para novos registros. Cliques salvar. O novo item aparece na lista imediatamente. O usuário pode continuar adicionando novos registros.

Para esclarecer, aqui estão exemplos de bloqueio de solicitação AJAX;

  • O usuário clica em excluir em uma coleção de emails. Um cursor de ampulheta é exibido. A solicitação AJAX é feita e, quando responde, o cursor da ampulheta é desativado. O usuário precisa esperar um segundo para que a operação seja concluída.
  • O usuário preenche um formulário para novos registros. Cliques salvar. O formulário fica cinza com um carregador AJAX animado. Uma mensagem é exibida "Seus dados foram salvos" e o novo registro aparece na lista.

A diferença entre os dois cenários acima é que uma configuração AJAX sem bloqueio não fornece feedback do desempenho operacional e uma configuração AJAX bloqueada.

O risco de solicitações ocultas de AJAX

O maior risco desse estilo de solicitação AJAX é que o aplicativo Web esteja em um estado completamente diferente quando a solicitação AJAX falhar.

Por exemplo, um exemplo sem bloqueio;

  • O usuário seleciona vários e-mails. Clica no botão excluir. A operação parece ocorrer imediatamente (os itens desaparecem da lista). O usuário clica no botão de composição e começa a digitar um novo email. É nesse momento que o código JavaScript descobre que a solicitação AJAX falhou. O script pode mostrar uma mensagem de erro, mas é realmente inútil no momento.

Como alternativa, um exemplo de bloqueio;

  • O usuário seleciona vários e-mails. Clica no botão excluir. Vê uma ampulheta, mas a operação falha. Eles recebem uma mensagem de erro dizendo "erro. Blá blá blá". Eles retornam à lista de e-mails e ainda têm os e-mails que desejavam excluir selecionados. Eles podem tentar excluí-los novamente.

Há também outros riscos técnicos para executar solicitações AJAX sem bloqueio. O usuário pode fechar o navegador, navegar para outro site e navegar para outro local na web atual que torne sem sentido o contexto de qualquer resposta a erro.

Então, por que está se tornando tão popular?

Facebook, Google, Microsoft, etc. etc .. todos esses grandes domínios estão cada vez mais usando solicitações AJAX sem bloqueio para fazer com que as operações pareçam ser executadas instantaneamente. Também vi um aumento nos editores de formulários que não têm botão de salvar ou enviar . Assim que você deixar um campo ou pressione enter. O valor é salvo. Não há mensagem de seu perfil atualizada ou etapa de salvamento.

As solicitações AJAX não são uma certeza e não devem ser tratadas como bem-sucedidas até que sejam concluídas, mas muitos aplicativos principais da web estão operando assim.

Esses sites que usam chamadas AJAX sem bloqueio para simular aplicativos responsivos assumem um risco desnecessário com o custo de aparecer rapidamente?

Esse é um padrão de design que todos nós devemos seguir para permanecermos competitivos?


20
Isso é justificado pelo fato de que uma operação bem-sucedida é muito mais provável; portanto, ser lento apenas para evitar o raro caso de feedback super otimista é uma má escolha. Transposto para relacionamentos pessoais, você prefere interagir com uma pessoa calma e ensolarada ou com alguém que assume categoricamente que tudo o que pode dar errado vai dar errado e age de acordo?
Kilian Foth

11
Para mim, o que estou enfrentando é que um aplicativo de desktop tem a operação e o erro acontecendo imediatamente. Onde, com aplicativos da Web, a operação acontece imediatamente, mas o erro está atrasado. No entanto, os sites operam com o design de um aplicativo de desktop.
Reactgular

7
Você também considerou o que acontece quando o aplicativo da área de trabalho grava no disco, ele realmente entra em um buffer do SO e o disco falha antes de poder ser gravado no prato? Ou, nesse caso, o disco falha após os bytes serem gravados no prato. Nos dois casos, o usuário pensa que algo aconteceu quando realmente não aconteceu.
kdgregory

2
@KilianFoth Eu prefiro quem assume que tudo pode dar errado, se a pessoa "ensolarada" vai dar um soco em você e roubar sua carteira ao primeiro sinal de problema. Portanto, depende da escala da reação da página ao fracasso.
#

11
@ButtleButkus Eu acho que essas mensagens salvas são novas. Eles não estavam lá quando eu fiz a pergunta. Tenho notado que o Google adiciona mais comentários recentemente, que está fazendo coisas em segundo plano.
Reactgular

Respostas:


62

Não é tanto um desempenho "falso" como uma capacidade de resposta real. Existem várias razões pelas quais é popular:

  • Atualmente, as conexões com a Internet são razoavelmente confiáveis. O risco de uma solicitação AJAX falhar é muito baixo.
  • As operações que estão sendo executadas não são realmente críticas à segurança. Se seus e-mails não forem excluídos no servidor, o pior é que você precisará excluí-los novamente na próxima vez que chegar à página.
  • Você pode criar sua página para desfazer a ação se a solicitação falhar, mas não precisa ser tão sutil porque isso significa que sua conexão com o servidor está interrompida. É mais fácil dizer "Conexão perdida. Não é possível salvar as alterações recentes. Tente novamente mais tarde".
  • Você pode criar sua página para permitir apenas uma solicitação AJAX pendente, para que seu estado não fique muito sincronizado com o servidor.
  • O navegador avisa se você tentar fechar ou navegar para fora de uma página enquanto uma solicitação AJAX estiver pendente.

Aviso pendente de AJAX


8
Esse último ponto, todos os navegadores fazem isso por padrão?
Svish

Eu não sei. Eu só testei no IE9 e no Chrome mais recente.
Karl Bielefeldt

3
Você, obviamente, não estão familiarizados com Internet australiano, para não mencionar pobres, em desenvolvimento, e isolados lugares, mesmo móvel em um veículo em movimento ...
hippietrail

2
@hippietrail Bem, você não pode fazer todo mundo feliz o tempo todo.
KOVIKO

11
Quando o usuário envia uma solicitação, ele nem sempre solicita uma nova página. Acho que aplicativos AJAX bem projetados podem torná-los mais agradáveis, permitindo que o usuário saiba o que está acontecendo com mais eficiência do que com uma recarga.
Frederik.L

32

Assumir que algo funcione e exibir um erro, caso falhe no lado remoto, é muito mais fácil do que impedir o usuário de fazer qualquer outra coisa até que haja uma resposta do servidor.

Um cliente de e-mail é realmente um ótimo exemplo disso: quando tenho uma lista com 5 e-mails e o principal é selecionado, espero que ao acessar DELtrês vezes os três primeiros sejam excluídos. Com "AJAX nonblocking", isso funciona bem - toda vez que eu pressiono a tecla, o email selecionado é removido imediatamente. Se algo der errado, um erro será mostrado e os emails não excluídos corretamente serão mostrados novamente OU a página será recarregada para se livrar do estado local inconsistente.

Portanto, no caso mais comum - que é sucesso -, melhora a usabilidade. No raro caso - falha - a usabilidade é prejudicada (o elemento excluído aparece novamente ou o aplicativo é "reiniciado"), mas ao criar um aplicativo, geralmente você deseja ter a melhor usabilidade para casos comuns, não para erros.


11
+1 este é o ponto central da questão. Por padrão, há tanta segurança que as pessoas implementam nos dias de hoje que, nos piores cenários, você ainda não está arriscando erros de usuário verdadeiros: imagine que o cliente de email falha ao excluir, agora o estado local é ruim e eles tentam excluir o email 4, que está desalinhado com o servidor, a grande maioria dos desenvolvedores de back-end terá uma trava de segurança para garantir que você exclua apenas o que o usuário absolutamente deseja e, portanto, esse desalinhamento não causará exclusões errôneas (pode falhar por engano, mas não será excluído) .
Jimmy Hoffa 31/01

@JimmyHoffa, você usaria um ID de email exclusivo na solicitação de exclusão. Seria muito ruim enviar solicitações de exclusão com base na ordem de exibição arbitrária dos e-mails na sua caixa de entrada.
Buttle Butkus

14

Os usuários não se importam com o que o seu software está fazendo nos bastidores: eles querem que suas ações tenham um impacto visível e possam trabalhar no seu ritmo.

Se uma ação foi bem-sucedida no lado do cliente - como a exclusão de e-mails -, é seu trabalho torná-la bem-sucedida no lado do servidor. Por que a exclusão falhou? Se for devido a algum tipo de limitação (por exemplo, você não pode remover um email que foi arquivado), o usuário deve ser informado disso antes que sua ação falhe.

Se o erro for causado por algo mais grave (digamos, uma falha no banco de dados), você deverá ter uma maneira de salvar a operação e tentar novamente quando o sistema estiver funcionando novamente.

Um bom exemplo de como gerenciar isso é a maneira como o Facebook lida com o bate-papo. Não há como impedir que um usuário se desconecte repentinamente, o que significa que ele não poderá ler as mensagens enviadas antes de sair. Em vez de exibir um erro, o sistema salva todas essas mensagens e as disponibiliza ao usuário quando ele voltar. Nenhum dado é perdido.


2
+1. Excelente exemplo de bate-papo. A maioria dos usuários espera que sua mensagem seja imediatamente disponibilizada a todos e, como essas mensagens raramente falham, os usuários têm a ilusão de que esse é o caso.
Neil

11
@Niphra, "Por que a exclusão falhou?" A rede pode falhar por vários motivos, nenhum dos quais relacionado ao seu aplicativo. Não há nada que você possa fazer para impedir isso.
Pacerier 16/02

5

Você pode se comprometer entre as duas opções. Por exemplo, se o usuário excluir um email, você poderá marcá-lo em vermelho ou cinza até receber uma confirmação de volta do servidor e, em seguida, removê-lo da lista. O usuário ainda pode fazer outras coisas enquanto uma ação está pendente, por isso não está bloqueando, mas ainda deixa um pequeno lembrete para o usuário de que suas ações ainda não foram confirmadas.

O Amazon AWS adota essa abordagem: quando você para / inicia uma instância, a caixa de seleção que permite selecioná-la se transforma em giratória (para que você não possa fazer nada por alguns segundos), mas isso não impede você de interagindo com outras instâncias.


Sua sugestão é semelhante à forma como o gmail mostra o texto "Salvando ..." enquanto o XHR está em andamento e "Salvo" depois de concluído. Se sempre dissesse "Salvo", quem acreditaria?
Buttle Butkus

3

Eu acho que isso vem junto com mais e mais sites que tentam se comportar como aplicativos e executam mais processamento no navegador (como validar dados do formulário) do que os sites mais tradicionais. Não vejo muitos problemas, desde que seu código seja confiável e você possa esperar que ele seja bem-sucedido em condições normais.

Você diz: "É nesse momento que o código JavaScript descobre que a solicitação AJAX falhou. O script pode mostrar uma mensagem de erro, mas é realmente inútil no momento".

Por que deveria ser inútil? Você pode voltar na lista de e-mails e excluir novamente. Por que esperar? Na verdade, não há muito "risco" e eles não "parecem" ser rápidos, eles realmente trabalham mais rapidamente. Então, se a atividade não é "crítica", por que ser lento?


11
Talvez inútil não fosse a palavra certa, mas o que quero dizer é que a mensagem de erro carece de contexto relativo, porque o usuário agora está fazendo algo completamente diferente. Estou tentando dizer, é que para um usuário da web ignorante, eles pensaram que os emails foram excluídos com sucesso. Então, por que agora, mais tarde, eles recebem uma mensagem de erro por algo que "viram" foram removidos. Para nós, programadores, entendemos, mas para o vovô usando o Gmail eles não entenderiam.
Reactgular

A maioria das pessoas prefere usar um aplicativo em que as coisas acontecem imediatamente, o sistema responde e há 1 em 10.000 de chance de a interface do usuário ser atualizada de maneira estranha em um erro do que um aplicativo que congela por um segundo sempre que altera um valor.
Gort the Robot

1

Meu 2c é: há situações em que é melhor ter, como você diz, "operações sem bloqueio" do Ajax e outras em que é uma má escolha de design. Exemplo: votando em um vídeo do YouTube. Você realmente não deseja que nenhuma parte da página seja bloqueada enquanto clica nos pequenos começos lá. É melhor falhar silenciosamente. Até uma mensagem de confirmação seria exagerada. No entanto, seu exemplo com exclusão de e-mail seria qualificado como obrigatório para a solicitação do tipo Ajax de bloqueio.

O Mongo DB faz algo assim (e isso pode ser considerado como um exemplo de aplicativo da área de trabalho). Eles têm vários "Preocupações de gravação" para suas operações, e você pode configurá-lo com valores diferentes para cada operação, variando entre "retornar imediatamente e não esperar por nada" para "bloquear até confirmar a transferência e o êxito da transferência de rede". em seguida, retorne "para" aguarde até que o conteúdo esteja devidamente programado para gravação em disco na máquina remota antes do seu retorno ". Obviamente, se você criar um cliente espesso para a área de trabalho (como C ++) usando o driver Mongo, definiria a preocupação de gravação mais leve para operações de banco de dados com um mínimo de "criticidade" (como verificar novos emails) e outras sobre preocupações de gravação mais estritas .

Enquanto vejo a utilidade do Ajax sem bloqueio, concordo com você que isso está acontecendo demais. A certa altura, havia pelo menos um site famoso de "rede social" que faria isso para o upload de fotos. Você escolheu sua foto para fazer o upload e, em seguida, bam, imediatamente lhe diria que está pronta e, no dia seguinte, quando você quiser adicionar mais algumas fotos (ou usar as que você acha que já adicionou), nunca foi encontrado. Mais tarde, eles desistiram disso e, na verdade, demoraram um pouco a esperar pela resposta (e você às vezes recebia mensagens como "falha ao enviar a foto, tente mais tarde").


+1 por ver as coisas do meu jeito :). O upload da foto é um ótimo exemplo de falha.
Reactgular

11
Por que um upload de bloqueio seria preferível? No Picasa (interface da web), você pode arrastar fotos e, enquanto elas são carregadas em segundo plano, você pode arrastar mais ou marcar fotos que foram finalizadas, etc. Uma operação de bloqueio de upload tornaria um UX horrível
BLSully
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.