Résoudre le Double Problème d'envoi de

Je voudrais voir comment les Développeurs Web à éviter la double soumission problème. Donc, fondamentalement, ma compréhension du problème est comme suit:

Double soumission se produit lorsque impatiente un utilisateur soumet un formulaire à plusieurs reprises, à l'origine de problèmes. Ce problème peut être résolu par JavaScript (plus précisément de scripts jQuery) que de désactiver le bouton "soumettre" une fois que le formulaire a été soumis à une faiblesse de ceci est que si les clients ont désactivé JavaScript.

Il y a aussi le côté serveur de méthodes de détection.

Donc mes questions sont:

Comment surmonter la double soumission?
Qu'est ce qu'un exemple de la vie réelle d'un problème causé par double soumet?
N'importe quelle Application Web de Cadres ont la double soumission outils intégrés?

Exemple réel par paypal en ajoutant des éléments à la shoppin panier à plusieurs reprises,puisque l'utilisateur n'a pas obtenu de réponse , alors que la première demande est toujours en cours.
Voir question à ce sujet: stackoverflow.com/questions/2830542/...

InformationsquelleAutor JHarley1 | 2011-01-15

8

Si vous travaillez avec java scripts côté serveur et également l'utilisation de struts 2, alors vous consultez ce lien qui parle sur l'aide jeton .

http://www.xinotes.org/notes/note/369/

Un jeton doit être généré et maintenu dans la séance de la première page de rendu, lorsque la demande est soumise avec le jeton pour la première fois , dans struts action exécuter un filetage avec filetage nom de l'id de jeton et exécuter la logique de tout ce que le client a demandé , lors de la client soumettre de nouveau la même demande, vérifiez si le fil est toujours en cours d'exécution(thread.getcurrentthread().interrompu) en cas d'exécution puis de l'envoyer à un client de redirection 503.

Veuillez jeter un oeil à la ExecuteAndWaitInterceptor de struts 2code, la logique de ceci, combiné avec le jeton de l'aide rapidement et cliquez sur
- Les jetons de sessions de ne pas gérer la simultanéité bien. Par exemple, plusieurs onglets dans les navigateurs.
- Pouvez-vous expliquer, ce que u parlons abt plusieurs onglets
- Oups, mal lu la réponse. Pensé que vous signifie un jeton dans l'universel de la session.
- la session n'est pas universelle ,relatives à un utilisateur connecté.
- Non, là je ne comprends droit. Si un utilisateur ouvre plusieurs onglets dans un navigateur, puis les jetons peuvent être mélangées, car il n'y a toujours qu'une seule session de l'utilisateur.
- Le jeton généré dans le côté serveur ,est également présent dans le cookie.Même si vous ouvrez plusieurs onglets, le jeton est partagé en tant que le cookie est dans le même chemin d'accès au domaine.
- Oui, et c'est un problème. J'ai ouvert la page 1, vous cherchez à mettre à jour mon profil. Jeton de 1 est généré. J'ouvre un nouvel onglet, recherche pour mettre à jour la photo de mon profil. Jeton 2 est généré et stocké dans la session. - Je soumettre onglet 1, qui envoie un jeton de 1, ce qui ne correspond pas à jeton 2, donc pas de changement est engagé. Si je ne suis pas chanceux, page de profil génère maintenant jeton 3. - Je soumettre ma photo, qui envoie le jeton 2, qui maintenant ne correspond pas à jeton 3.
- La question posée par l'utilisateur du formulaire de soumission : 1. u peut avoir des champs cachés à l'intérieur html <form/> éléments qui interdit la double présentation 2. une fois que l'utilisateur soumet le formulaire , je le redirige vers une page avec les changements.
- Mais les jetons de session ne fonctionne pas toujours parce que ils ne gèrent pas les multiples fenêtres.
- onglet cookie spécifique. bytes.com/topic/javascript/answers/...
- Si il y a une façon de contourner, de les ajouter à votre réponse.
- Votre lien montre Struts 1 code et vous parlez de Struts 2. Ces 2 versions sont incompatibles.
- Le lien ci-dessus ne fonctionne pas correctement. Je pense qu'ils ont peut-être changé de données réelles à partir de ce site web. s'il vous Plaît mettre à jour votre réponse
InformationsquelleAutor Dead Programmer
16

