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

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?

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.

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.

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.

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.

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?

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»).