BANNIR UN UTILISATEUR PAR COOKIE
ehectsamira
Messages postés
14
Date d'inscription
mardi 8 février 2005
Statut
Membre
Dernière intervention
11 janvier 2008
-
31 mars 2007 à 01:06
p3x Messages postés 214 Date d'inscription vendredi 30 juillet 2004 Statut Membre Dernière intervention 9 janvier 2019 - 7 juil. 2008 à 14:39
p3x Messages postés 214 Date d'inscription vendredi 30 juillet 2004 Statut Membre Dernière intervention 9 janvier 2019 - 7 juil. 2008 à 14:39
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/42024-bannir-un-utilisateur-par-cookie
https://codes-sources.commentcamarche.net/source/42024-bannir-un-utilisateur-par-cookie
7 juil. 2008 à 14:39
- si l'utilisateur n'a pas de cookie il ne sera pas banni mais le script va lui en recréer un.
- si tu veux bannir un user il faut changé juste le champ ban de 0 à 1 dans la table.
Et l'intérêt en fait du script c'est que tu peux très bien bannir un utilisateur même si il n'est pas membre ou inscrit sur le site.
Si par exemple tu décide de mettre un forum sur un site et que sur celui-ci les utilisateurs ne sont pas obligé de s'inscrire pour poster des messages, si il y a un abus tu peux tjs bannir.
Mais pour bien identifier l'utilisateur, il faut bien sur créer une relation entre les ID de la table cookie et les ID de la table forum.
7 juil. 2008 à 11:28
Pour moi, le plus efficace est le plus ennuyant pour l'utilisateur est de bannir son adresse e-mail et son pseudo EN PLUS de lui coller un cookie sur le nez. Il suffit de garder l'entrée de l'utilisateur dans la table et de créer un champ qui vaudra 1 lorsque l'utilisateur est banni, sinon 0. Au moment de se connecter, si son statut est bann, il ne pourra pas se connecter. Si il veut recréer un compte, il ne pourra pas utiliser la même adresse e-mail OU le même pseudo. Ca en dissudera plus d'un.
Le cookie permet d'en rajouter une couche en 2ème condition lors de la connexion, de l'inscription ou même de l'accès au site.
Comme dit plus haut, il est impossible de bannir définitivement quelqu'un, comme il est impossible de se targuer d'avoir un site 100% sécurisé. Mais il y a statistiquement moins de chance de déjouer un système qui possède un maximum de portes.
2 avril 2008 à 13:20
L'idée du cookie est interressante , mais je trouve qu'il est plus logique de faire l'inverse , c'est a dire : si un cookie est inscrit sur l'ordi = accés ok au site. Pas de cookie=pas d'accés. c'est plus logique dans la mesure ou la personne ne pourra pas "s'écrire" un cookie pour aller sur le site , il est en effet plus facile de s'effacer le cookie pour pouvoir visiter le site que de s'en ecrire un ;)
Bonne journée a tous.
21 janv. 2008 à 19:27
Sinon ban tt le monde .. ou personne c'est encore mieux !
8 avril 2007 à 01:10
J'imagine que pour banir quelqu'un definitivement, il faut qu'il est prealablement cree un compte que tu supprimes derriere... je vois pas trop comment faire pour supprimer de maniere sur quelqu'un surfant juste sur ton site sans y etre connecte. On a deja parler de la protection IP trop facilement contournable (suffit de taper "free proxy server" sur google pour regler la question).
As-tu eu utilise ton script dans des cas particulier (autre qu'un forum) ?
Rajoutes-tu quelque chose derriere ?
"euh.... FHX, ca c'est uniquement quand t'as un joli reseau feminin avec des jolies NAT...
si A n'a pas l'adresse ip de C. c'est que t'as mis une regle MASQUERADE."
Un reseau feminin ? C'est quoi ?
+1 pour FhX.
Je bosse dans l'administration reseau et la premiere chose que l'on apprend, c'est que les reseaux n'utilisent pas les adresses IP comme on le pense mais bel et bien les adresses MAC (via le protocole ARP et RARP). Dans l'exemple de A voulant discuter avec C en passant par B, C aura bel et bien l'adresse IP de A mais jamais son adresse MAC. C'est grace au routage effectue par B qu'un packet peut changer de reseau. B entretient une table de routage associant les adresses IP au adresse MAC des prochains routeurs.
Pas besoin d'un reseau local (cas de la mascarade comme tu l'as mentionne), ce shema fonctionne sur internet tous les jours (rien qu'en se connectant sur CS par exemple ;-) ). On peut voir les passerelles via un banal traceroute (mais j'imagine que tu le sais deja :p)
@++
5 avril 2007 à 01:24
- $HTTP_COOKIE_VARS est toujours obsolète et le sera toujours
- toujours pas de traitement des données fournies par le cookie... c'est un coup à se faire plomber sa base de données
- SELECT * à virer vu que tu connais les champs à récupérer
- tu ne vérifie pas si ta requête renvoie quelque chose avant de faire ton fetch
- réassigner les variables à partir de $data est un peu inutile surtout que si mysql ne renvoie pas de résultat $data vaudra false
- pourquoi tu t'entête à faire une requête pour récupérer le dernier id inséré alors que tu peut mettre le champ id en auto increment et utiliser mysql_insert_id()... qui plus est déclare le comme clé primaire ça optimisera un peu les requêtes
- ton <noscript> ne sert toujours à rien
- else { if($ban 1) {
>
else if(!empty($ban)) {
- il faut spécifier un temps avant l'expiration du cookie dans ton setcookie() sinon ce dernier expire à la fermeture du navigateur et dans ce cas autant utiliser les sessions... .. .
Sinon il serait bien d'implémenter un garbage collector parce que en procédant comme tu le fait dans quelques mois ta table sera pleine à craquer... .. .
@ tchaOo°
4 avril 2007 à 18:41
Je parle bien d'adressage MAC et non adressage IP ici.
En effet, A voit bien C en adresse IP. Mais pas en adresse MAC.
C'est pas ma faute ca, c'est IP (couche 3) qui est comme ca :p
La résolution d'adresse MAC ne peut se faire qu'au sein d'un même réseau :)
Ex simple :
internet
|
ordi1
|
-------------
| | |
ordi2 ordi3 ordi4
Les ordis du sous reseau n'enverront leurs adresses MAC qu'aux mêmes ordis de ce sous-reseau... Donc à ordi1, ordi2, ordi3, ordi4.
Jamais un PC au dessus de ordi1 ne verra l'adresse MAC de ordi2, ordi3 ni ordi4.
C'est ordi1 qui se chargera de faire la traduction des adresses.
Mais masquer l'IP revient à faire comme tu dis oui :)
4 avril 2007 à 07:44
si A n'a pas l'adresse ip de C. c'est que t'as mis une regle MASQUERADE.
4 avril 2007 à 02:13
@ tchaOo°
3 avril 2007 à 19:47
Impossible, et cela est du au réseau en lui même.
Pourquoi ?
Imaginons 3 nodes.
A <=> B <=> C
A veut parler à C, mais doit passer par B.
A envoie un paquet à B avec son adresse IP et son adresse MAC.
B lui renvoit sa propre IP avec sa propre adresse MAC afin qu'il y est communication .
Puis, B va lire le paquet de donnée que A veut envoyer pour C. Il va créer un nouveau paquet avec en entête non pas l'adresse IP et MAC de A, mais ses propres adresses à lui ! Ce qui est normal d'ailleurs.
Donc, B envoie un paquer à C avec son adresse IP et son adresse MAC.
C lui renvoit sa propre IP avec sa propre adresse MAC afin qu'il y est communication.
B envoit le paquet à C.
C répond à B.
B répond à A.
Jamais A ne va parler à C directement.
Donc jamais C ne verra l'adresse MAC de A et vice-versa.
Et voila :)
3 avril 2007 à 19:02
Ne pas pouvoir récupérer l'adresse mac par exemple.
fodrai qu'il l'otorise comme ca on sauré tou ce qu'il se passe sur internet. Autoriser l'adresse mac ca seré une nouvelle police virtuel une révolution quelque part !
3 avril 2007 à 02:36
Le truc chiant par contre c'est pour reconnaitre les internautes le coup des id numériques c'est pas super clair... en même temps y a pas 36 solutions... à creuser... .. .
@ tchaoO°
2 avril 2007 à 22:36
2 avril 2007 à 21:55
2 avril 2007 à 21:44
2 avril 2007 à 19:06
PS : je sens que le débat n'a pas prêt de se finir. Lol.
2 avril 2007 à 18:49
Car ton script est caduque dans ce cas la.
Certes, l'idée en soi n'est pas mauvaise car il n'existe aucun moyen permettant de bannir définitivement quelqu'un... mais un rappel ne fait pas de mal à personne.
Je viens de relire le premier post de Kankrelune... c'est vrai qu'on peut le prendre mal parce que c'est toi qui post ta propre source, mais il n'a pas totalement tord non plus.
Il est vrai qu'un cookie de session, ca se voit moins... mais cela veut dire aussi qu'il faut ralonger le temps des sessions, et ca par contre, c'est pas forcément plus cool ^^
Il faut réussir à trouver un compromis. Oui, ta solution peut être utilisée en complément d'autres solutions.
Mais je reviens sur ce que tu m'as dit quand même (^^) :
"FHX lorsqu'on dit "faire le script seuleument par cookie sans base de données", ca veut dire sans espace de stockage d'info donc ca implique ton fichier texte par exemple."
Non c'est totalement faux. Mauvaise expression de ta part. Pour moi, ne pas utiliser une base de donnée ne signifie pas qu'on ne peut pas utiliser le système de fichiers. Les sessions sont bien basées sur des fichiers, sans base de données, mais je pourrais très bien le faire (je l'ai déja fais et j'ai posté la solution ici ^^).
Petit problème d'expression... pas bien méchant :)
J'irais aussi la dessus :
"C'est bien joli de bannir, mais encore, il faut savoir QUI bannir ;)"
En effet, le seul moyen de savoir QUI vient visiter ton site, cela reste l'adresse IP. Hors tout le monde sait ce qu'on peut en faire de cette IP... !
Bref, c'est le brouillard :)
2 avril 2007 à 18:46
je suis daccord avec toi mais à la base on parle d'un script qui permet de bannir par selection de l'administrateur et non pas un script qui banni automatiquement en fonction des comportement des utilisateurs.
En gros l'admin banni qui il veut, quand il veut, même si l'utilisateur n'a rien fait.
Mais en réalité j'ai choisi de mettre une BDD au départ pour pouvoir plutard y intégrer un module de stats. Je comptais le modifier peu à peu (enfin tu verras ;)).
Sinon c'est bien ce que je disais plus haut, si on a un espace membre, forum, chatbox... on peut très simplement associer les tables entre elles pour y bannir l'id associé au nom, pseudo, email... J'ai réalisé cette source avant tout pour qu'elle soit intégrer à un module.
2 avril 2007 à 01:20
Reprenons et dans le calme... avant tout concernant ton dernier post j'aimerais bien que tu m'explique ce que c'est qu'un cookie si ce n'est un espace de stockage sous forme de fichier... .. . ;o)
Enfin bref... vu que l'on ne se comprend pas je vais imager ce que je dis... moi sur la plupart des sites que je fais je bannis l'internaute 30 minutes lorsque ce dernier s'est planté 3 fois de couple login/pass... pareil lorsqu'une attaque est suspectée ou encore lors d'une tentative de flood... à quoi me servirait une base de données... à rien... tu dis que faire un script qui bannis automatiquement est impossible mais biensur que non... c'est très simple il suffit de réagir en fonction du comportement de l'utilisateur... qui plus est le site ne serait pas perdu... cookie ban, pas cookie pas ban donc cookie expiré = pas ban... pas besoin d'avoir fait math sup pour comprendre ça... en fait comme je l'ais déja dis...
"après tout dépend de la définition que tu as du ban et de la façon dont tu souhaite le déployer"
Je pense qu'il a pas plus clair... .. .
Autre remarque... j'aimerais bien savoir comment tu vas bannir un internaute X... imaginons par exemple... que je tente de hacker ton site... tu t'en rend compte dans les log de tes stats (url suspects) tu fais comment avec tes id numériques dans ta table... tu le saura d'où que je suis le visiteur n° 6789... ou alors tu integre ce script dans un espace membre et à ce moment là effectivement tu peux utiliser une base de données mais juste par le biais d'une simple modification de la table user (1 champ "banished" en plus) associé aux cookies... .. .
Voili voilou
@ tchaOo°
1 avril 2007 à 19:20
mais bon je crois qu'il est temps que l'on arrête de causer de ca.
UN SRCIPT BANNISSANT LES UTILISATEURS D'UN SITE DISPOSE FORCEMENT D'UNE BASE DE DONNEES POINT FINAL.
1 avril 2007 à 19:09
1 avril 2007 à 18:51
Un fichier coté serveur ?
Bah vi, ca marche aussi bien ^^
Une base de donnée c'est quoi à la base ? Bah un fichier !!
Bon maintenant, une BDD c'est une multitude de fichiers... mais quand même :)
Ce que tu peux faire en SQL maintenant, on le faisait avec des fichiers avant :)
1 avril 2007 à 16:40
1 avril 2007 à 16:38
vous êtes des codeur ou non ?
merci JDALTON42 tu me sauve la vie -.-
1 avril 2007 à 16:36
1 avril 2007 à 16:33
c'est pas difficile a comprendre donc la base de donnée est indispensable !
1 avril 2007 à 16:29
1 avril 2007 à 16:27
je pète un plomb personne n'a encore compris !
1 avril 2007 à 16:16
1 avril 2007 à 16:13
1 avril 2007 à 16:02
Comment sans base de données l'admin fait-il pour bannir une personne ? C'est à dire quelles seraient les étapes que le script suivraient ?
si vous avez la réponse bah sérieux bien joué...
1 avril 2007 à 15:58
C'est bien joli de bannir, mais encore, il faut savoir QUI bannir ;)
1 avril 2007 à 15:37
Si ... contient le cookies banned avec la valeur 1.
Il est banni.
Pas besoin de stocker quoique ce soit dans une bdd.
Et perso si jme fait bannir jvé y penser au cookies.
1 avril 2007 à 15:28
1 avril 2007 à 15:24
1 avril 2007 à 14:55
bannir quelqu'un sans base de données et juste par cookie n'est pas possible ou alors si tu peux réaliser un script pareil j'aimerais te le voir faire. Car comment veux tu cibler ton utilisateur à bannir ? Et il faut bien que ton script sache qui bannir et pour ca il faut bien qu'une liste de ban soit existante dans lequel ton script va chercher (c'est pourtant clair).
Si l'on prend t'as méthode il faudrait modifier le cookie de l'utilisateur si je comprend bien ? mais comment veux tu modifier le cookie d'un utilisateur qui n'est pas connecter au site (c'est impossible) ?
Je te le prouve très simplement :
tu m'as dit mot pour mot : "si l'internaute à le cookie c'est qu'il est banni point... s'il ne l'a pas c'est qu'il n'est pas banni ou qu'il a viré le cookie "
La création de cookie se fait obligatoirement par script automatique si on peut dire.
C'est à dire que l'hors de sa création personne ne peut changer vraiment les valeurs. Ce sont des valeurs prédéfinis sur le site.
Cela veut dire qu'un site basique avec lequel on placerait un script pour bannir sans base de données créérait automatiquement des cookies avec toujours la même valeur et ne saurait vraiment quand changer le cookie sans liste de banni.
Autrement dit tous les utilisateurs seraient toujours non-banni, ou tous les utilisateurs seraient toujours bannis.
Enfin je sais pas si t'as vraiment compris le fond de ce que je veux dire...
Mais sérieux essais de faire un script de bannissement seuleument par cookie.
Pour moi c'est impossible. J'aimerais bien que les autres donnent leurs opinions la dessus d'ailleurs.
1 avril 2007 à 12:44
Concernant l'utilisation de mysql je le redis utilisé comme ça l'est dans ta source c'est inutile... si l'internaute à le cookie c'est qu'il est banni point... s'il ne l'a pas c'est qu'il n'est pas banni ou qu'il a viré le cookie (ça sert à rien de lui mettre un cookie pour dire qu'il n'est pas banni)... pas besoin de faire des requêtes inutiles et surcharger la base de donnée pour rien car si l'utilisateur supprime son cookie l'entrée elle, restera dans la table et comme tu n'a pas prévu de garbage collector ta table risque de vite être remplie... le seul avantage dans l'utilisation d'un base de donnée est de pouvoir retrouver une liste des actuellement personnes bannies pour savoir qui est banni et pour au besoin le dé bannir... effectivement la ça deviendrait utile mais là une liste serait peut explicite vu que le seul point de reconnaissance des bannis c'est un id numérique ("tiens je vais dé bannir l'internaute n° 673")... quand au code pour bannir quelqu'un il est très simple et tiens en quelques lignes... et je vois pas en quoi il serait plus compliqué que l'activation via la base de données ("tiens je vais bannir l'internaute n° 845")... après tout dépend de la définition que tu as du ban et de la façon dont tu souhaite le déployer pour moi un ban est définitif (en terme de décision) et expire quand on a dit qu'il devait expirer et dans ce cas pas besoin de s'embêter avec une base de données... .. .
@ tchaOo°
ps: à aucun moment je ne t'ai chambré... sinon tu l'aurait sentis passé... il ne faut pas prendre mon commentaire comme tel mes remarques sont strictement techniques... .. . ;o)
1 avril 2007 à 05:22
Mais sinon dire que mon script n'est pas bon et que la méthode n'est pas fiable est un peu trop exagéré. Car si tu regarde bien c'est la meilleure des solutions pour bannir un utilisateur le plus longtemps possible. Aucune autre plus fiable n'existe si tu cherche bien. Et le script reste soft pour l'intégrer à tout site qui pourait l'associer à un forum par exemple.
Tu dis KANKRELUNE qu'une base de donnée ne sert à rien ici mais comment veux tu avoir une liste d'utilisateur banni enregistrée sur le site sans base de donnée ?
Car il faut d'un côté un id stocké sur la machine de l'utilisateur (en l'occurence ici le cookie) et le même id associé à une valeur ban stocker sur le serveur du site (c'est à dire la bdd) pour que le script puisse gérer les deux entrées et donc dire si l'utilisateur est banni ou non.
Ca parait logique non ? Tu voulais faire comment ? stocker la valeur ban sur le cookie ? c'est insensé : l'admin ne pourait pas changer la valeur du cookie à moin de générer un script auto qui le fasse à la prochaine connexion de l'utilisateur. Et encore il faudrait à ce moment donné l'information à ce script manuellement auparavent. C'est absurde car cela fait encore plus de ligne de code et ajoute une action de traitement des informations suplémentaire.
Enfin bref tout ça pour te dire que tu as l'air très doué en code mais vrément pas logique dans ta manière de faire les choses.
PS : qui chambre se fait chambrer mais merci quand même pour les conseils ;)
1 avril 2007 à 02:19
if(isset($_COOKIE['isBanished']))
die('Vous n\'avez plus l\'autorisation d\'accéder à ce site');
else
setcookie('isBanished','yes', (time() + 3600));// + 3600 1 h de ban (1 h 3600 sec)
Dans ce cas le ban expire en même temps que le cookie... .. .
@ tchaOo°
1 avril 2007 à 00:10
31 mars 2007 à 22:52
Meme si par ip n'est pas fiable a 100% a cause des proxy, ip dinamique...
31 mars 2007 à 21:15
je sais qu'on sait le faire avec le cookie mais je sais pas comment avec les session...
31 mars 2007 à 15:44
if(!isset($_SESSION))
session_start();
$time = time();
if(isset($_SESSION['isBanished']) && $_SESSION['isBanished'] > $time)
die('Vous n\'avez plus l\'autorisation d\'accéder à ce site');
elseif(isset($_SESSION['isBanished']))
unset($_SESSION['isBanished']);
Ensuite pour bannir...
$_SESSION['isBanished'] = time()+3600; // + 3600 = 1 heure de ban (1 h = 3600 sec)
Voila... sinon... .. .
$cook $HTTP_COOKIE_VARS["p3x_cook"];
>
les $HTTP_*_VARS sont dépréciés on utilise les super globales $_* ici $_COOKIE... tu ne vérifies même pas que l'index p3x_cook existe...
----------------------------------------
// Sélection de la table p3x_cook
$sql = "SELECT * FROM p3x_cook WHERE id='$cook'";
$req = mysql_query($sql) or die('Erreur SQL !'.$sql.' '.mysql_error());
while($data = mysql_fetch_array($req))
{
// Si un des identifiants sélectionnés est égal au cookie on récupère
// les variables dernière date de connexion et banni
$ban = $data['ban'];
$date = $data['date'];
$id = $data['id'];
}
=>
un SELECT * est inutile et lourd... tu sais de quels champs tu as besoin... tu ne tiens pas compte du fait que mysql peut ne pas renvoyer de résultat... ou plutôt tu en tiens compte mais de la mauvaise façon... qui plus est tu as une belle faille à la sql injection (ne jamais faire confiance aux données soumise par l'internaute les cookie en faisant partie)... pas besoin non plus de faire une boucle sur le résultat mysql étant censée te renvoyer une entrée ou 0 entrée...
// Sélection de la table p3x_cook
$sql = 'SELECT ban,date,id FROM p3x_cook WHERE id=\''.mysql_real_escape_string($cook).'\'';
$req = mysql_query($sql) or die('Erreur SQL !'.$sql.' '.mysql_error());
$ban = array();
if(mysql_num_rows($req) !== 0)
$ban = mysql_fetch_assoc($req);
--------------------------------------
if($id == NULL)
{
// Sélection du dernier identifiant de la table p3x_cook
$sql = "SELECT * FROM p3x_cook ORDER BY id DESC LIMIT 1";
$req = mysql_query($sql) or die('Erreur SQL !'.$sql.' '.mysql_error());
while($data = mysql_fetch_array($req))
{
// Initialisation d'une nouvelle variable identifiante
$id = $data['id']+1;
}
// Insertion de cette variable dans la table p3x_cook avec la date d'aujourd'hui
$sql = "INSERT INTO p3x_cook VALUES($id, 0, '$date2')";
$req = mysql_query($sql) or die('Erreur SQL !'.$sql.' '.mysql_error());
// Création d'un nouveau cookie qui dispose de ce nouvel identifiant
setcookie("p3x_cook",$id);
}
=>
Ce passage du code est bien étrange... pourquoi faire une boucle pour récupérer id alors qu'en auto increment suffirait (couplé avec mysql_insert_id())... la balise noscript est inutile au passage...
if(empty($ban))
{
// Insertion de cette variable dans la table p3x_cook avec la date d'aujourd'hui
$sql = 'INSERT INTO p3x_cook VALUES(\'\', 0, \''.$date2.'\')';
$req = mysql_query($sql) or die('Erreur SQL !'.$sql.' '.mysql_error());
// Création d'un nouveau cookie qui dispose de ce nouvel identifiant
setcookie("p3x_cook",mysql_insert_id());
}
elseif(!empty($ban['ban']))
die('Vous n\'avez plus l\'autorisation d\'accéder à ce site');
reprenons depuis le début...
// Initialisation des variables de connexion à la base de données
$serveur = 'localhost';
$user = 'login';
$password = 'passe';
$base = 'bdd';
// Récupération des variables date d'aujourd'hui et
// initialisation da la variable avec les infos sur le ban
$date = date("j/m/Y");
$banInfos = array();
// Connexion à la base de donnée.
$connexion = mysql_connect($serveur,$user,$password);
$db = mysql_select_db($base, $connexion);
// l'internaute a t il le cookie si oui on cherche dans la bdd
if(isset($_COOKIE['p3x_cook']))
{
// Sélection de la table p3x_cook
$sql = 'SELECT ban,date,id FROM p3x_cook WHERE id=\''.mysql_real_escape_string($_COOKIE['p3x_cook']).'\'';
$req = mysql_query($sql) or die('Erreur SQL !'.$sql.' '.mysql_error());
if(mysql_num_rows($req) !== 0)
$banInfos = mysql_fetch_assoc($req);
}
// si banInfos est vide c'est que l'on a pas trouvé l'internaute dans la base
if(empty($banInfos))
{
// Insertion de cette variable dans la table p3x_cook avec la date d'aujourd'hui
$sql = 'INSERT INTO p3x_cook VALUES(\'\', 0, \''.$date.'\')';
$req = mysql_query($sql) or die('Erreur SQL !'.$sql.' '.mysql_error());
// Création d'un nouveau cookie qui dispose de ce nouvel identifiant
setcookie('p3x_cook',mysql_insert_id(),(time()+3600));
}
elseif(!empty($banInfos['ban']))
die('Vous n\'avez plus l\'autorisation d\'accéder à ce site');
Mais bon la façon de procéder n'est pas bonne... quand à la note 4/10 je la trouve tout à fait adaptée... .. .
@ tchaOo°
31 mars 2007 à 15:11
Même si sur ton site il n'ya pas de forum, chatbox, livre d'or... en gros tout ce qui pourrait récupérer les infos d'un utilisateur par formulaire, bref même sans tout ca tu pourrais bannir.
En gros tout ce qu'on pourrait connaître sur l'utilisateur qui serait unique c'est l'adresse ip, tu as raison. Mais l'adresse ip peut changer régulièrement selon les fournisseurs (par exemple moi jai orange et ma connec bug tout le temps, donc mon ip change tout le temps). Ca veut dire que l'utilisateur aurait juste à attendre 1 journée par exemple (le temps de rafraichissement de la connec) pour que celui-ci soit débanni. Donc l'adresse ip n'est pas fiable. C'est pour ca que j'ai choisi le cookie qui banni l'utilisateur tant que celui-ci n'est pas supprimé (Et crois moi il n'y pas beaucoup d'utilisateur qui pense à les supprimer).
31 mars 2007 à 14:50
Pour celui qui changerait de mail, on pourrait tout de même combiner l'enregistrement avec une vérification rapide de l'IP via le cookie utilisé ici.
31 mars 2007 à 14:40
pensez de votre côté à mettre une note meilleure que 4 parce que ca vos plus que ca quand même ;)
31 mars 2007 à 14:28
p3x ==> c'est vrai qu'en y réfléchissant, c'est le meilleur moyen si l'utilisateur a une ip dynamique... mais bon suffit de nettoyer les cookies mais c'est vrai qu'on y pense pas quand on est banni...
passe quand meme la source en débutant et se sera bon...
aussi si y avait un script qui permettrait d'ajouter un ban se serai bien
31 mars 2007 à 14:25
31 mars 2007 à 14:21
ca fait plaisir à peine poster et déja plein de commentaire merci à vous.
sinon, je voulais vous dire que le cookie est le moyen le plus fiable pour bannir un utilisateur.
J'ai vraiment bien cherché mais je n'est rien trouvé de mieu.
Ensuite ce script est assez soft : il n'y a pas d'administration, et explique juste le fonctionnement de base.
Si je l'ai conçu comme ca c'est pour pouvoir facilité l'intégration de celui-ci à un forum, chat, livre d'or.... En effet, il suffit d'associer l'ID de p3x_cook à l'ID de la table d'un foum, chat, livre d'or etc... Comme ca lorsqu'un utilisateur sème la pagaille il est facilement identifié.
31 mars 2007 à 14:20
31 mars 2007 à 12:36
Pour les cookies, c'est vraiement trop simple à contourner.
31 mars 2007 à 11:09
31 mars 2007 à 11:08
31 mars 2007 à 11:08
31 mars 2007 à 11:07
31 mars 2007 à 10:37
p3x, personnellement, je pense qu'un bannissement par adresse e-mail est plus efficase, tu interdit dans une base de donnée certaine adresse e-mail et le tour est jouer.
Mais bon, je n'ai encore rien trouver pour bannir définitivement un utilisateur, je ne pense pas que ce soit possible.
Phenix
31 mars 2007 à 10:20
p3x ==> déjà je mettrais cette source en débutant, de plus, si ce script me bannis, j'ai juste a nettoyer mes cookies et je peux revenir... sert a rien quoi...
31 mars 2007 à 01:06