En situation réelle: placer des paris sur un site de paris. Les utilisateurs auraient la double clic et d'obtenir deux paris placés. Pas bon!!! Javascript vérifications n'ont pas été suffisantes pour empêcher cela.

Solution:
1. Créer UUID/GUID caché d'entrée en forme à l'aide de scripts côté serveur de la langue qui rend le formulaire.
2. Sur le formulaire de soumission immédiatement ajouter à une table de base de données appelé UniqueSubmissions (par exemple). Puis poursuivez le traitement.
3. Chaque demande ultérieure ayant le même UUID/GUID sera rejetée s'il est trouvé dans la UniqueSubmissions table.
Cela a fonctionné pour nous. L'espoir qui permet de répondre à votre question!
- Bon! mais quel est l'UUID et le GUID stand for?
- Ajout de liens vers des UUID/GUID - la plupart des langues, vous donner un moyen de créer par programmation, par exemple j'utilise ColdFusion et je peux en créer un à l'aide de createUUID().
- Votre idée est très bien. Mais je pense que cette architecture seront confrontées à des limitations dans l'Ajax de réponse.La façon dont nous pouvons mettre à jour UUID?GUID avec le rendu de la page.
- cela fonctionne bien pour moi: document.querySelector("#submitbutton").addEventListener("click",function(ev){ev.target.disabled=true;}); - en supposant que l'actualisation de la page après avoir cliqué sur, par opposition à un XMLHttpRequest ou simmilar réponse
- Pourquoi Javascript n'a pas fonctionné, ce qui a été la mise en œuvre ?
InformationsquelleAutor Ciaran Archer
7

Utiliser le redirection après-post ou parfois appelé PRG (post/redirect/get)

En bref, lorsque l'utilisateur soumet le formulaire, vous pouvez effectuer une redirection côté client (après avoir consommé le post de données) à la réponse (succès) de la page.
- Bonne Réponse et donne certainement plus de profondeur que mon "côté Serveur méthodes". - Merci Beaucoup.
- cela n'empêchera pas rapide double-cliquez sur les problèmes de
- La redirection après-poste de patron est sympa, mais ça ne résout pas ce problème. Le problème est soit stupide utilisateurs qui double-cliquez sur le bouton "soumettre" ou usagers impatients qui re-soumettre le formulaire avant que la page est chargée. Deux de ces cas, avoir lieu avant la redirection après-post motif s'applique.
- Vous pouvez simplement désactiver le bouton "soumettre" après le premier clic pour gérer rapidement un double-clic.
- Ok droite, donc ce sera?
- C'est une solution, certes, mais ce qui se passe si l'utilisateur arrive à avoir désactivé JavaScript.
- alors je suppose que vous aurez besoin de stocker des côté client de l'état comme un champ caché dans le formulaire que vous renvoyer vers le serveur pour valider le post pour l'unicité.
- la seule solution ultime est de générer aléatoirement une forme uid/hash, mettre comme caché, et le marquer comme étant traitée une fois posté.
- une autre solution est de toujours comparer les données publiées par des valeurs réelles dans la base de données et vérifier si ou non vous devez mettre à jour les valeurs, mais ths ne peut pas toujours s'appliquer.
InformationsquelleAutor Joel
5

Un exemple réel serait cette réponse posté deux fois ;-).
Si vous ne voulez pas compter sur un quelconque aspect du côté client (javascript, ou même des cookies), vous pouvez calculer un hash MD5 de la base des données présentées, éventuellement en ajoutant des informations telles que l'adresse IP source et le type de navigateur utilisé, et de rejeter les postes qui ont le même hash.

