Page 1 sur 2
tps de vie limite d'une connexion
Posté : 16 juin 2008, 15:05
par bruno.rotrou
salut
je suis confronté pour la première fois à un site qui a besoin d'un niveau de sécurité non négligeable.
j'ai lu beaucoup de post intéressants sur ce sujet avec la protection contre les injections sql ect ....
mais j'aimerais savoir comment je peux donner un tps limite de connexion a un client qui reste sans activité.
j'ai lu qu'on pouvait utiliser les session et les cookies mais je ne vois pas comment.
meme si je n'ignore pas qu'un cookie a une duree de vie, par contre les session je sais pas.
alors voila si qq1 pouvais me conseiller ou me diriger vers un tut , un post ect ...
merci d'avance et bonne journée
A+
Posté : 16 juin 2008, 15:38
par mcorgnet
Les sessions ont une durée de vie de 30mn a la base, il me semble. un truc genre max_session_lifetime pour le changer.
EDIT
Non en fait, ça se change dans le php.ini
et sûrement dans le htaccess
session.gc_maxlifetime
session
Posté : 16 juin 2008, 16:50
par bruno.rotrou
merci
ce qui veut dire que mes var _session ne seront plus valable au bout de 30mn
je vois pas comment utiliser ca pour savoir que mon client est inactif depuis 30mn
je continus a chercher
A+
Posté : 16 juin 2008, 17:17
par katagoto
A chaque actualisation tu UPDATE une table avec l'id du client et le timestamp, comme ça tu saura depuis combient de temps il est inactif...
Posté : 16 juin 2008, 17:34
par zeus
Je te conseille la solution du cookie auquel tu fixes une durée de vie de 30mn.
A chaque fois que tu affiches une page, si le cookie est présent, c'est que la durée depuis sa dernière visite est inférieure à 30mn.
Sinon, c'est qu'il s'est passé plus de 30mn, donc, une nouvelle visite.
Il te suffit juste de penser à redemander la création du cookie à chaque visite pour que le compteur reparte à 30mn à chaque visite.
Pour la solution en base de données, c'est un catastrophe pour les performance d'un site. Ca ne se verra pas au début, mais dès que la charge commencera à monter, tu affaiblis ton site.
Dire que c'est impossible, c'est reconnaitre sa faiblesse et perdre du temps que nous aurions pût investir dans sa réalisation...
Bonjour, je voudrais un ordinateur de moins de 500€ qui sais me prédire l'avenir ... ah merde, je suis faible
Posté : 16 juin 2008, 18:17
par katagoto
Dire que c'est impossible, c'est reconnaitre sa faiblesse et perdre du temps que nous aurions pût investir dans sa réalisation...
Bonjour, je voudrais un ordinateur de moins de 500€ qui sais me prédire l'avenir ... ah merde, je suis faible
Tiens un modo qui part en HS
L'inconvéniant c'est que si le client refuse les cookies le système s'éffondre...
Posté : 16 juin 2008, 18:52
par zeus
Et avec le système de base de données, comment est-ce que tu sais qu'un client reviens ?
Et oui, l'avantage d'être un dictateur, c'est qu'on dictate

Posté : 16 juin 2008, 18:58
par katagoto
Très simple, si sa dernière actualisation date de plus de 30 minutes, c'est qu'il revient
Les cookies c'est encore moin sûr puisque c'est modifiable...
L'avantage d'être un modérateur c'est de pouvoir modérer les autres, mais pour bien les modérer il faut commencer par soit même

Posté : 16 juin 2008, 23:40
par zeus
Très simple, si sa dernière actualisation date de plus de 30 minutes, c'est qu'il revient
Justement, comment fait tu pour savoir que le visiteur X est passé sur le site ? en déposant une trace sur son PC ... donc un cookie
L'avantage d'être un modérateur c'est de pouvoir modérer les autres, mais pour bien les modérer il faut commencer par soit même

Il me semble que tu es bien loin de pouvoir donner ce genre de conseils ...
[HS terminé]
merci
Posté : 17 juin 2008, 08:10
par bruno.rotrou
salut et un gd merci a vous deux pour vos reponses
j'essais de mettre ca en oeuvre avec les cookies
bonne journée
Posté : 17 juin 2008, 10:56
par Hywan
Hey

,
Si tu veux bien utiliser les sessions, je te conseille
un petit tour dans le manuel. Tu y trouveras toutes les informations nécessaires.
Attention à ne pas confondre session et cookie. Les sessions sont stockées dans des fichiers (par défaut) côté serveur. Les cookies sont des fichiers côté client qui contiennent l'identifiant de session. Cet identifiant a deux façons d'être stocker : soit en variable URL (impossible à sécuriser et URL dégueulasse), soit dans des cookies (plus sécurisable et invisible pour l'utilisateur).
On peut se passer de Javascript, mais on ne peut pas se passer des cookies. Tous les navigateurs — même les plus rudimentaires — acceptent les cookies. C'est la façon la plus sûr et la plus propre de travailler avec les sessions.
Et quand
Zeus dit que les bases de données plombent les performances d'énorme site (surtout pour une action aussi triviale), je pense qu'il sait de quoi il parle. Tu devrais plutôt profiter de son expérience …
Posté : 17 juin 2008, 11:39
par zeus
Effectivement, un de mes projets est un système de tracking de visite (un google adsense like), et aujourd'hui, plus de 96% des navigateurs acceptent les cookie.
Pour les autres, il n'y a pas de solution simple

Posté : 17 juin 2008, 12:28
par katagoto
Première requête : je regarde si il est dans la table, seconde requête j'update s'il y ait ou je l'insert s'il y ait pas, pour pas faire la première requête à chaque fois tu utilise les sessions...
@zeus en effet, mais je ne suis pas modérateur

Posté : 17 juin 2008, 12:38
par Hywan
Et à ça tu ajoutes les connexions persistances et tout le toutime. Notre ami est débutant s'il te plaît. On va au plus simple et au plus efficace : les sessions.
Fin du débat.
Posté : 17 juin 2008, 14:43
par zeus
Non, mais sans parler de débat ...
katagoto, comment est-ce que tu sais que tel PC est déjà passé sur un site juste avec ta base de données ?
Quand j'arrive sur ton PC, qu'est ce qui te permet de savoir s'il faut faire un insert ou un update ?
[EDIT] du moins, quel serait l'id, la trace que tu mettrais dans le WHERE pour identifier un visiteur. Et surtout, d'où sortirait cette trace ?
Si tu me réponds l'IP, j'arrête tout ici et je souhaite bon courage à bruno.rotrou