it-swarm.com.de

Wie sicher sind versteckte AJAX fordert diese gefälschte Leistung an?

Was ist eine versteckte AJAX Anfrage)?

Ich habe eine Zunahme der Verwendung von versteckten AJAX -Anfragen festgestellt, die die Aktion eines Benutzers sofort ausführen sollen. Ich werde auf diese Art von AJAX) verweisen = Anfrage als nicht blockierend. Es handelt sich um eine AJAX Anfrage, die gestellt wird, ohne dass der Benutzer weiß, dass sie stattfindet, sie wird im Hintergrund ausgeführt und der Vorgang ist stumm ( es gibt keine ausführliche Angabe) ein erfolgreicher Abschluss des Aufrufs AJAX). Ziel ist es, den Vorgang so erscheinen zu lassen, dass er sofort erfolgt, wenn er wirklich nicht abgeschlossen ist.

Hier sind Beispiele für nicht blockierende AJAX request;

  • Benutzerklicks löschen auf eine Sammlung von E-Mails. Die Elemente verschwinden sofort aus ihrem Posteingang und können mit anderen Vorgängen fortfahren. Währenddessen verarbeitet eine AJAX -Anforderung das Löschen der Elemente im Hintergrund.
  • Der Benutzer füllt ein Formular für neue Datensätze aus. Klicks speichern. Das neue Element wird sofort in der Liste angezeigt. Der Benutzer kann weiterhin neue Datensätze hinzufügen.

Zur Verdeutlichung finden Sie hier Beispiele für das Blockieren von AJAX request;

  • Benutzerklicks löschen auf eine Sammlung von E-Mails. Ein Sanduhr-Cursor wird angezeigt. Die Anforderung AJAX) wird gestellt, und wenn sie antwortet, wird der Sanduhrcursor ausgeschaltet. Der Benutzer muss eine Sekunde warten, bis der Vorgang abgeschlossen ist.
  • Der Benutzer füllt ein Formular für neue Datensätze aus. Klicks speichern. Das Formular wird grau mit einer AJAX Loader-Animation. Es wird die Meldung "Ihre Daten wurden gespeichert" angezeigt, und der neue Datensatz wird in der Liste angezeigt.

Der Unterschied zwischen den beiden oben genannten Szenarien besteht darin, dass ein nicht blockierendes AJAX Setup) keine Rückmeldung über eine Betriebsleistung liefert und ein blockierendes AJAX Setup).

Das Risiko versteckter AJAX Anfragen

Das größte Risiko für diesen Stil der AJAX -Anforderung besteht darin, dass sich die Webanwendung in einem völlig anderen Zustand befindet, wenn die AJAX -Anforderung fehlschlägt).

Zum Beispiel ein nicht blockierendes Beispiel;

  • Der Benutzer wählt eine Reihe von E-Mails aus. Klicken Sie auf die Schaltfläche Löschen. Der Vorgang scheint sofort zu erfolgen (die Elemente verschwinden einfach aus der Liste). Der Benutzer klickt dann auf die Schaltfläche zum Erstellen und beginnt mit der Eingabe einer neuen E-Mail. Zu diesem Zeitpunkt erkennt der JavaScript-Code die Anforderung AJAX fehlgeschlagen. Das Skript könnte eine Fehlermeldung anzeigen, ist aber zu diesem Zeitpunkt wirklich sinnlos.

Alternativ ein Blockierungsbeispiel;

  • Der Benutzer wählt eine Reihe von E-Mails aus. Klicken Sie auf die Schaltfläche Löschen. Sieht eine Sanduhr, aber die Operation schlägt fehl. Sie erhalten eine Fehlermeldung mit der Aufschrift "Fehler. Bla bla bla". Sie kehren zur Liste der E-Mails zurück und haben immer noch die E-Mails ausgewählt, die sie löschen möchten. Sie könnten versuchen, sie erneut zu löschen.

Es gibt auch andere technische Risiken für die Ausführung von nicht blockierenden AJAX -Anfragen. Der Benutzer könnte den Browser schließen, zu einer anderen Website navigieren und zu einem anderen Ort im aktuellen Web navigieren, der den Kontext bildet von jeder Fehlerantwort bedeutungslos.

Warum wird es so beliebt?

Facebook, Google, Microsoft, etc .. etc .. all diese großen Domains verwenden zunehmend nicht blockierende AJAX Anfragen, um Operationen durchzuführen erscheinen, dass sie ausgeführt werden sofort. Ich habe auch eine Zunahme von Formulareditoren gesehen, die keine Schaltfläche zum Speichern oder Senden haben haben. Sobald Sie ein Feld verlassen oder die Eingabetaste drücken. Der Wert wird gespeichert. Es gibt keine Ihr Profil wurde aktualisiert Nachricht oder Speicherschritt.

