probleme de session et captcha

[php_addict]

bonjour

je me vois confronter à un petit probleme de session

sur ma page de login je démarre un session_start car au bout de 3 tentatives échouées de login je déclenche une variable $_SESSION['captcha'] qui quand est détectée propose le formulaire de login avec l'image du captcha...bref un classique du genre

le problème etant qu'a chaque fois qu'un visiteur passe par la page login cela ouvre un session et donc un fichier temporaire de session (ou dans mon cas une entre dans la base de donnée car mes sessions sont gérée en base de donnée)

le problème étant surtout les robots d'indexation qui a chaque fois passent par là me créés une session

il y a possibilité de détecter les robots mais c'est pas très clean, voyez vous un autre moyen de ne pas créer autant de sessions à chaque fois qu'un visiteur passe par ma page login ?

bonne fin de journée

[Kassak]

Logiquement, tant que l'utilisateur ne s'est pas logué, tu ne devrais pas créer de session non ?

Proposition alternative, au bout de 3 tentatives ratées, tu bloques le comptes dans la bdd, et si le compte est bloqué, le seul moyen de le débloquer c'est avec un captcha... Pas besoin de 40 000 sessions.

[djidi]

Tu peux créer une table pour les tentatives de connexion en utilisant par exemple l'IP et le nombre de tentatives.
Dans la page du formulaire tu fais ensuite la vérification.

[niahoo]

tu peux passer par un cookie classique à la place.. mais c'est plus facilement contournable donc je ne vois pas non.

[Viciousity]

Les deux solutions sont un peu bidon ...
Dans le premier cas, suffit de lancer le nettoyeur de cache et paf on peut a nouveau tenter sans captcha.
Dans le deuxieme cas tu bloques un compte "innocent". Du coup si tu veux faire chier un gars, tu lui tapes 3 erreurs de login et lui doit se taper le captcha.

Une des meilleurs façon de gérer sa est de logguer les ip dans une table qui contient trois champs (Ip, count, last_try) en faisant un truc du genre :
- Si l'ip n'existe dans la table => je l'inscrit et j'incremente le count de 1, je met a jour last_try avec le timestamp
- Si l'ip existe dans la table => j'incrémente de 1 la valeur de count, je met a jour last_try
- Si l'ip existe et que count >= 3 => J'affiche le captcha, j'incrémente de 1 count et je met ajour last_try
- Si l'ip existe et que count >= 20 => Je bloque l'ip.

A chaque essai on vérifie si last_try est par exemple inférieur a 30 minutes, si oui, alors je remet a 0 count.

[php_addict]

merci pour vos avis

Logiquement, tant que l'utilisateur ne s'est pas logué, tu ne devrais pas créer de session non ?

les sessions ne servent pas uniquement à identifier lors du login mais ca peut prêter à confusion et c'est peut être stupide mais après être logué je fais un $_SESSION['connecté'] que je vérifie à chaque page privée

bloquer le compte d'un joueur est une très mauvaise idée...
le cookie non plus
d'ailleurs le système de session pour les captcha non plus vu qu'il utilise les cookies ou siid dans l'url

faire une blacklist d'ip me parait interessant mais ca n'empechera pas l'ip spoofing même si c'est dejà une technique avancé de hacking

donc le top pour bloquer les robots au login c'est l'ip meme si on peut la spoofer ????

[Jeckel]

le problème étant surtout les robots d'indexation qui a chaque fois passent par là me créés une session

il y a possibilité de détecter les robots mais c'est pas très clean, voyez vous un autre moyen de ne pas créer autant de sessions à chaque fois qu'un visiteur passe par ma page login ?

Quel est le problème d'avoir beaucoup d'entrées dans ta base de données ?

Le système de session, c'est une connexion d'un client (navigateur ou bot) = une session, que l'utilisateur soit connecté ou non. c'est le principe d'une session (d'un point de vue technique, mais si fonctionnellement, par abus de langage on considère souvent une session comme étant un utilisateur identifié).

Si le problème c'est uniquement les moteurs d'indexation alors laisse faire... surtout en base de données, une base mysql se comportera très bien avec 100 000 lignes dans ta table, t'inquiète pas.

Si par contre, c'est pour "bloquer" les robots qui tentent des connexions en force, c'est différent, et le problème n'a pas grand chose à voir avec les sessions.

Pour info, se baser sur l'IP c'est risquer, d'une part ça peut se pooffer, c'est vrai, mais surtout qu'une IP peut être commune à de nombreux utilisateurs (utilisation d'un proxy ou d'un firewall ==> cas des entreprises, bibliothèques et divers lieux publiques, et aussi des cités universitaires)

[php_addict]

Merci Jeckel et je me permet une dernière question:

mon système de gestion pour les joueurs connectés se géré en base de donnée (session_set_save_handler) mais je peut très bien faire en sorte que la session pour le captcha soit faite de facon traditionelle (fichier dans repertoire tmp du serveur)

cela a t il un interet?

[niahoo]

c'est à toi de fournir la réponse. pourquoi as tu choisi de stocker les sessions en db ? pourquoi revenir à un fichier. un double système ne me paraît pas évolutif

[php_addict]

pourquoi as tu choisi de stocker les sessions en db ? pourquoi revenir à un fichier

A l'epoque où je testais mon site sur un mutu les sessions sautaient sans cesse sur les navigateur mobiles, j'ai donc passé ca en base de donnée. L'autre avantage est de pouvoir savoir combien de sessions encore actives sont en cours. Il y a certainement d'autres avantages que j'ignores