À quel point les requêtes AJAX cachées sont-elles sécurisées?


48

Qu'est-ce qu'une demande AJAX cachée?

J'ai remarqué une augmentation de l'utilisation de requêtes AJAX cachées conçues pour que l'action d'un utilisateur semble se produire immédiatement. Je ferai référence à ce type de demande AJAX comme non bloquant. C'est une demande AJAX faite sans que l'utilisateur sache que cela se produit, elle est effectuée en arrière-plan et son fonctionnement est silencieux ( il n'y a pas de message détaillé indiquant la réussite de l'appel AJAX ). L’objectif est de faire croire à l’opération que cela s’est produit immédiatement alors qu’elle n’a pas vraiment fini.

Voici des exemples de requêtes AJAX non bloquantes;

  • L'utilisateur clique sur supprimer dans une collection d'e-mails. Les éléments disparaissent immédiatement de leur boîte de réception et ils peuvent continuer avec d'autres opérations. Pendant ce temps, une demande AJAX traite la suppression des éléments en arrière-plan.
  • L'utilisateur remplit un formulaire pour les nouveaux enregistrements. Clics enregistrer. Le nouvel élément apparaît immédiatement dans la liste. L'utilisateur peut continuer à ajouter de nouveaux enregistrements.

Pour clarifier, voici des exemples de blocage de demandes AJAX;

  • L'utilisateur clique sur supprimer dans une collection d'e-mails. Un curseur en sablier apparaît. La demande AJAX est faite et quand elle répond, le curseur sablier est désactivé. L'utilisateur doit attendre une seconde pour que l'opération soit terminée.
  • L'utilisateur remplit un formulaire pour les nouveaux enregistrements. Clics enregistrer. Le formulaire devient gris avec un chargeur AJAX animé. Un message s'affiche "Vos données ont été enregistrées" et le nouvel enregistrement apparaît dans la liste.

La différence entre les deux scénarios ci-dessus réside dans le fait qu'une configuration AJAX non bloquante ne fournit pas d'informations en retour sur une opération en cours d'exécution, contrairement à une configuration AJAX bloquante.

Le risque de demandes cachées AJAX

Le plus grand risque de ce style de demande AJAX est que l'application Web puisse se trouver dans un état complètement différent en cas d'échec de la demande AJAX.

Par exemple, un exemple non bloquant;

  • L'utilisateur sélectionne un tas de courriels. Clique sur le bouton Supprimer. L'opération semble se produire immédiatement (les éléments disparaissent de la liste). L'utilisateur clique ensuite sur le bouton de composition et commence à taper un nouvel email. C'est à ce moment que le code JavaScript découvre que la demande AJAX a échoué. Le script peut afficher un message d'erreur, mais c'est vraiment inutile en ce moment.

Alternativement, un exemple bloquant;

  • L'utilisateur sélectionne un tas de courriels. Clique sur le bouton Supprimer. Voit un sablier, mais l'opération échoue. Ils reçoivent un message d'erreur disant "erreur. Bla bla bla". Ils sont renvoyés à la liste des e-mails et ils ont toujours sélectionné les e-mails qu'ils voulaient supprimer. Ils pourraient tenter de les supprimer à nouveau.

Il existe également d'autres risques techniques liés à l'exécution de requêtes AJAX non bloquantes. L'utilisateur peut fermer le navigateur, accéder à un autre site Web et à un autre emplacement du site Web actuel, ce qui rend tout contexte de réponse d'erreur inexact.

Alors, pourquoi devient-il si populaire?

Facebook, Google, Microsoft, etc., etc., etc., tous ces grands domaines utilisent de plus en plus des requêtes AJAX non bloquantes pour faire en sorte que les opérations apparaissent comme étant exécutées instantanément. J'ai également constaté une augmentation du nombre d'éditeurs de formulaires dépourvus de bouton de sauvegarde ou d'envoi . Dès que vous quittez un champ ou appuyez sur enter. La valeur est enregistrée. Il n'y a pas de message de profil ou de sauvegarde mis à jour .

Les demandes AJAX ne sont pas une certitude et ne devraient pas être traitées avec autant de succès tant qu'elles ne sont pas terminées, mais de nombreuses applications Web majeures fonctionnent exactement comme cela.

Ces sites Web qui utilisent des appels AJAX non bloquants pour simuler des applications réactives prennent-ils un risque inutile au détriment d'une parution rapide?

