probleme de session et captcha

[Jeckel]

Je ne vois pas en quoi le fait de passer les sessions en BDD aurait pu régler ton pbm de sessions qui sautent, à moins que ton hébergeur soit très mal configuré...

La gestion des sessions (PHP) en base de données n'ont, à mon goût que deux intérêts :
- pouvoir faire des requêtes et des jointures dessus (mais c'est dangereux)
- pouvoir gérer du load-balancing (c'est à dire plusieurs serveurs qui se partage la charge et qui doivent donc gérer les sessions de manière commune sur un système central)

Gérer sur fichier dans un cas / sur base de données dans d'autre ça me semble tordu, lourd et assez risqué, il vaut mieux rester sur un système et le garder.

La session sur fichier fonctionne normalement très bien, moi je reste là dessus, il faut juste faire toujours attention de ne pas stocké trop de choses dedans car étant un fichier il peut devenir lourd à ouvrir...

Ensuite, une fois l'utilisateur connecté ou déconnecté (dans le sens login valide) je flag l'utilisateur dans la table, ça me permet de compter le nombre d'utilisateur connecté, et UNIQUEMENT mes utilisateurs, qui sont déjà identifié. (reste juste à rajouter un champs date de dernière activité pour être sur)

[php_addict]

Je ne vois pas en quoi le fait de passer les sessions en BDD aurait pu régler ton pbm de sessions qui sautent, à moins que ton hébergeur soit très mal configuré...

et pourtant...c'était un 90 plan de ovh

Merci pour toutes vos réponses et je vais suivre vos conseils

bonne journée à tous

[Viciousity]

Un petit code a l'arrache pour illustrer mes propos (fait rapidement )

# En imaginant une base de donnée avec :

  String   visitor_ip

  Integer  try_count

  DateTime last_try_at







# Pour vérifier le captcha.

# =========================



# On récupère le visiteur si il existe.

visitor = TableIp.find_by_visitor_ip(request.remote_ip)



# Si il est en base de donnée

if visitor

  # Si jamais il a tenté entre 10 et 20 essais.

  show_captcha if (10..20).include?(visitor.try_count)

  # Si jamais plus de 20 essais.

  refuse_user  if visitor.try_count > 20

end







# Quand on poste le formulaire :

# ==============================



# On récupère le visiteur si il existe.

visitor = TableIp.find_by_visitor_ip(request.remote_ip)



# Si il est déja en base de donnée

if visitor

  # Si jamais son dernier essai date de - de 30 minutes(1800 secondes)

  if visitor.last_try_at < Time.now - 1800 ? visitor.try_count=0 : visitor.try_count +=1

  # On update avec le moment présent.

  visitor.last_try_at = Time.now

  visitor.save

else

  TableIp.create(:visitor_ip=>request.remote_ip, :try_count=>1, :last_try_at=>Time.now)

end

[Sephi-Chan]

Pardon de poser cette question, mais elle me semble fondamentale : pourquoi fais-tu tout ça ?


@ Viciousity

Time.now - 1800  # C'est bien.

30.minutes.ago   # C'est plus sexy et lisible !

[Viciousity]

Heu pour l'aider si c'est a moi que tu t'adresses
Sinon j'en vois pas vraiment l'utilité pour un jeu mais bon ...

Ps: je code sous Sinatra, 30.minutes.ago sa n'existe pas la

[Sephi-Chan]

Non, je demande ça à PHP Addict ! :p
Et go ActiveSupport !

[Viciousity]

Haha en fait j'en ai pas l'utilité actuellement dans mes projets sous Sinatra qui sont souvent de toute petite envergure ;P
Sinon j'avoue que sous Rails j'ai tendance a en abuser un peu

Puis pense un peu à tous les gens qui font du php sur le forum, c'est déja galère pour eux de devoir comprendre notre code alors si jamais on se met a compliquer encore tout sa ...

[php_addict]

Pardon de poser cette question, mais elle me semble fondamentale : pourquoi fais-tu tout ça ?

Il est quand même important de protéger un minimum l'accès aux comptes des joueurs, non? Que votre jeu ai 100 ou 100.000 joueurs ca reste important...

pour remarque j'avais repris le compte d'un joueur sur un mmorpg très célèbre et son mot de passe était '123456' et je n'oses imaginer le nombre d'internautes utilisant des mots de passe aussi peu sécurisés

tu ne sécurises pas un minimum le compte de tes joueurs ?

[Viciousity]

Ben si mais avec un système de log ip légèrement plus optimisé que celui-ci
Mais qui s'inscrit dans la meme logique

Il n'y a pas de solution miracle, si quelqu'un veux hacker ton jeu, il réussira si il en a les connaissances et le temps
Mais je peux t'assurer que pour le moment la solution que je te propose reste robuste et fiable pour les 3/4 des attaques

[Sephi-Chan]

Honnêtement, je ne pense pas qu'il soit utile de mettre en place ce genre de protection, et encore moins au niveau du client.

Je trouve qu'un simple compteur de connexions échouées au niveau du compte est plus simple et utile. Tu alertes le propriétaire du compte après quelques échecs et libre à lui de décider de ce qu'il fera. Tu peux lui proposer de changer de mot de passe (avec pourquoi pas un outil pour évaluer la force de son mot de passe ?).

Pour la partie IP, tu peux simplement utiliser Fail2Ban, tu le fais bannir les gens qui rencontrent un peu trop d'erreurs 401/403 et voilà (bien sûr, ton application doit servir ces code erreurs en cas d'échec).