AJAX-Anforderungen sind keine Gewissheit und sollten erst nach Abschluss als erfolgreich behandelt werden, aber so viele wichtige Webanwendungen funktionieren einfach so.

Verwenden diese Websites nicht blockierende AJAX -Aufrufe, um reaktionsfähige Anwendungen zu simulieren, die ein unnötiges Risiko eingehen, wenn sie schnell erscheinen?

Ist dies ein Entwurfsmuster, dem wir alle folgen sollten, um wettbewerbsfähig zu bleiben?

48
Reactgular

Es ist nicht so sehr "falsche" Leistung als echte Reaktionsfähigkeit. Es gibt eine Reihe von Gründen, warum es beliebt ist:

  • Internetverbindungen sind heutzutage ziemlich zuverlässig. Das Risiko, dass eine AJAX - Anforderung fehlschlägt, ist sehr gering.
  • Die durchgeführten Operationen sind nicht wirklich sicherheitskritisch. Wenn Ihre E-Mails nicht auf dem Server gelöscht werden, müssen Sie sie im schlimmsten Fall erneut löschen, wenn Sie das nächste Mal auf die Seite gelangen.
  • Sie können Ihre Seite so gestalten, dass die Aktion rückgängig gemacht wird, wenn die Anforderung fehlschlägt. Sie müssen jedoch nicht so subtil sein, da dies bedeutet, dass Ihre Verbindung zum Server unterbrochen ist. Es ist einfacher zu sagen, dass die Verbindung unterbrochen wurde. Die letzten Änderungen können nicht gespeichert werden. Versuchen Sie es später erneut.
  • Sie können Ihre Seite so gestalten, dass nur eine ausstehende AJAX -Anforderung) zulässig ist, damit Ihr Status vom Server nicht zu stark synchronisiert wird.
  • Der Browser warnt Sie, wenn Sie versuchen, eine Seite zu schließen oder von dieser weg zu navigieren, während eine AJAX -Anforderung aussteht).

AJAX pending warning

61
Karl Bielefeldt

Es ist viel benutzerfreundlicher, anzunehmen, dass etwas funktioniert, und einen Fehler anzuzeigen, falls es auf der Remote-Seite fehlschlägt, als den Benutzer daran zu hindern, etwas anderes zu tun, bis eine Antwort vom Server eingeht.

Ein E-Mail-Client ist eigentlich ein tolles Beispiel dafür: Wenn ich eine Liste mit 5 E-Mails habe und die oberste ausgewählt ist, erwarte ich das beim Schlagen DEL dreimal werden die ersten drei E-Mails gelöscht. Mit "nicht blockierendes AJAX" funktioniert dies einwandfrei - jedes Mal, wenn ich die Taste drücke, wird die ausgewählte E-Mail sofort entfernt. Wenn etwas schief geht, wird ein Fehler angezeigt und entweder werden die nicht ordnungsgemäß gelöschten E-Mails erneut angezeigt OR Die Seite wird neu geladen, um den inkonsistenten lokalen Status zu beseitigen.

Im am häufigsten vorkommenden - das ist Erfolg - verbessert es die Benutzerfreundlichkeit. Im seltener Fall - Fehler - wird die Benutzerfreundlichkeit beeinträchtigt (gelöschtes Element wird erneut angezeigt oder die Anwendung wird "neu gestartet"), aber beim Erstellen einer Anwendung möchten Sie normalerweise die beste Benutzerfreundlichkeit für häufige Fälle haben, nicht im Fehlerfall.

32
ThiefMaster

Den Benutzern ist es egal, was Ihre Software hinter den Kulissen tut: Sie möchten, dass ihre Aktionen sichtbare Auswirkungen haben und in ihrem Tempo arbeiten können.

Wenn eine Aktion auf der Clientseite erfolgreich war - wie das Löschen von E-Mails -, ist es Ihre Aufgabe, sie auch auf der Serverseite erfolgreich zu machen. Warum ist das Löschen fehlgeschlagen? Wenn dies auf eine Einschränkung zurückzuführen ist (z. B. können Sie eine archivierte E-Mail nicht entfernen), sollte der Benutzer darauf hingewiesen werden, dass vor seine Aktion fehlgeschlagen ist.

Wenn der Fehler durch einen schwerwiegenderen Fehler verursacht wird (z. B. einen Datenbankabsturz), sollten Sie die Möglichkeit haben, den Vorgang zu speichern und erneut zu versuchen, wenn das System wieder hochgefahren ist.

Ein gutes Beispiel dafür ist die Art und Weise, wie Facebook den Chat abwickelt. Es gibt keine Möglichkeit, einen Benutzer daran zu hindern, die Verbindung plötzlich zu trennen. Dies bedeutet, dass er die von Ihnen gesendeten Nachrichten vor dem Verlassen nicht lesen kann. Anstatt einen Fehler anzuzeigen, speichert das System alle diese Nachrichten und stellt sie dem Benutzer zur Verfügung, wenn er zurückkommt. Es gehen keine Daten verloren.

