BANNIR UN UTILISATEUR PAR COOKIE

Commentaire de jdalton42 le 31/03/2007 10:20:42

ehectsamira ==> si quelqu'un fout le bordel sur le site (flood sur le livre d'or, forum, shootbox, commentaire, etc) tu peux l'empecher de venir sur le site.

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...

Commentaire de jdalton42 le 31/03/2007 11:07:21

Beh moi perso j'y penserai

Commentaire de jdalton42 le 31/03/2007 11:08:55

j'ai oublié de rajouter, moi j'ai plusieurs adresses email... je pourrais toujours m'inscire

Commentaire de rambc le 31/03/2007 12:36:13

Pour bannir un utilisateur définitivement, j'imagine qu'on doit d'abord le repérer "manuellement" ou suite à des remarques d'autres utilisateurs. Il suffit alors d'avoir un simple fichier sur son site avec la liste des personnes interdites et l'interdiction est alors définitive car elle est côté SERVEUR. Donc il me semble qu'un script qui gèrerait ce fichier interne serait plus efficace.

Pour les cookies, c'est vraiement trop simple à contourner.

Commentaire de p3x le 31/03/2007 14:21:20

Bonjout tout le monde,
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é.

Commentaire de jdalton42 le 31/03/2007 14:28:22

RAMBC ==> beh chez moi j'ai juste a débrancher mon modem environ 10 a 20 mins apres sa l'ip est changé...

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

Commentaire de rambc le 31/03/2007 14:50:58

Pour ma proposition, je ne pensais pas au repérage de l'utilisateur mal attentionné via son IP mais via ses "coordonnées" d'enregistrement (mail+login...).

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.

Commentaire de kankrelune le 31/03/2007 15:44:39

Ouais ouais ouais... je ne reviendrais pas sur le fait que cette technique n'est pas super fiable et qu'il n'y a de toute façon pas de moyen vraiment fiable... c'est pas super codé au niveau syntaxe et je trouve la façon de fonctionner mal pensée... l'utilisation d'un table sql est inutile... les infos qui y sont stockée sont inutiles... qui plus est je conseillerais l'utilisation des sessions un cookie de session passant plus inaperçu qu'un cookie de ban... .. .

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°

Commentaire de Rudy3212 le 31/03/2007 22:52:31

Script assez inutile, vaut mieux un bannissement par ip que par cookies.

Meme si par ip n'est pas fiable a 100% a cause des proxy, ip dinamique...

Commentaire de kankrelune le 01/04/2007 02:19:49

La méthode du cookie et la méthode de l'ip sont toutes les deux aussi contournable il n'y en a pas une mieux que l'autre... concernant la session elle se termine à la fermeture du navigateur... donc si l'on veut appliquer un ban plus long il faut effectivement passer par un cookie "normal" après tout dépend des besoins et du cadre d'utilisation du script... mais si vous regardez la source le temps d'expiration du cookie n'est pas spécidié dans le setcookie() dans ce cas le cookie expire à la fermeture du navigateur donc autant utiliser les session... sinon il faut faire... .. .


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°

Commentaire de kankrelune le 01/04/2007 12:44:04

Je n'ai jamais dis que la technique du cookie n'était pas bonne j'ai dis qu'elle n'est pas meilleur (ni pire) que celle de l'ip... .. .

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)

Commentaire de rambc le 01/04/2007 15:24:24

La base de données n'est pas indispensable si on part du principe que l'utilisateur ne pensera pas à effacer ces cookies, autrement dit si l'utilisateur ne connais rien aux cookies, et en particulier s'il ne sait pas où les trouver pour les modifier. Parceque dans ce cas, il suffit juste d'indiquer directement dans ton cookie que l'utilisateur n'est pas le bienvenu sur ton site. Cela me parait plus simple. Non ?

Commentaire de Rudy3212 le 01/04/2007 15:37:46

Il a raison la base de donnée n'est pas obligatoire, on peut s'en passer.

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.

Commentaire de p3x le 01/04/2007 16:02:05

Bon, je vais vous poser une question toute simple.

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é...

Commentaire de rambc le 01/04/2007 16:16:23

Le truc ne consiste pas à enregister la personne mais plus simplement à mettre dans le cookie une info disant qu'elle est bannie. Ensuite quand tu as un utilisateur qui se connecte, tu regardes si ton cookie "bloqueur" existe. En dautres terme, c'est l'absence du cookie qui permet d'entrer dans le site.

Commentaire de p3x le 01/04/2007 16:29:00

NEPHACID si t'as compris STP explique leur ='(

Commentaire de jdalton42 le 01/04/2007 16:36:57

je me trompe p3x ?

Commentaire de jdalton42 le 01/04/2007 16:40:08

lol ;) mais y a des gens qui ont moin de logique...

Commentaire de p3x le 01/04/2007 19:09:28

donc toi t'es hors sujet la du coup =p

Commentaire de kankrelune le 02/04/2007 01:20:07

NON... et arrête de me prendre pour un demeuré... je code depuis assez longtemps pour savoir de quoi je parle quand je dis quelque choses et je suis pas con au point de ne pas demander des explications lorsque je ne comprend pas... c'est toi (et jdalton42 par la même) qui n'a rien compris... .. !

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°  

Commentaire de FhX le 02/04/2007 18:49:36

Ce que veut dire Kankrelune, c'est dans le cas où ton visiteur n'accèpte pas les cookies !

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 :)

Commentaire de p3x le 02/04/2007 21:44:53

bah tu insultes tous le monde et les admins CS te banniront, rien de plus simple !

Commentaire de FhX le 02/04/2007 22:36:13

Oui regarde, Bidou il sert qu'à ca !

Commentaire de p3x le 03/04/2007 19:02:59

c le seul truc abusé kan meme kan on y pense dans php. Ne pas pouvoir connaître l'utilisateur avec une clef unique.
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 !

Commentaire de kankrelune le 04/04/2007 02:13:18

Voila pour le coté technique... quand au coté éthique cela voudrait dire que les internautes seraient traçable... et personnellement je ne suis pas pour... mais ça c'est un long débat où chacun a son avis... .. .

@ tchaOo°

Commentaire de FhX le 04/04/2007 18:41:05

"Donc jamais C ne verra l'adresse MAC de A et vice-versa."
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 :)

Commentaire de jean84 le 08/04/2007 01:10:11

La gestion des cookies est contre indiquee dans les applications lie a la securite (de pres comme de loin). Ce type de protection (peut on appeler sa comme sa ?) ne doit jamais etre appliquer cote client mais cote serveur, les addons permettant de modifier ses cookies sont nombreux sur le net (rien que pour firefox, y a Anec Cookie Editor qui fonctionne a merveille et perso, je regarde souvent du cote de mes cookies voir ce qui se passe, juste par curiosite). Et pour finir sur firefox, le mien est configure pour tout efface de maniere silencieuse a chaque fois que je le ferme...
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)

@++

Commentaire de levraipestouille le 02/04/2008 13:20:23

Slt :)
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.