Discussion :

[mikldev]

Bonjour,

Je travaille sur un progiciel web en Java basé sur Struts et Hibernate déployé sur Tomcat.
Lorsque je clique deux fois rapidement (presque simultanément) sur un lien ou un bouton submit, cela déclenche 2 traitements identiques presque simultanément côté serveur. Ce traitement étant relativement lourd, je souhaite empêcher l'utilisateur de le faire plus d'une fois.

J'ai tenté de faire un synchronized(session) pour empêcher la récupération de la session utilisateur tant que le traitement n'est pas finit. Cela empêche bien un accès concurrent lors du traitement, mais ne règle pas le fait que le traitement est bien déclenché 2 fois.

Ayant aussi pas mal d'AJAX, je ne souhaite pas non plus limité 1 seule requête par utilisateur, je veux juste qu'il ne puisse pas faire 2 fois le même traitement simultanément.

Je me suis alors lancé dans une expérience pour bloquer les threads : création d'un Filtre ayant pour unique but de bloquer les thread associés à des requêtes identiques d'un même utilisateur si un premier thread est déjà en train d'effectuer le traitement.
Une fois que le premier thread a finit le traitement, il copie le contenu de la réponse dans le dernier thread alloué pour une même requête du même utilisateur. Ceci permettant de renvoyer au navigateur la réponse attendue.
Ceci marche plutôt bien, mais j'avoue que mon code est assez compliqué.

J'ai supposé que ce type de problème pouvait survenir dans n'importe quel type d'application web, mais à mon grand désespoir, je n'ai pas trouvé d'outil permettant de "bloquer" des requêtes simultanés et identiques d'un même utilisateur.

Connaissez-vous un outil ou un manière de faire permettant de gérer simplement ce problème ?

PS : impossible de bloquer l'appel avec du javascript côté client

Merci d'avance!

[dinobogan]

Tu pourrais stocker la date de la requête dans la session utilisateur. sur une nouvelle requête, le serveur vérifie la dernière date entrée. Si elle est trop récente, il n'effectue pas la requête.

[mikldev]

Bonjour et merci pour ta réponse.

Le problème c'est que le navigateur s'attend à afficher la réponse de la 2ème requête. Ce qui fait que si je ne renvoie pas la réponse de mon traitement dans la deuxième requête, j'obtiens une page blanche côté client.

Je trouve ça vraiment bizarre de ne pas avoir trouvé de problèmes similaires sur internet.

Une autre idée peut être ?

[tchize_]

il y a deux technique répandue pour éviter la double soumission. Une technique client et une technique serveur.

La technique client: un javascript associé au formulaire. Dès soumission, le formulaire disparait, ça empêche deux soumissions. Lorsque la réponse apparaitra, il y aura un nouveau formulaire.

La technique coté serveur. A chaque fois que tu génère un formulaire, tu lui ajoute un numéro unique. A chaque fois que tu traite un formulaire, tu regarde si ce numéro n'a pas déjà été traité. Si oui, tu refuse la deuxième requête.

Un alternative à cette technique est de mettre un filtre qui scanne tes paramètres de requetes et, pour certaines requetes, refuse la requete si la même requete exactement a été soumise il y a moins de xx secondes (ce ce que fait le forum pour information)

[ray_fab]

Moi je serais plutôt tenté à dirais de mettre une sécurité sur ton url, et là tu lui donnes le nombre maximum d'accès à l'url on va dire 1, donc lorsque l'utilisateur utilisateur est déjà "connecté" sur cette url la seconde va générer une erreur qu'il faudra gérer par exemple ne rien faire mais tu le gères comme tu veux.et une fois que le traitement de l'utilisateur est fini, tu le déconnectes, cela signifie que cette sécurité n'a rien à voir avec la sécurité de l'application, après c'est des logique qu'il faut gérer.
Mais en tout cas l'idée de cacher l'url par JavaScript est aussi pas mal. A toi de voir.

[mikldev]

Tout d'abord, merci pour vos réponses.

@tchize_ :
- Pour la technique côté client : je vais tente de cacher le formulaire en javascript, je n'avais pas pensé à cette possibilité (ayant testé pas mal de chose, je doute que cela fonctionne mais on verra bien :-)). Par contre, mon problème de double clique n’apparaît pas uniquement sur des soumissions, j'ai aussi le cas d'accès concurrents côté serveur sur des GET classiques (double clique sur <a href="">).

- Pour la technique côté serveur : j'avais déjà expérimenté ce type de solution. Le problème est que le navigateur client s'attend à recevoir la réponse de la deuxième requête, du coup si je la bloque, l'utilisateur verra afficher une jolie page blanche :-) Chose que je cherche à éviter.


@ray_fab : merci, mais je ne souhaite pas bloquer l'utilisateur à une seule requête. Sur un chargement de page, il se peut que j'ai 3 requêtes AJAX qui charges des parties spécifiques de ma page.

Encore merci !

[fr1man]

As tu regardé du côté des tokens de Struts ?
Ca correspond à ton problème.

[tchize_]

ben au lieu d'afficher une page blanche tu affiche une message qui explique le problème, tout simplement

Pour les GET, un get ne devrais pas forcer d'action dans le serveur et donc les GET simultanés ne devraient pas être un problème.