tps de vie limite d'une connexion

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : tps de vie limite d'une connexion

par zeus » 17 juin 2008, 17:26

Je ne te rejoins pas là dessus : le mec qui veut changer son numéro de session, faut qu'il trouve un numéro correspondant sur le serveur, ce qui est plus compliqué que d'incrémenter un cookie dans lequel on a placé un id d'utilisateur ...
Dans ma solution, le cookie ne contient rien.
Le fait qu'un visiteur contienne le cookie suffit pour savoir qu'il est déjà passé il y a moins de x minutes (durée de vie du cookie)

Je reconnais que je me suis totalement planté dans cette phrase là :?
Donc, ma solution consistant à stocker l'id du membre ...
Je travaillais sur un système où je doit stocker l'id dans le cookie (pas en clair, je vous rassure) et j'ai fait un gros amalgame. Au temps pour moi :oops:

par mcorgnet » 17 juin 2008, 16:48

Et les sessions ... c'est un cookie sur le client avec un id de session ...

Et il faut savoir que sessid en url est perdu au changement de site.

Donc, ma solution consistant à stocker l'id du membre dans un cookie est aussi sécurisé que la session, puisque le client peut altérer ou supprimer un cookie de session ou un cookie tout court de la même manière.
Mais ma solution est beaucoup plus optimisée puisqu'elle permet d'alléger la base de données et de réduire énormément le nombre de requêtes.
Je ne te rejoins pas là dessus : le mec qui veut changer son numéro de session, faut qu'il trouve un numéro correspondant sur le serveur, ce qui est plus compliqué que d'incrémenter un cookie dans lequel on a placé un id d'utilisateur ...

Mais je ne suis pas non plus pour l'utilisation de la base de données.

Cookie de session, donc, qui ne contient qu'un ID de session généré aléatoirement, hashé en SHA-1, ça me paraît optimisé en matière de sécurité.

par zeus » 17 juin 2008, 16:35

Et les sessions ... c'est un cookie sur le client avec un id de session ...

Et il faut savoir que sessid en url est perdu au changement de site.

Donc, ma solution consistant à stocker l'id du membre dans un cookie est aussi sécurisé que la session, puisque le client peut altérer ou supprimer un cookie de session ou un cookie tout court de la même manière.
Mais ma solution est beaucoup plus optimisée puisqu'elle permet d'alléger la base de données et de réduire énormément le nombre de requêtes.

par mcorgnet » 17 juin 2008, 16:32

Moi ye souis pour les sessions, depuis que ye tenté de faire la gestion d'un panier avec les cookies.

Moins je vois de cookies, mieux je me porte. Ils me servent juste à identifier quelqu'un pour mes login.

par katagoto » 17 juin 2008, 16:25

Il dit que c'est sécurisé, donc il y a un espace membre avec l'id stocké dans les sessions...
<?php
session_start();
$connexion=new PDO(/* ... */);
// Si l'utilisateur n'était pas dans la BDD
if(!$_SESSION['test_user']){
    $connexion->exec("INSERT INTO connectes VALUES('".$_SESSION['id_user']."', '".time()."')");
    $_SESSION['test_user']=1;
}

$requete=$connexion->query("SELECT * FROM connectes"); 
$requete->fetch(PDO::FETCH_OBJ);
if($requete->temps<900) $connexion->exec("UPDATE FROM connectes SET temps='".time()."' WHERE id='".$_SESSION['id_user']."'");
else die('vous avez actualiser votre page il y a plus de 30m, veuillez vous relogguer');
?>
Voilà le travail, en gros, mais les sessions me paraissent plus simple...

par zeus » 17 juin 2008, 14:43

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

par Hywan » 17 juin 2008, 12:38

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.

par katagoto » 17 juin 2008, 12:28

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

par zeus » 17 juin 2008, 11:39

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

par Hywan » 17 juin 2008, 10:56

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 …

merci

par bruno.rotrou » 17 juin 2008, 08:10

salut et un gd merci a vous deux pour vos reponses

j'essais de mettre ca en oeuvre avec les cookies

bonne journée

par zeus » 16 juin 2008, 23:40

Très simple, si sa dernière actualisation date de plus de 30 minutes, c'est qu'il revient :P
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 :wink:
Il me semble que tu es bien loin de pouvoir donner ce genre de conseils ...
[HS terminé]

par katagoto » 16 juin 2008, 18:58

Très simple, si sa dernière actualisation date de plus de 30 minutes, c'est qu'il revient :P
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 :wink:

par zeus » 16 juin 2008, 18:52

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

par katagoto » 16 juin 2008, 18:17

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

L'inconvéniant c'est que si le client refuse les cookies le système s'éffondre...