Cher admins,
Je me permets de proposer un systeme anti-doublon pour les posts dans les forums et journaux (le phénomène est d'avantage localisé sur les forums néanmoins)
Le systeme est relativement simple dans l'idée (dans la pratique aussi, mais après ca dépend de votre structure actuelle que je ne connais pas trop)
A chaque fois qu'on ouvre un formulaire de post, un champs caché contient un ticket (un peu comme chez le boucher), et coté serveur, on attend le-dit numéro de ticket grace à une liste des tickets en attente.
Une fois posté, le serveur efface le numéro de ticket dans la liste de ceux en attente, et ainsi si un 2ème post est effectué avec le meme numéro de ticket, alors pouf, erreur, le numéro de ticket n'est pas dans la liste, vous avez surement dû poster en double.
C'est viable non ?
synthèse des modifs :
_une table de numéro de tickets
_une page intermédiaire au formulaire de saisie qui génére un numéro de ticket, le met dans la table du serveur, et génère la page de formulaire de saisie adéquate.
_un script de vérification de numéro de ticket avant l'intégration finale dans la base du formulaire posté
- cho7, qui tient vraiment a son systeme anti-double, surtout que depuis, il s'est lui meme fait avoir avec lynx :) -
Forum LinuxFr.idées Anti-double
1
sept.
2004
# Peut être un petit eclaircissement...
Posté par Anonyme . Évalué à 1.
Sinon je vois pas vraiment ce qui pourrait clocher...
[^] # Re: Peut être un petit eclaircissement...
Posté par Pinaraf . Évalué à 1.
[^] # Re: Peut être un petit eclaircissement...
Posté par cho7 (site web personnel) . Évalué à 2.
Pour la question de l'algo, il y aurait diverses possibilités, comme celle de générer un numéro de ticket en fonction de l'ID de session de la personne additionné du timestamp actuel, ce qui exclu toute chance de généré 2 fois le même numéro de ticket pour un utilisateur
pour récapituler :
on clique sur "Poster"
on créé un ticket sous la forme "id_session + timestamp"
on ajoute ce ticket dans la base du serveur
on créé le formulaire contenant un champ caché contenant lui meme le ticket
Quand on clique sur valider, le ticket est recherché dans la base du serveur, s'il existe alors on valide le message et on efface le numéro de la liste, autrement, erreur.
Voilà
[^] # Re: Peut être un petit eclaircissement...
Posté par Anonyme . Évalué à 1.
Si le navigateur quitte inopinément, le ticket reste t'il indéfiniment sur le serveur, ou possède t'il un temps limite avant d'être invalidé et détruit ?
Une raison voudrait que le premier cas ne soit pas valide, car si il le serait, il ne resterait plus qu'à créer un robot créant des tickets indéfiniment de manière à surcharger le serveur...
Mais je préfère m'abstenir de tout jugement hâtif...
[^] # Re: Peut être un petit eclaircissement...
Posté par cho7 (site web personnel) . Évalué à 2.
Ainsi on pourrait lancer ce script de nettoyage a interval régulier pour purger la table des tickets périmés
# Bonne idée
Posté par Twidi (site web personnel) . Évalué à 2.
Je génère pour chaque formulaire un nombre alétoire, je créé un fichier vide dans un répertoire dédié, et au moment de la validation, je n'ai qu'à vérifier l'existence de cette clé, et ainsi la supprimer
s'il utilise une seconde fois le même formulaire, la clé n'existe plus et son message est refusé
et j'ai un script en cron toutes les 30 mn qui efface les clés non utilisées depuis de plus d'une heure
Amha cela est bien plus rapide que de passer par du mysql (enfin pour moi car le formulaire etant sur chaque page, je génère une clé à chaque page, et j'économise avec ce système une requête par page, ce qui est précieux)
et c'est couplé avec un bête javascript sur le onsubmit du formulaire qui empeche de cliquer plusieurs fois (il y a aussi possibliité de masquer le bouton de validation)
[^] # Re: Bonne idée
Posté par Pooly (site web personnel) . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.