14
DistantEcho

Sie können zwischen den beiden Optionen Kompromisse eingehen. Wenn der Benutzer beispielsweise eine E-Mail löscht, können Sie sie rot oder grau markieren, bis Sie eine Bestätigung vom Server erhalten, und sie erst dann aus der Liste entfernen. Der Benutzer kann noch andere Dinge tun, während eine Aktion aussteht, sodass sie nicht blockiert, aber dennoch eine kleine Erinnerung für den Benutzer hinterlässt, dass seine Aktionen noch nicht festgeschrieben wurden.

Amazon AWS verfolgt diesen Ansatz: Wenn Sie eine Instanz stoppen/starten, wird das Kontrollkästchen, mit dem Sie sie auswählen können, zu einem Drehfeld (sodass Sie einige Sekunden lang nichts dagegen tun können). Dies blockiert Sie jedoch nicht Interaktion mit anderen Instanzen.

5
valtron

Ich denke, dies geht einher mit immer mehr Websites, die versuchen, sich wie Anwendungen zu verhalten und mehr im Browser zu verarbeiten (wie das Überprüfen von Formulardaten) als die traditionelleren Websites. Ich sehe darin kein allzu großes Problem, solange Ihr Code zuverlässig ist und Sie erwarten können, dass er unter normalen Bedingungen erfolgreich ist.

Sie sagen: "Zu diesem Zeitpunkt erkennt der JavaScript-Code die Anforderung AJAX fehlgeschlagen. Das Skript könnte eine Fehlermeldung anzeigen, ist aber zu diesem Zeitpunkt wirklich sinnlos."

Warum sollte es sinnlos sein? Sie können in die Liste der E-Mails zurückkehren und den Löschvorgang erneut durchführen. Warum stattdessen warten? Es gibt eigentlich kein großes "Risiko" und sie "scheinen" nicht schnell zu sein, sie arbeiten tatsächlich schneller. Also, wenn die Aktivität nicht "kritisch" ist, warum langsam sein?

3

Mein 2c ist: Es gibt Situationen, in denen es besser ist, wie Sie sagen, "nicht blockierende" Ajax-Operationen zu haben und andere, in denen es eine schlechte Wahl für das Design ist. Beispiel: Abstimmung eines YouTube-Videos. Sie möchten nicht, dass ein Teil der Seite blockiert wird, während Sie auf die kleinen Starts dort klicken. Es ist besser, stillschweigend zu scheitern. Sogar eine Bestätigungsnachricht wäre übertrieben. Ihr Beispiel für das Löschen von E-Mails würde ich jedoch als obligatorisch für Ajax-Anfragen vom Blockierungstyp qualifizieren.

Mongo DB macht so etwas (und dies könnte als Desktop-Anwendungsbeispiel angesehen werden). Sie haben verschiedene "Schreibprobleme" für ihre Vorgänge, und Sie können sie für jeden Vorgang auf unterschiedliche Werte konfigurieren, von "Sofort zurückkehren und auf nichts warten" bis "Blockieren", bis Sie die erfolgreiche Netzwerkübertragung bestätigt haben und Kehren Sie dann zu "zurück" zurück und warten Sie, bis der Inhalt ordnungsgemäß für das Schreiben der Festplatte auf dem Remotecomputer geplant ist, bevor Sie zurückkehren. Wenn Sie einen Desktop-Thick-Client (wie in C++) mit dem Mongo-Treiber erstellen, stellen Sie natürlich das geringste Schreibproblem für Datenbankoperationen mit minimaler "Kritikalität" (z. B. das Suchen nach neuen E-Mails) und andere für strengere Schreibprobleme ein .

Obwohl ich die Nützlichkeit von nicht blockierendem Ajax sehe, stimme ich Ihnen zu, dass es zu viel passiert. Zu einem bestimmten Zeitpunkt gab es mindestens eine berühmte "Social Networking" -Seite, die dies für das Hochladen von Fotos tun würde. Sie haben Ihr Foto zum Hochladen ausgewählt und dann bam, es würde Ihnen sofort sagen, dass es fertig ist, und dann sicher genug am nächsten Tag, wenn Sie weitere Fotos hinzufügen möchten (oder für das verwenden möchten, von dem Sie dachten, dass Sie es bereits hinzugefügt haben) war nie zu finden. Später gaben sie dies auf und nahmen sich tatsächlich die Zeit, um auf die Antwort zu warten (und Sie erhielten tatsächlich manchmal Nachrichten wie "Foto konnte nicht hochgeladen werden, versuchen Sie es später").

1
Shivan Dragon