InformationsquelleAutor Yack
3

La web2py cadre a protection intégrée contre la double soumission de formulaire. Il stocke un jeton dans la session ainsi que dans un champ caché dans le formulaire, et ils doivent correspondre moment de la soumission ou de la soumission est rejetée. De plus, cette méthode protège contre les CSRF (cross-site request forgery).
- Mon problème avec le jeton dans la session, c'est que si vous avez plusieurs pages ouvertes, les jetons peuvent être mélangées. Cependant, c'est OK pour les plates-formes qui ne peut que voir d'un écran à un temps (comme l'ancien Kindle, ou plus WML en fonction de téléphone cellulaire de navigateurs.)
- Si vous le souhaitez, vous pouvez donner la forme d'un nom unique à chaque fois qu'il est créé, de sorte que l'ouverture de la même forme dans une nouvelle fenêtre va pas remplacer la clé de l'original, de sorte que le formulaire pour être soumises à partir d'une autre fenêtre.
- Je ne suis pas sûr que je comprends ce que vous dites. Pourriez-vous me donner un exemple?
- import uuid form.process(formname=uuid.uuid4()). Maintenant, le formulaire est un nom unique à chaque fois qu'il est créé, si la même page est ouverte dans plusieurs onglets du navigateur/windows, la forme a un nom différent sur chaque page. Le jeton est associé avec le nom de formulaire, donc l'ouverture d'un deuxième page n'interfère pas avec le jeton de la première page.
- Je vais vérifier. Je vous remercie.
InformationsquelleAutor Anthony
2

Si le formulaire a l'intention de fournir une interface pour l'enregistrement de certaines données dans le serveur de bases de données, vous pouvez utiliser de révision spéciales champ est obligatoire pour les données soumises. A vérifier si oui ou non le soumis de révision correspond à la dernière version des données dans la base de données (ou est-ce un nouveau morceau de l'insertion de données), pourrait vous fournir avec un bon contrôle que faire si plusieurs soumet sont effectués dans l'ordre.
- PS ce mécanisme est obligatoire dans CouchDB et les déclencheurs sur les conflits de version
InformationsquelleAutor Dennis Kreminsky
1

En utilisant struts web-application du cadre de nous peut gérer ce problème comme suit:

Struts a 3 méthodes utiliser pour le token, saveToken(), isTokenValid() and resetToken().

saveToken() - générer le jeton de clé et de les sauvegarder sur demande/attribut de session.

isTokenValid() - valider soumis jeton de clé contre l'1 magasin dans la demande/session.

resetToken() - réinitialiser le jeton de clé.

Comment cela fonctionne:

1) Sur l'écran de chargement, invoque saveToken() sur la classe de l'action de créer et de stocker le jeton de clé. Struts va stocker la clé générée à la demande/session. Si le jeton créé avec succès, lors de l'affichage de la source sur le navigateur, vous verrez quelque chose de similaire à la suivante, le jeton de clé est stockée comme un champ caché:
```
<form action="myaction.do" method="post"> 
 <input type="hidden" 
 name="<%= Constants.TOKEN_KEY %>" 
 value="<%= session.getAttribute(Action.TRANSACTION_TOKEN_KEY) %>" > 
```
2) une Fois le formulaire soumis, invoque isTokenValid() sur l'action de la classe, il devra valider l'soumis jeton de clé(champ caché) avec le jeton de clé stockée précédemment sur demande/session. Si match, il retournera true.
```
public final ActionForward perform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
    saveToken(request);
    if (!tokenIsValid(request)) {
        //forward to error page saying "your transaction is already being processed" 
    } else {
        //process action 
        //forward to jsp 
    }
    //Reset token after transaction success. 
    resetToken(request);
}
```
référence

InformationsquelleAutor Premraj

Vous devez vous connecter pour publier un commentaire.