| 1 StreM, le 14 sep 2005 à 15:29:22Je pense que ca dépend quel sécurité tu veux. Je m'explique :
Tu dois savoir qu'un cookie est stocké sur le poste client sous forme de fichier texte, sans aucun cryptage. Donc sur des systèmes basiques comme windows 98 ou même XP avec un formatage en FAT32 (pas de droits d'accès sur les répertoires), n'importe qui peut y avoir accès. Et si tu regardes le contenu du cookie, oui, c'est tout marqué en clair !
Et typiquement, c'est ULTRA SIMPLE de changer la valeur de ta variable "admin?" de non à oui !
Donc penche toi vers du cryptage/dévryptage (donc pas de MD5 !), en effet !
A moins que quelqu'un d'autre ait une solution...
http://www.securiteinfo.com/conseils/cookies.shtml
Moins le blanc est intelligent, plus le noir lui parait bête | 2 Erdnax, le 14 sep 2005 à 15:37:05Je pensais bien que tu interviendrais ;)
En fait, j'ai décidié entre temps de laisser tomber le statut par cookies, une petite requête mysql et hop, plus sûr, et peut-être un poil plus lent, mais c'est pas un gros site.
Sinon, maintenant j'ai un autre problème, j'ai regardé un peu comment étaient fait les cookies de ccm, et j'ai vu que ce n'est pas l'identifiant qui est inséré (lui aussi trop facile à modifier...), mais l'id de session. Alors je suppose qu'il y a une table temporaire ou sont stockés tous les id des sessions en cours sur ccm, et qu'à chaque fois un script va vérifier si la session à bien été enregistrée ?
Est-ce que quelqu'un pourrait m'en dire un peu plus sur le fonctionnement des sessions sous ccm ?
J'ai lu ça :
http://www.commentcamarche.net/php/phpcookie.php3
et deux ou trois autres articles de ccm et d'ailleurs, mais rien ne vaut une "vraie" explication du fonctionnement. Alors si quelqu'un y arrive, ou si quelqu'un à une idée ;) Merci
Grève de signure... | 3 StreM, le 14 sep 2005 à 15:45:39Héhééé... je pensais bien que tu pensais que j'interviendrais ;))
Sinon, pour les sessions de CCM, je pense savoir comment elles fonctionnent, car j'ai déja intervenu sur une application qui utilisait ce système, et il est vrai que ca peut servir à pleins de choses :
En fait, tu crées toi-même ton identifiant de session (un md5(rand()) et hop !), que tu stockes ET dans ta table SESSIONS ET dans ton cookie. Ainsi, tu retrouves les données dans la base de données. Problème : n'importe qui peut prendre le cookie d'un autre, et qui sait ce que ca peut donner ? A moins que tu fasses un test sur l'IP du client, mais même, point de vue de la sécurité, c'est pas génial...
Enfin de toutes facons, pour une sécurité optimum, tu ne peux que demander un identif et un mdp a chaque fois. C'est pour ca que je te demandais comment, dans quelle mesure tu comptais mettre en place ta sécu ?
Moins le blanc est intelligent, plus le noir lui parait bête | 6 Erdnax, le 14 sep 2005 à 16:09:07P.S. je t'aiderai bien sur ton javascript, mais bof, j'm'y connais moi que toi. Sympa ton truc, même si c'est pas encore 100% au point, ça promet ;)
Grève de signure... | 7 StreM, le 14 sep 2005 à 16:17:57Merci !
J'ai le meme pour rogner les photos, et un autre pour les faire rotationner, négatif, etc... Bref, un photoshop online !
Mais j'aimerais bien que ca tourne pas que sous IE...
Merci quand meme !
Moins le blanc est intelligent, plus le noir lui parait bête |
|
|
| 4 Erdnax, le 14 sep 2005 à 15:52:38Donc en fait, le plus simple, c'est de démarrer une session si le mot de passe et le compte d'utilisateurs sont juste, toutes les infos sont retirées à partir de la base de données (statut, droits, etc), sont stockés dans la session, et à chaque fois que le visiteur quitte le site, il doit se reconnecter.
Ca, je peux le faire, il n'y a pas de problème (c'est déjà plus ou moins en place en fait), mais j'aimerais bien pouvoir faire en sorte que le visiteur reste connecté même lorsqu'il quitte le site, durant une certaine période (en l'occurence 12h).
Donc mon problème est la sécurité avec les cookies, je ne vois pas trop comment faire en sorte que le visiteur ne puisse pas se faire voler sa session (ou même la traffiquer en fait).
Grève de signure... | 5 StreM, le 14 sep 2005 à 16:08:14Pour moi, tu devrais faire le systeme de session par BDD (tu generes toi meme l'id de session) et stocker cet id dans un cookie. Par ce système, l'utilisateur n'a AUCUN moyen de modifier son statut, puisqu'il est en BDD, pas dans le cookie. Après, il faut compter sur la sécurité du compte windows de l'utilisateur (les comptes linux n'ont pas de problemes de sécurité ;) ).
Et tu mets une date d'expiration POUR ton cookie (pas dedans ! Quand tu le crées !), et DANS ta BDD (pour ne pas que l'utilisateur puisse le modifier, et que tu puisses faire un test pour vérifier que ca ne fait pas encore 12h qu'il s'est déloggué)
Après, je te laisse réflechir pour l'utilisation optimale : n'oublie pas de mettre a jour la date de derniere connexion (dans la BDD, ca va de soi) de l'utilisateur dans chaque page.
Ca va aller ? :-P
Moins le blanc est intelligent, plus le noir lui parait bête |
| 8 Erdnax, le 14 sep 2005 à 16:32:23Bon, en gros (je récapitule, parce que je suis pas sûr d'avoir tout compris.)
1. Je génère un id de session (md5(rand())) que je place dans un cookie et ma base de donnée. Ce cookie est programmé pour vivre 12h00, et son heure d'échéance est aussi indiquée dans la base de donnée.
2. Dans chaque page, on récupère le cookie, on regarde si les deux numéros de sessions jouent (bdd et cookie), et si la date d'expiration du cookie ne dépasse pas celle de la bdd.
3. A l'heure d'expiration, le cookie s'autodétruit de lui-même, et euh, dans la bdd lol ? C'est de ça que tu parles quand tu dis :
n'oublie pas de mettre a jour la date de derniere connexion (dans la BDD, ca va de soi) de l'utilisateur dans chaque page ?
Grève de signure... | 9 StreM, le 14 sep 2005 à 16:41:22NON :-P
En fait, moi j'avais vu ce systeme, et l'id que tu créeais etais passé en paramètre a chaque page. Je ne sais pas si c'est la meilleure solution...
Enfin pour utiliser ce syteme :
- index.php : tu crees l'identif de session, tu stockes dans ta BDD : l'identif de session, la date de connexion et le reste. Tu crées le cookie (a la creation, tu donnes une date d'expiration, c'est le principe du cookie),et tu mets l'identif de session dedans.
- dans les autres pages : tu actualises la date de derniere connexion dans la BDD si now() est inferieur a la date de derniere connexion + 12H sinon tu renvoie sur index.php
- index.php : tu récupères l'identif de session de ton cookie, et tu fais le test des 12H sur la date de derniere connexion. Si c'est ok, tu actualises, sinon, tu redemandes les identifiants de ton utilisateur.
Capito ? ;))
Hesite pas a me dire ce qui n'est pas clair.
Moins le blanc est intelligent, plus le noir lui parait bête |
| Alors j'ai compris le principe, au détail près (et c'est pas le plus petit lol) du test des 12h, ce qui est souligné. Le now() est la date et l'heure de maintenant, on est d'accord ?
Je comprends pas pourquoi si l'heure actuelle est plus petite que la date de dernière connexion, alors que cette dernière est actualisée juste avant...
Et bon, si t'as du code php pour expliquer, on parlera plus le même langage lol. (Mais tu t'en doute, écris le pas s'il est pas déjà existant.)
Sinon, ce que j'ai écrit plus haut pourrait fonctionner ? Parce que ça, j'ai compris :P
Grève de signure... |
| 11 StreM, le 14 sep 2005 à 17:06:20Désolé, j'ai vu passer ca, mais j'en ai plus, de code...
Pour le inférieur, faut mettre des parenthèses :si now() est inferieur a (la date de derniere connexion + 12H)
Et oui, now() est le timestamp de ... maintenant ;)
Sinon, pour ton idée, oui ca peut tout à fait marcher, mais il y a 2 inconvénients majeurs : récupérer le cookie à chaque page, c'est lourd ! Tu n'as besoin de le récupérer qu'une seule fois si tu passes ton id de session en paramètre, ou si tu l'inscris dans une session PHP(t'emmele pas les pinceaux!). Enfin, dans ton cas, la cookie n'est pas bien gros, mais bon, pense a la bande passante, ca fait discuter 2 machines. Alors qu'un parametre en GET, non. Bref, ca peut marcher.
L'autre inconvénient, c'est que tu prends la date de connexion au tout début. Donc si ton utilisateur reste sur ton site 2H, il n'aura pas 12H de sursis, mais 10H.
M'enfin, je dis MAJEURS, mais tout est relatif !
Moins le blanc est intelligent, plus le noir lui parait bête |
| AAAAAAAAAHHHHHHHHHH
Ben avec les paranthèse, ça va bien mieux lol !
Sinon, tu t'embrouilles sur l'explication de la lourdeur si je récupère le cookie sur chaque page, mais j'ai tout compris, sisi !
Et sinon, pour les 10 ou 12 heures, bof, ça m'est égal, c'est totalement aléatoire, c'est juste histoire que le cookie ne reste pas trop longtemps, mais le temps exact n'est pas très important, donc ce n'est pas un inconvénient.
Donc je crois que je vais prendre "ma" méthode, avec une seule récupération du cookie.
Le seul truc, c'est pour enlever les id de sessions terminées dans la base de donnée. Si t'as une dernière idée pour ça ;)
Grève de signure... |
| 13 StreM, le 14 sep 2005 à 17:27:25Pardon, il est le soir, j'ai travaillé toute la journée, je commence a fatiguer, j'arrive plus a m'expliquer... :-P
Pour nettoyer un peu la BDD des sessions je pense que je ferais une fonction qui parcourt la base a la recherche des "last_time_connect" qui datent de plus de 12H.
Je déduis de ton post que tu utiliseras bien des tables liées ?
genre une table qui ne contient QUE l'id de session et l'id du user, et une autre table qui contient les users ?
Si c'est ca, c'est bien, j'avais oublié de le préciser. Tu verras que ca peut être drôlement utile !
Bon courage en tout cas ! Je te laisserais te dépatouiller, tu apprendras beaucoup avec un script comme ca ! Mais réflechis bien à tout, c'est pas évident de se lancer la dedans, mine de rien !
Moins le blanc est intelligent, plus le noir lui parait bête |
| Je sais, merci pour tout, mais je n'ai averti personne de ce projet. (Bien que les visiteurs ne soient pas encore foule). J'ai donc tout le temps qu'il me faut pour développer, tester, etc.
Donc encore merci, et bonne soirée, repose toi bien ;)
:P@+
Grève de signure... |
|
|
|
|
Adresse ip php