Est-ce un modèle de conception que nous devrions tous suivre pour rester compétitifs?


20
Cela est justifié par le fait que le succès des opérations est beaucoup plus probable. Par conséquent, être lent, juste pour éviter les rares cas de réactions excessivement optimistes, constitue un mauvais compromis. Transposé aux relations personnelles, préférez-vous interagir avec une personne calme et ensoleillée ou une personne qui assume catégoriquement que tout ce qui peut mal tourner va mal se passer et agit en conséquence?
Kilian Foth

1
Pour moi, ce qui me pose problème, c'est qu'une application de bureau ait à la fois le fonctionnement et l'erreur se produisent immédiatement. Où comme, avec les applications Web, l'opération se produit immédiatement, mais l'erreur est retardée. Pourtant, les sites fonctionnent avec la conception d'une application de bureau.
Réactif le

7
Avez-vous également pris en compte ce qui se produit lorsque votre application de bureau écrit sur le disque, elle est réellement insérée dans une mémoire tampon de système d'exploitation et le disque tombe en panne avant de pouvoir être écrit sur le plateau? Ou, d'ailleurs, le disque tombe en panne une fois les octets écrits sur le plateau. Dans les deux cas, l'utilisateur pense qu'il s'est passé quelque chose alors que ce n'est pas le cas.
kdgregory

2
@KilianFoth Je préférerais celui qui suppose que tout peut aller de travers, si la personne "ensoleillée" va vous frapper et voler votre portefeuille dès les premiers signes de problèmes. Cela dépend donc de l'ampleur de la réaction de la page en cas d'échec.
Izkata

1
@ButtleButkus Je pense que ces messages de sauvegarde sont nouveaux. Ils n'étaient pas là quand j'ai posé la question. J'ai remarqué que Google ajoutait plus de commentaires ces derniers temps, c'est qu'il fait des choses en arrière-plan.
Reactgular

Réponses:


62

Ce n'est pas tant une "fausse" performance qu'une réelle réactivité. Il est populaire pour plusieurs raisons:

  • Les connexions Internet sont assez fiables de nos jours. Le risque d'échec d'une demande AJAX est très faible.
  • Les opérations effectuées ne sont pas vraiment critiques pour la sécurité. Si vos courriels ne sont pas supprimés sur le serveur, le pire qui se passe est que vous devez les supprimer à nouveau lors de votre prochaine visite sur la page.
  • Vous pouvez concevoir votre page pour annuler l'action en cas d'échec de la demande, mais vous n'avez pas vraiment besoin d'être aussi subtile, car cela signifie que votre connexion au serveur est interrompue. Il est plus facile de dire "Connexion perdue. Impossible d'enregistrer les modifications récentes. Réessayez plus tard."
  • Vous pouvez configurer votre page pour n'autoriser qu'une seule demande AJAX en attente afin que votre état ne soit pas trop désynchronisé par le serveur.
  • Le navigateur vous avertit si vous essayez de fermer ou de quitter une page alors qu'une demande AJAX est en attente.

AJAX en attente d'avertissement


8
Ce dernier point, tous les navigateurs le font-ils par défaut?
Svish

Je ne sais pas. Je ne l'ai testé que sur IE9 et le dernier chrome.
Karl Bielefeldt

3
Vous ne connaissez évidemment pas l'Internet australien, sans parler des endroits pauvres, en développement et isolés, même mobiles sur un véhicule en mouvement ...
hippietrail

2
@ hippietrail Eh bien, vous ne pouvez pas rendre tout le monde heureux tout le temps.
KOVIKO

1
Lorsque l'utilisateur envoie une demande, il ne demande pas toujours une nouvelle page. Je pense que des applications AJAX bien conçues peuvent les rendre plus agréables, en permettant à l'utilisateur de savoir ce qui se passe plus efficacement qu'avec un rechargement.
Frederik.L

32

Supposer que quelque chose va fonctionner et afficher une erreur en cas d'échec du côté distant est beaucoup plus convivial que d'empêcher l'utilisateur de faire autre chose jusqu'à ce que le serveur réponde.

Un client de messagerie est en fait un excellent exemple: lorsque j’ai une liste de 5 courriels et que le premier est sélectionné, je suppose que lorsqu’on tape DELtrois fois, les trois premiers courriels sont supprimés. Avec "AJAX non bloquant", cela fonctionne bien - chaque fois que je frappe, l’email sélectionné est immédiatement supprimé. Si quelque chose ne va pas, une erreur est affichée et soit les courriels non correctement supprimés sont montrés à nouveau OU la page est rechargée pour se débarrasser de l'état local incohérent.

Donc, dans le cas le plus fréquent - c'est le succès - cela améliore la convivialité. Dans de rares cas - en cas d' échec - la convivialité est dégradée (l'élément supprimé s'affiche à nouveau ou l'application est "redémarrée"), mais lors de la création d'une application, vous souhaitez généralement bénéficier de la meilleure facilité d'utilisation pour les cas courants, et non en cas d'erreur.


1
+1 c'est la tache sur le coeur de la matière. Il y a tellement de sécurité implémentée par défaut de nos jours que, dans le pire des cas, vous ne risquez pas de commettre de véritables erreurs de la part d'un utilisateur: imaginez que le client de messagerie électronique ne parvient pas à supprimer, maintenant l'état local est mauvais et tentent de supprimer le courrier électronique 4 mal aligné. avec le serveur, la grande majorité des développeurs back-end auront un verrou de sécurité pour garantir que vous ne supprimez que ce que l'utilisateur veut absolument et ainsi, ce désalignement ne provoquera pas de suppressions erronées (il peut échouer par erreur mais ne sera pas supprimé) .
Jimmy Hoffa le

@ JimmyHoffa, vous utiliseriez un identifiant de messagerie unique dans la demande de suppression. Il serait vraiment mauvais d'envoyer des demandes de suppression en fonction de l'ordre d'affichage arbitraire des e-mails dans votre boîte de réception.
Buttle Butkus

14

Les utilisateurs ne se soucient pas de ce que fait votre logiciel en coulisse: ils souhaitent que leurs actions aient un impact visible et puissent travailler à leur rythme.

Si une action aboutit côté client - comme la suppression d'e-mails -, vous devez également la mener avec succès sur le serveur. Pourquoi la suppression a-t-elle échoué? Si cela est dû à une limitation quelconque (par exemple, vous ne pouvez pas supprimer un courrier électronique qui a été archivé), vous devez en informer l'utilisateur avant que son action n'échoue.

Si l'erreur est provoquée par quelque chose de plus grave (disons une panne de base de données), vous devriez avoir un moyen de sauvegarder l'opération et de la réessayer lorsque le système sera à nouveau opérationnel.

Un bon exemple de gestion est la façon dont Facebook gère le chat. Il n'y a aucun moyen d'empêcher un utilisateur de se déconnecter brusquement, ce qui signifie qu'il ne pourra pas lire les messages que vous avez envoyés avant de partir. Au lieu d'afficher une erreur, le système enregistre tous ces messages et les met à la disposition de l'utilisateur à son retour. Aucune donnée n'est perdue.


2
+1 Excellent exemple de chat. La plupart des utilisateurs s'attendent à ce que leur message soit immédiatement mis à la disposition de tous, et comme ces messages échouent rarement, les utilisateurs ont l'illusion que c'est le cas.
Neil

1
@ Niphra, "Pourquoi la suppression a-t-elle échoué?" Le réseau peut échouer pour de nombreuses raisons, dont aucune avec votre application. Vous ne pouvez rien faire pour arrêter cela.
Pacerier

5

Vous pouvez faire un compromis entre les deux options. Par exemple, si l'utilisateur supprime un courrier électronique, vous pouvez le marquer en rouge ou en gris jusqu'à ce que vous obteniez une confirmation du serveur, puis seulement le supprimer de la liste. L'utilisateur peut toujours faire d'autres choses pendant qu'une action est en attente, donc elle ne bloque pas, mais cela laisse quand même un petit rappel pour l'utilisateur que leurs actions n'ont pas encore été validées.

Amazon AWS adopte cette approche: lorsque vous arrêtez / démarrez une instance, la case à cocher qui vous permet de la sélectionner se transforme en spinner (vous ne pouvez donc rien y faire pendant quelques secondes), mais cela ne vous empêche pas interagir avec d'autres instances.


Votre suggestion est similaire à la façon dont gmail affiche le texte "Enregistrer ..." pendant le transfert de XHR et "Enregistré" une fois que vous avez terminé. Si on disait toujours "Sauvé", qui le croirait?
Buttle Butkus

3

Je pense que cela vient avec de plus en plus de sites Web qui essaient de se comporter comme des applications et effectuent plus de traitements dans le navigateur (comme la validation des données de formulaire) que les sites plus traditionnels. Je ne vois pas trop de problème à cela tant que votre code est fiable et que vous pouvez vous attendre à ce qu'il réussisse dans des conditions normales.

Vous dites "C'est à ce moment que le code JavaScript découvre que la demande AJAX a échoué. Le script peut afficher un message d'erreur, mais il est vraiment inutile à ce stade."

Pourquoi devrait-il être inutile? Vous pouvez retourner dans la liste des courriels et recommencer la suppression. Pourquoi attendre à la place? Il n’ya pas vraiment de "risque" et ils ne "semblent" pas être rapides, ils travaillent plus vite. Donc, si l'activité n'est pas "critique", pourquoi être lent?


1
Peut-être qu'inutile n'était pas le bon mot, mais ce que je veux dire, c'est que le message d'erreur manque de contexte relatif, parce que l'utilisateur fait maintenant quelque chose de complètement différent. J'essaie de dire, c'est qu'à un utilisateur ignorant du Web, ils pensaient que les courriels avaient bien été supprimés. Alors pourquoi maintenant, plus tard, ils reçoivent un message d'erreur pour quelque chose qu'ils "ont vu" ont été supprimés. Pour nous, programmeurs, nous comprenons, mais pour les grands-pères utilisant Gmail, ils ne comprendraient pas.
Réactif le

La plupart des gens préfèrent utiliser une application où les choses se passent immédiatement, le système est réactif et il y a 1 chance sur 100 que l'interface utilisateur se mette à jour de façon étrange en cas d'erreur, plutôt qu'une application qui se fige pendant une seconde chaque fois qu'elle modifie une valeur.
Gort the Robot

1

Mon 2c est: il y a des situations où il est préférable d'avoir, comme vous dites, des opérations Ajax "non bloquantes" et d'autres où c'est un mauvais choix de conception. Exemple: voter une vidéo sur YouTube. Vous ne voulez pas vraiment qu'une partie de la page soit bloquée pendant que vous cliquez sur le petit bout qui commence ici. Il vaut mieux échouer en silence. Même un message de confirmation serait excessif. Toutefois, votre exemple de suppression de courrier électronique serait considéré comme obligatoire pour les demandes Ajax de type blocage.

Mongo DB fait quelque chose comme ça (et cela pourrait être considéré comme un exemple d'application Desktop). Ils ont différentes "préoccupations d'écriture" pour leurs opérations, et vous pouvez le configurer avec différentes valeurs pour chaque opération, allant de "revenir immédiatement et n'attendez rien" à "bloquer" jusqu'à confirmation du transfert réussi du réseau et puis retournez "à" attendez que le contenu soit correctement programmé pour l'écriture sur disque sur la machine distante avant votre retour ". De toute évidence, si vous créez un client lourd Desktop (en C ++ similaire) à l'aide du pilote Mongo, vous définissez le problème d'écriture le plus léger pour les opérations de base de données "critiques" (telles que la recherche de nouveaux messages), et d'autres sur des problèmes d'écriture plus stricts. .

Bien que je voie l’utilité d’Ajax non bloquant, je conviens avec vous que cela se fait trop souvent. À un moment donné, il y avait au moins un célèbre site de "réseautage social" qui le ferait pour le téléchargement de photos. Vous avez choisi votre photo à télécharger, puis bam, tout de suite, cela vous dira que c'est fait, et bien sûr, le lendemain, lorsque vous souhaitez ajouter d'autres photos (ou utiliser celles que vous pensiez avoir déjà ajoutées), ne devait jamais être trouvé. Plus tard, ils ont abandonné le processus et ont effectivement pris le temps d'attendre la réponse (et vous receviez parfois des messages du type «Impossible de télécharger une photo, essayez plus tard»).


+1 pour voir les choses à ma façon :). Le téléchargement de photos est un excellent exemple d'échec.
Réactif le

1
Pourquoi un téléchargement bloquant serait-il préférable? Dans Picasa (interface Web), vous pouvez faire glisser des photos vers l'intérieur, et pendant qu'elles téléchargent en arrière-plan, vous pouvez en faire glisser davantage, ou marquer des photos terminées, etc. Une opération de téléchargement
bloquée en
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.