begin process at 2012 05 27 18:30:10
  Trouver un code source :
 
dans
 
[ Dernières recherches ]
Accueil > 

Code

 > 

Sécurité & Cryptage

 > SERSESSIONS > CLASS PHP5 POUR GERER LES SESSIONS SIMPLEMENT (PROTECTION XSS)

SERSESSIONS > CLASS PHP5 POUR GERER LES SESSIONS SIMPLEMENT (PROTECTION XSS)


 Information sur la source

Note :
6,5 / 10 - par 2 personnes
6,50 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Sécurité & Cryptage Classé sous :SER, simple, sessions, arrayaccess, XSS Niveau :Débutant Date de création :26/02/2009 Date de mise à jour :02/04/2010 17:20:08 Vu / téléchargé :5 966 / 479
Auteur : Astalavista

Ecrire un message privé
Ce membre participe au partage de revenus publicitaires
Commentaire sur cette source (24)
Ajouter un commentaire et/ou une note

 Description

Class en PHP5 qui permet de sécuriser les sessions automatiquement.

Vérifie :
- l'IP
- le nom du navigateur
- le temps de la sessions
- le referer

Un élément pour les paranoïaques permet de régénérer un ID de session a chaque récupération de la session en cours

Source

  • <?php
  • require "session.class.php";
  • // $Session = new session($sessionName, $timeOut, $timeCookie, $cacheLimit, $idReg, $csrfFix)
  • // str $sessionName : Nom du cookie de la session
  • // int $timeOut : Timeout de la session
  • // int $timeCookie : Temps du cookie (0 pour session)
  • // int $cacheLimit : Cache de la session
  • // 0 => 'public', 1 => 'private', 2 => 'nocache'
  • // bool $idReg : Regénère un id de session à chaques appels
  • // bool $csrFix : Sécurité pour le Cross Site Request Forgeries
  • $Session = new session();
  • //écriture dans la session :
  • $_SESSION['offset'] = "valeur";
  • // Ou
  • $Session['offset'] = "valeur";
  • // Ou
  • $Session -> offset = "valeur";
  • //lecture dans la session
  • echo $_SESSION['offset'];
  • // Ou
  • echo $Session['offset'];
  • // Ou
  • echo $Session -> offset;
  • //suppression dans la session
  • unset($_SESSION['offset']);
  • // Ou
  • unset($Session['offset']);
  • // Ou
  • unset($Session -> offset);
  • //vérification avec isset
  • isset($_SESSION['offset']);
  • // Ou
  • isset($Session['offset']);
  • // Ou
  • isset($Session -> offset);
  • ?> 
<?php
require "session.class.php";
// $Session = new session($sessionName, $timeOut, $timeCookie, $cacheLimit,  $idReg, $csrfFix) 
// str $sessionName : Nom du cookie de la session
// int $timeOut : Timeout de la session
// int $timeCookie : Temps du cookie (0 pour session)
// int $cacheLimit : Cache de la session
//				 0 => 'public', 1 => 'private', 2 => 'nocache'
// bool $idReg : Regénère un id de session à chaques appels
// bool $csrFix : Sécurité pour le Cross Site Request Forgeries
$Session = new session();

//écriture dans la session :
$_SESSION['offset'] = "valeur";
// Ou
$Session['offset'] = "valeur";
// Ou
$Session -> offset = "valeur";

//lecture dans la session
echo $_SESSION['offset'];
// Ou
echo $Session['offset'];
// Ou
echo $Session -> offset;

//suppression dans la session
unset($_SESSION['offset']);
// Ou
unset($Session['offset']);
// Ou
unset($Session -> offset);

//vérification avec isset 
isset($_SESSION['offset']);
// Ou
isset($Session['offset']);
// Ou
isset($Session -> offset);

?>


 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Historique

26 février 2009 17:08:02 :
Ajout d'une sécurité pour le Cross Site Request Forgeries
02 mars 2009 21:56:18 :
Prit en compte des commentaires :)
15 mars 2009 14:41:02 :
implémentation de la classe arrayaccess qui permet l'utilisation en tant que tableau.
02 avril 2010 17:20:09 :
rajout du mot clef XSS

 Sources du même auteur

Source avec Zip Source avec une capture AFFICHER UNE IMAGE SANS IMAGE (GRÂCE AUX URI)
Source avec Zip SERCACHE2 > CACHE DE PAGES, D'OBJETS, DE REQUÊTES ... (NON T...
Source avec Zip SURCHARGE DE LA CLASSE RECURSIVEDIRECTORYITERATOR POUR RÉCUP...
Source avec Zip SERTPL > CLASS PHP5 POUR GERER LES TEMPLATES SIMPLEMENT
Source avec Zip SERCACHE > CLASS PHP5 POUR LA CRÉATIONS DE CACHES SIMPLEMENT
Toutes les sources de Astalavista

 Sources de la même categorie

Source avec Zip Source avec une capture CAPTCHA AJAX ANTI-BOT par darkvador59
Source avec Zip Source avec une capture ACCÈS, ESPACE MEMBRE AVEC INSCRIPTION ET DÉSINSCRIPTION PAR ... par stephelle
Source avec Zip CRYPTAGE REVERSIBLE par Mokost
Source avec Zip Source avec une capture CREATION DE COMPTE AVEC CRYPTAGE ET ESPACE DE CONNEXION SEC... par bm1982
PROTÉGEZ VOS LIENS DE TÉLÉCHARGEMENT PAR MOT DE PASSE ET/OU ... par unlien
Toutes les sources de la catégorie Sécurité & Cryptage

 Sources en rapport avec celle ci

COMPTEUR DE VISITE - FICHIER TXT - CODE MINIMAL par SuperChouquette
REDIRECTION D'URL par bonhommecrea
Source avec Zip CALENDRIER par gabay
Source avec Zip SERTPL > CLASS PHP5 POUR GERER LES TEMPLATES SIMPLEMENT par Astalavista
Source avec Zip SERCACHE > CLASS PHP5 POUR LA CRÉATIONS DE CACHES SIMPLEMENT par Astalavista

Commentaires et avis

Commentaire de aKheNathOn le 26/02/2009 15:29:16 9/10

Classe sympa, partie sécurisation est assez bien faite. Quelques détails, REMOTE_ADDR est générée par apache contrairement à HTTP_X_FORWARDED_FOR et HTTP_CLIENT_IP qui sont dans les entêtes HTTP. Vu que tu les priorises, j'ai qu'à définir une entête HTTP_X_FORWARDED pour te faire croire que c'est mon IP. Un patch possible serait de prendre en compte les deux :

private function get_IP_Reel() {
  if (isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {
    return $_SERVER["REMOTE_ADDR"].$_SERVER["HTTP_X_FORWARDED_FOR"];
  } elseif (isset($_SERVER["HTTP_CLIENT_IP"])) {
    return $_SERVER["REMOTE_ADDR"].$_SERVER["HTTP_CLIENT_IP"];
  } else {
    return $_SERVER["REMOTE_ADDR"];
  }
}

Afin d'aller plus loin dans la sécurisation, tu devrait également t'intéresser aux failles CSRF (http://www.phpcs.com/codes/PROTECTION-CONTRE-FAILLES-CSRF-CROSS-SITE-REQUEST-FORGERIES_49233.aspx) car après acquisition d'une session, on peut faire à partir d'un site pirate n'importe quelle action, or le principe d'une session est de stocker des données à partir du site navigué, donc si l'appel provient d'un autre domaine, la session devrait être regénérée.

Bonne prog,
Akh

Commentaire de Astalavista le 26/02/2009 16:11:09

Merci de ton commentaire :)

Je vais appliquer ta modification au code source.
Sinon pour les failles CSRF je pense utiliser le $_SERVER['HTTP_REFERER'], vu que ceux-ci sont fournit par le navigateur du client et que tous les navigateurs "sécurisé" l'utilisent. Qu'en pense tu ?

Commentaire de aKheNathOn le 26/02/2009 16:25:16

Oui c'est largement suffisant vu que l'exploit se passe sur une machine en principe "sure".

Après cette modif, ta classe permet une sécurisation béton contre le vol de sessions ou bien contre les attaques CSRF - ça couvre pas mal de failles du coup :)

Je vais certainement l'utiliser pour mes devs ;)

Commentaire de webdeb le 26/02/2009 21:22:26

Mwai ta source est loin d'être au top...

1/ Les constantes de configuration n'ont rien à faire à l'extérieur de ta classe. A la rigueur tu peux utiliser des variables statiques ou bien simplement des propriétés de la classe. Tu peux aussi fournir un tableau au constructeur de la classe qui va initialiser ta session.

2/ L'indentation est complètement déguinglée... C'est illisible !

3/ Tu fais un self::Securise() alors que ta méthode Securise() n'est pas déclarée statique. Tu dois faire un $this->Securise() dans ce cas.

4/ Les noms de classes et de méthodes en français, c'est loin d'être super. Ca limite grandement la diffusion et l'utilisation de ton code au plus grand nombre.

5/ Il serait bien de pouvoir setter les valeurs dans des namespaces comme le font certains framework. Par exemple :

public function setAttribute($name, $value, $ns = '/user/session')
{
  $_SESSION[$ns][$name] = $value;
}

6/ Il manque des méthodes utiles du type hasAttribute()

7/ En PHP 5, le destructeur c'est __destruct()

8/ Ta sécurité anti CSRF n'est pas terrible. Il faudrait plutôt sauver dans la session le hash md5 ou sha1 d'une chaîne. Par exemple :

$_SESSION['salt'] = md5(session_id().rand(0,9999999);
$_SESSION['_csrf_token'] = sha1($_SERVER['HTTP_USER_AGENT'].$salt.$_SESSION['REMOTE_ADDR']);

A chaque nouvelle session tu contrôles le _csrf_token grâce à la salt connue. Si ce n'est pas bon tu jettes une EXCEPTION et si elle est juste, tu régénères un nouveau token pour la page courante.

++

Commentaire de webdeb le 26/02/2009 21:23:07

Dans mon exemple $salt c'est $_SESSION['salt'] ;)

Commentaire de webdeb le 26/02/2009 21:23:48 4/10

Et je note 4/10 au passage.

Commentaire de aKheNathOn le 26/02/2009 23:15:03

Salut Webdeb,

Je suis pas d'accord avec toutes tes remarques. Bien vu le destruct, et éventuellement les fonctions statiques (même si c'est le cas contraire qui ne fonctionne pas).

Pour l'indentation et l'anglais c'est un peu du chippotage, de même que les namespaces qui ne sont pas super optimisées. Dans une session tu mets des variables ou objets, donc pas besoin de tableaux indexées à 3 dimensions.

Ta remarque 8 est complètement à côté de la plaque. Je résume ta proposition en terme de couts : tu crées un salt avec un md5 à l'intérieur duquel tu mets un rand. Ensuite tu fais un sha de l'user agent et du remote address, le tout stocké dans la session.

Ce qui cloche, c'est que d'une part tu ne sécurises pas d'avantage : la session est stockée en local coté serveur et que tous ces cryptages ne servent à rien à part être couteux en tps d'execution. Le hacker ne pourra pas influer sur leur valeur.

En cas de vol de session, si l'utilisateur a la même IP et USER AGENT, il passera la sécurité dans l'exemple que tu donnes ou même en utilisant cette source. Point positif de cette source que tu ne prends pas en compte dans ton code, c'est que la source d'AstaLaVista prends gère la valeur du forward de proxy, cas classique du proxy d'entreprise qui permettrait alors de voler une session soit disons sécurisée.

Tu parles de sécurité anti CSRF, vu l'exemple que tu donnes je ne suis pas certain que tu comprennes vraiment ce que c'est - en tout cas ça n'a rien à voir avec le vol de session, mais plus avec le referer (CR = Cross Site).

Un 4/10 c'est vraiment pas cher payé, parmi toutes les sources de gestion de sessions c'est la SEULE qui gère cette thématique qui est plus que jamais d'actualité.

Sur ce, AstaLaVista je t'encourrage fortement à appliquer un patch pour les failles CSRF et la boucle sera bouclée.

En terme d'évolutions, tu pourrais éventuellement gérer les sessions au niveau de leur handler, ça permettrait d'utiliser dirrectement $_SESSION ... sans avoir à passer par ta classe qui gérerais de manière auto la sécurité : de la doc à cet endroit : http://fr2.php.net/manual/fr/function.session-set-save-handler.php

Bonne prog,
Akh

Commentaire de webdeb le 27/02/2009 00:27:20

@Akhénathon : je ne dis pas que l'exemple que je donne est celui qu'il faut suivre, je donne ni plus ni moins qu'une piste de réflexion. Et pour ta gouverne, je sais très bien ce qu'est une CSRF.

Concernant l'indentation et l'anglais, ça a beau être du chipottage pour toi, mais ça ne l'est pas pour moi pour des raisons évidentes. Savoir indenter son code et respecter des conventions de codage reconnues est selon moi la première chose à avoir en tête lorsque l'on développe. En effet, on développe rarement que pour soi-même. Quand on développe en milieu professionnel dans une équipe ou bien lorsque l'on décide de mettre sa source à disposition du public, c'est la moindre des choses de rendre cette dernière lisible et compréhensible. Et bien sûr, cela passe par l'indentation, le choix des noms des méthodes et des classes mais aussi des commentaires (PHPDoc si possible). Quand on lit une source bâtie sur ces quelques règles élémentaires, ça donne déjà une bonne impression sur le travail du développeur et sur son niveau de compétence. Je travaille chez Sensio, la société qui édite le framework professionel open-source symfony. Clairement, on ne verra jamais passer ce genre de code dans nos projets !

Concernant les namespaces, je ne vois pas en quoi ce n'est pas optimisé. Je serai curieux de connaître l'argument qui te faire dire ça... Un tableau à 2 dimensions n'est pas moins performant qu'un tableau à une dimension. Bien que PHP permette de stocker des objets en session, ce n'est pas du tout une bonne pratique pour des raisons de performances et de place. Il vaut mieux s'arranger pour stocker une représentation de l'objet sous forme d'un tableau sérialisé.

Ensuite, ta remarque sur les performances du calcul de la salt et d'un jeton anti CSRF est totalement invalide. Calculer un hash et une valeur aléatoire, c'est peanut comme temps de traitement. Il faut arrêter avec la performance. Quand on veut travailler avec des objets et de la sécurité, on sait pertinemment que ça va coûter quelques pouillièmes de micro secondes supplémentaires de temps CPU. Je travaille quotidiennement avec symfony, framework entièrement OO et intégrant toute une panoplie de traitement pour sécuriser l'application développée contre les XSS et CSRF. Oui, clairement les performances ne sont pas les mêmes qu'avec une appli procédurale. Mais c'est normal, on fait de l'objet et de la sécurité. Et au final, les serveurs tiennent très bien la charge et délivrent leurs pages très bien. Il n'y a qu'à voir Dailymotion ou Yahoo pour s'en convaincre qui utilise symfony. Donc la notion de performance ça ne veut rien dire en développement web. Et sachant qu'acheter un serveur coûtera toujours moins cher qu'embaucher un développeur pour optimiser l'application, on se moque de gagner 5 ms dans un programme PHP.

Je reviens sur ta remarque concernant le hacker et la viabilité du jeton de protection. Certes les fichiers de session sont présents sur le serveur. Et ? En quoi le hacker pourra-t-il les lire ? La seule manière pour lui d'avoir accès à ces fichiers est de s'introduire physiquement sur la machine ou bien d'y introduire un script malveillant (par le biais un d'un upload non sécurisé par exemple). Sauf que s'il arrive à s'introduire sur le serveur, c'est que la sécurité de l'application est vraiment merdique ! Pour ta gouverne, configurer le répertoire de stockage des sessions fait également partie de la sécurité des sessions. Ca commence par reconfigurer manuellement le répertoire de stockage des sessions qui est /tmp par défaut. Dans le cas d'un serveur mutualisé, on prend aussi garde à ne pas écrire les fichiers de session de tous les sites hébergés dans le même répertoire. Chaque site doit avoir son dossier de sessions, hermétiquement clos et inaccessible par les autres.

Son système de session est très loin d'être performant et d'être évolutif. En effet, il ne permet que de "gérer" (c'est un bien grand mot) les sessions natives de PHP. Mais si j'ai envie de gérer mes sessions dans une base de données par exemple sans avoir à toucher l'implémentation de mon code métier. Comment je fais avec son code ? Bah on ne fait rien, on est grillé. On ne peut pas changer ou faire évoluer efficacement le gestionnaire de sessions.

Bref, ma note n'est pas injustifiée et je la maintiens. Cette classe est clairement "inutilisable" dans un environnement professionnel.

++

Hugo.

Commentaire de Astalavista le 27/02/2009 02:02:23

Bon ...
Pour ton 1, oui je sais, je vais le faire
Pour ton 2, "déglinguée", oui autant que tu as écrit ce mot ; fait le tour de toutes mes sources pour marquer le même message alors :) mais en faite, je ne voit pas ce qui te dérange ...
Pour ton 3, Là je suis dac !
Pour ton 4, je vais voir pour me mettre à l'anglais ... promis ...
Pour ton 5, C'est vrai que sa serait cool ...
Pour ton 6, utile pour toi ?
Pour ton 7, Je sais bien que le destructeur est __destruct ... Mais bon si tu avais vu ma classe, c'est la destruction d'une session et pas d'un objet :)
Et enfin, pour ton 8, Heuuuu ... Où est ta protection avec ton grain de sel ?

Non franchement, pour le dernier point, c'est inutile ton code, hormis si tu passe le jeton dans chaque liens via le GET, dans se cas mon programme ne se nommerais plus SER. Je persiste à dire que ma protection est la plus sûr ET la plus simple. (La tienne est la plus sûr, uniquement)

Franchement je te trouve un peut rude la dessus ... Surtout pour l'indentation ... Je ne voit pas où sa ne colle pas ...

Aller dernier commentaire :) ; pour ton "5 ms dans un programme PHP.", moi je trouve que c'est utile de grappiller du temps, car sur un site a fort trafique, sa compte énormément ... (et le temps c'est e l'argent)

Ha oui, j'allais oublier, ma source n'es pas dans la partie POO du site je croit, mais dans la partie sécurité ...

Commentaire de aKheNathOn le 27/02/2009 10:23:25

Je ne reviens pas sur toutes tes remarques Hugo, juste pour te dire que :

Crypter une donnée que tu mets en session, c'est totalement inutile, ça te fait perdre du temps processeur et ça ne sécurise pas plus. A méditer.

Pour ma part pour le 4/10 et les notes en général, je trouve qu'elles sont là pour encourager les auteurs. J'en mets pas quand la source est pas top à mon gout, je me sert des commentaires pour aider l'auteur et jamais pour le descendre.

CS est un réseau de partage, et même si la source est merdique (je dis pas ça pour cette source) l'auteur à pris le temps de la faire et de la partager, et rien que pour ça il mérite d'être encouragé à continuer.

On est vraiment pas là pour saquer, mais c'est mon avis qui n'est peut-être pas partagé par tt le monde.

Commentaire de aKheNathOn le 27/02/2009 10:26:18

MDR, j'avais pas vu le 5 MS dans ton commentaire. Vas voir ton chef Fabien Potencier et demandes-lui si c'est catastrophique 5ms de plus ou de moins dans le loader de symphony :)))

Non, pour être sérieux, dans les routines de bas niveau, chaque KO de mémoire alloué ou de MS supplémentaire devient vite un goulot d'étranglement ou des benchmarks abominables.

Commentaire de webdeb le 27/02/2009 16:25:36

Je n'ai pas envie de partir dans un troll mais je vais revenir sur quelques points pour clôturer mes remarques. Je n'ai rien contre le fait qu'il partage ses sources mais le problème de Codes Sources c'est que la plupart des codes déposés ici sont très mauvais. Sur 10 codes déposés, il doit à peine y'en avoir un qui tient la route. Donc, à force de voir des codes médiocres, on ne peut s'empêcher de critiquer et parfois de descendre les sources (et leurs auteurs) pour leur montrer la mauvaise qualité de leur code. Je ne critique pas pour le plaisir de critiquer. J'essaie un tant soit peu d'être constructif et de justifier mes remarques, parfois pas toujours...

Quant à symfony (note que ça s'écrit avec un F et non PH !!!), je rigole de ta remarque pas véritablement justifiée. La chasse aux millisecondes ça ne sert strictement à rien, sauf si tu t'appelles Yahoo, Google ou Amazon. Et encore, ces derniers sites ont d'excellents temps de réponse car ils ont d'une part l'argent pour se payer les serveurs qui vont bien mais surtout car les optimisations sont réalisées côté client (optimisation du temps de chargement des pages côté navigateur). Donc on se moque de gagner 5 ou 10 ms sur un serveur lorsque l'on travaille avec un framework orienté objet. Le but d'un framework OO comme symfony ou Zend Framework, c'est d'apporter une structure cohérente et solide pour simplifier, industrialiser et professionnaliser les développements dans le but de les rendre plus pérennes et plus maintenables. D'autant plus que lorsque tu utilises ce genre d'outils, tu as généralement le serveur qui va bien derrière avec au minimum un cache d'opcodes. Si tu veux des ultra hautes performances, alors dans ce cas, tu commences par installer ton serveur web (Apache ou LightHTTPD par exemple) configuré uniquement pour tes besoins (cad que tu lui dégages toutes les lib dont ton projet n'a pas besoin), tu fais de même pour PHP. Tu codes ensuite entièrement en procédural, tu mets du cache de partout, tu optimises côté client (réduction des js et css, optimisation du html, compression gzip...), tu fais de jolis indexes dans ta BDD, tu crées des vues. Ok tu seras plus performant (ou pas !) mais ton projet deviendra très certainement laborieux à faire maintenir et à pérenniser. Sans parler du budget conséquent que ça nécessite !!! C'est bien pour cette raison que Google, Yahoo ou Amazon peuvent se le permettre. A titre d'information, Amazon perd 1% de chiffre d'affaire par jour si les temps de réponse de ses pages augmentent de quelques pouillèmes de millisecondes. Mais mis à part eux, je pense pas qu'il soit véritablement nécessaire de se casser le cul pour 5 ms, sauf si le client est prêt à sortir quelques gros billets. Mais ça, ça se négocie. L'approche pragmatique est bien souvent la meilleure ;)

++

PS : symfony 1.3 et symfony 2.0 seront bien plus performants que les versions actuelles. Mais sache que ZF, Jelix, CakePHP ou n'importe quel autre framework ne sont guère plus performants.

Commentaire de malalam le 01/03/2009 11:48:26 administrateur CS

Hello,

chuis emmerdé là...
Juste, d'emblée, comme ça, parce que je tombe sur la fin du message de webdeb : jelix est une abomination...quant au zend framework, je ne dirai rien par respect pour zend.
Je suis emmerdé parce que je comprends vos 2 approches.
Moi aussi, webdeb, je suis un professionnel du PHP. Un vrai...je bosse dans le PHP depuis une 10aine d'années. C'est ma spécialité. Et je comprends très bien l'approche commerciale...les contraintes de temps vs la qualité du dév. Ne nous leurrons pas...les meilleurs dév PHP ne sont pas des dév à vocation commerciale.
Mais la question est : qu'est-ce qu'un BON dév php?
Symfony est un joli framework. Vraiment :-) Mais dans mon taf...je suis responsable de développement, c'est moi qui décide de comment mes dévs doivent développer. Et je leur interdis formellement d'utiliser quelque framework que ce soit. Ce que l'on perd au départ, on le gagne sur la durée, avec cette approche : pourquoi utiliser un framework dont on va utiliser 10% des possibilités, quand on a tout a fait les moyens, et surtout l'expérience pour développer un framework dédié à nos besoins? On est alors maîtres de nos dév, la "scalability" est bien meilleure.
Je reviens à ce code : je ne l'ai absolument pas regardé, j'ai juste lu les échanges entre 2 très bons dév PHP. Ok...il n'est sans doute pas adapté à un milieu professionnel...mais là, on en vient à PHPCS, webdeb...tu es un professionnel comme moi : les quelques codes que tu as laissés sur phpcs sont-ils proches de ce que tu développes pour ta boîte ? Les miens, non. Enfin, proches...si, sans doute...mais je ne mets pas leurs évolutions en ligne, je ne mets pas les dévs critiques...je ne mets rien de professionnel. Mes meilleurs dév, vous ne les verrez jamais. Chacun des mes appli web php utilisent leur propre espace pour les sessions. C'est une évidence dans un milieu pro. Cela rend-il mauvais un appli de gestion des sessions ne tenant pas compte de ça ? Je ne le pense pas. PHPCS, c'est du grand public...et il ya un fossé entre le PHP grand public, et le PHP professionnel. Enfin...en tous cas, un certain PHP pro...parce que je connais bcp de boîtes prétendant développer en PHP qui sont franchement mauvaises...
Je suis d'accord sur le fait qu'il faille pointer les défaillances. J'aime PHP, réellement. Je pense que c'est un excellent langage. Et je sais coder dans d'autres langages...J'aimerais qu'il gagne ses lettres de noblesses. Mais son côté grand public est aussi ce qui a fait son succès.
PHPCS n'est PAS un repository de codes pro. D'ailleurs, je ne connais aucun site qui puisse se targuer de ne posséder que de bons codes PHP, pas même phpclasses.org.
Oui, sur PHPCS, on a peut-être 1 code sur 10 qui puisse prétendre être un code de niveau professionnel. C'est la stricte vérité.
Mais là où je rejoins Akhé, c'est que ce n'est pas une raison pour massacrer des codes corrects.
Vous parlez d'optimisation, et c'est une lourde discussion. Je te rejoins, webdeb sur ce point : la sécurisation est plus importante que l'optimisation dans un environnement pro. Et qand on code correctement, de toute manière, on optimise quand même suffisamment. Et puis, l'optimisation, ça se travaille sur le long terme. La sécurisation, bien plus rarement. Et effectivement, il faut vraiment de très très gros volumes pour que quelques pouillèmes de secondes se ressentent. Et encore une fois, ça, ça se rattrape.
Il est bien plus important d'avoir un code clair, facilement évolutif, simple, modulaire...
Quant aux remarques sur les commentaires en anglais...mouais...je commente souvent en anglais. Pas toujours, mais souvent. Ceci dit, si le codes est clair, concis, simple...pas besoin de commentaires. Mais bon...il y a le but du code à prendre en compte : je ne suis pas certain que ce code ait pour but d'être utilisé worldwide. Et PHPCS n'est certainement pas un site consulté worldwide.

Bref...j'ai passé un très mauvais we...donc : battez-vous sur des choses tangibles, sur le php...pas sur des considérations qui n'ont pas lieu d'être sur un site tel que PHPCS.


Commentaire de guismo1er le 04/03/2009 17:12:48

Bonjour, pas mal ta source, mais pourrais tu  expliquer à quoi sert:

# // int $cacheLimit : Cache de la session
# // 0 => 'public', 1 => 'private', 2 => 'nocache'


# // bool $idReg : Regénère un id de session à chaques appels

et

# // bool $csrFix : Sécurité pour le Cross Site Request Forgeries

--------------------

C'est juste pour info, je ne critique pas du tout :)

Commentaire de Astalavista le 04/03/2009 23:55:24

XD,
Le cache limit permet de signaler au navigateur le type de session : http://fr.php.net/manual/fr/function.session-cache-limiter.php (en voyant la doc, va faloir que j'ajoute private_no_expire)

idReg, permet de regenerer le numeros de session, c'est juste pour les parano...

le csrFix permet d'empêcher un autre site d'accéder a une commande via une iframe ou autre en vérifiant simplement si la personne a pour référent le même site que le tien ... dans le cas contraire, la session est détruite

j'espère que j'ai répondu a tes questions ...

Commentaire de guismo1er le 05/03/2009 17:13:47

Un grand merci.

Cependant, j'ai lu la doc et je ne trouve pas vraiment à quoi peut servir le cache limiter.

As tu un exemple?

PS: En fait, c'est comme si j'utilisais session_Start(), mais avec plus d'options?

Commentaire de Astalavista le 05/03/2009 17:25:42

Il suffit simplement de lire un peut plus bas sur la page que je t'ai fournit :
public:
    Expires: pageload + 3 hours
    Cache-Control: public, max-age=10800
  
private:
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: private, max-age=10800, pre-check=10800
  
nocache:
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    Pragma: no-cache
  
private_no_expire:
    Cache-Control: private, max-age=10800, pre-check=10800

Et (à mon avis) le "private" permet de prévenir le navigateur qu'il n'y a que ce site qui a le droit d'accéder à ce cache ...

Commentaire de dorian91 le 15/03/2009 00:56:52

Salut
Tu pourrais implementer l'interface ArrayAccess comme ca tu pourrais utiliser ta classe comme la variable $_SESSION.
Ex : $oSession = new session();
     $oSession['test'] = 'truc';

A+

Commentaire de malalam le 15/03/2009 08:37:37 administrateur CS

Hello,

c'est une bonne idée, ArrayAccess, sauf que pour gérer une variable de session qui est un tableau avec, c'est la croix et la bannière! Je le sais, j'ai très exactement essayé la même chose (classe de gestion de session avec ArrayAccess -entre autres classes de la SPL) il y a un an ou deux :-)

Commentaire de Astalavista le 15/03/2009 14:43:33

Voila, c'est fait ...
Et pour ceux que sa n'intéresse pas ; tous les accès au valeurs de la session sont affiché :)

Commentaire de dorian91 le 15/03/2009 15:31:47

Oui le probleme ce sont les tableaux imbriqués dans la session.
Peut etre peut tu t'inspirer d'une classe que j'ai faite pour un package config.
Cela te permettra de faire
$oSession['truc']['bidule']['etc']
ou
$oSession->truc->bidule->etc

http://files.codes-sources.com/fichier.aspx?id=49214&f=package+config%2fsystem%2fiterator%2fmap_iterator.class.php
Il faudra l'adapter car elle est en php5.3 mais ca peut te donner une base.

Commentaire de eltyty le 04/10/2009 14:37:30

Bonjour,

perso je trouve ton code vraiment bien. Du moins pour mon niveau.
Enfin je trouve quelqu'un d'aussi parano que moi lol

Par contre j'ai plusieurs questions, désolé cela va te montrer mon petit level mais bon si tu peux y répondre ;-)

-quel est l'intérêt de donner un nom de session ($$sessionName) ?
-tu indiques bien que ton cookie n'a pas de durée de vie ? si oui pourquoi ?
-la session est valide pendant 300 sec d'inactivité c'est bine ça ?
-perso j'ai du mal à comprendre CSRF_SECU sachant que tu indiques s'il est initialisé et que tu viens d'une autre page alors tu initialise $_SESSION[self::REFERER] pour la suite ???
-Excuse mais j'ai jamais vu de truc comme ça $Session_OK &=  pourquoi le &=
-dernier bine, j'ai regardé la doc mais je ne vois pas l'intérêt de session_regenerate_id(false);. A true oui mais le mettre à false ?

Voilà je sais ça fait beaucoup de question mais j'essaie de faire mon système qui quant à lui reposerai sur une vérif par rapport à une table. Donc j'aimerai m'inspirer de ce que tu as fait :-)
Voilà merci d'avance à ceux qui peuvent m'aider.

Commentaire de Astalavista le 04/10/2009 16:32:54

Le nom de la session est en faite le nom du cookie, on peut créé plusieurs sessions et donc avoir un nom différent ...
Le cookie avec une durée de vie de 0 permet au cookie de rester le temps de l'accès au site, normalement, si tu quitte le site et que tu reviens, le cookie ne serra plus là.
Pour les 300 Sec, c'est bien ça, au bout de 300 secondes passer entre 2 actions, la session serra compté comme invalide.
Le CSRF_SECU permet la protection dans le cas ou une session et déjà créé.
Le & est un et logique, $A &= $B; c'est pareille que $A = $A & $B; après si tu ne connais pas la logique, google est ton amis :)
Le session_regenerate_id(false); permet de générer un nouvel identifiant de sessions sans pour autant la supprimer ... ce qui empêche l'usurpation d'ID.


Sinon, si tu veut utiliser une base de donnée pour les sessions, tu va surement te tourner vers session_set_save_handler() ?

Commentaire de eltyty le 04/10/2009 17:56:39

Re,

merci déjà pour cette rapidité et ces informations. Et bien justement je suis en pleine refonte de mon système et comme je suis pas développeur de métier mais par envie je m'inspire des code que je vois.
Quant à l'utilisation de session_set_save_handler(), je pense utilisé ça même si je t'avoue je suis un peu perdu quant à son utilisation. A l'occasion si ca te tente de réfléchir avec moi pour un système de session par une base de donnée. Je sais déjà que je vais fonctionné avec une table memory.
Il est vrai qu'un coup de main me serai utile ;-)
En tout cas déjà merci

 Ajouter un commentaire


Discussions en rapport avec ce code source dans le forum

Un p'tit code simple mais je sais pas comment le faire ! [ par N e x u m ] Salut,je voudrais avoir un simple code SANS MYSQL (Si possible) Qui garde le même design dans chaque pageAdmettons on a un design (Un look, un interfa Help me....travaille en php "simple" mais payé.....!! [ par Maniac ] Salut,voila je n'y connais rien du tout en php, mais je dois "simplement" faire un forum pour un client pour qui je developpe son site...Si qq1 savait code simple pour formulaire [ par bernard ] bonsoir à tous, je suis débutant de chez débutant et j'ai besoin d'aide.je voudrais réaliser un programme en php.il s'agit d'un formulaire où le visit utilisation de sessions... [ par Clonk ] Bonjour, ça ne fait pas longtemps que j'ai vraiment commencé le PhP et j'aurais juste une question à poser : quelqu'un peut il m'expliquer comment mar PROBLEME SIMPLE [ par g0belin ] sa me repond sa---------------------------ERREUR--------------------Réponse serveur SQL : You have an error in your SQL syntax near '@msn.com, 1234567 nombre de sessions ouvertes [ par eax ] salut je cherche comment connaitre le nombre de sessions php ouvertes à l'instantsans passser par une base de données avec un champ du genre online.me récup données sessions [ par eax ] salutj'aimerais bien savoir comment faire pour récupérer les variables $blabla de chaque sessions ouvertes.(enregistrées avec session_register("blabla sessions php [ par eax ] salutje cherche un site, un tutorial, un bouquin, ... qui explique tout sur les sessions (du début jusqu'aux fonctions approfondies). est-ce que ça ex Gestion sessions [ par elanspeech ] Je souhaiterais pouvoir gerer plusieurs utilisateurs sur mon site avec un systeme de session avec les contraintes : - Un "login" ne peut se logger qu' Gestion sessions [ par elanspeech ] Salut,J'ai des difficultes a resoudre la gestion de session.quand un utilisateur se logue, je met ma base a jour, s'il se deconnecte, je fais de meme.


Nos sponsors


Sondage...

CalendriCode

Mai 2012
LMMJVSD
 123456
78910111213
14151617181920
21222324252627
28293031   

Consulter la suite du CalendriCode

A découvrir
 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,796 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales
Outils Convertisseur VB/C# Snippets et scripts Outils en ligne La ToolBox
Communauté Programmation Photographie Technologie Newsgroups Emploi Forum Blogs
Guide d'achat Téléphonie mobile Image et son Informatique Bureautique Jeux vidéo
Logiciels Internet & Réseau Développement Market Android Jeux & Loisirs Graphisme Multimédia Sécurité Pilotes
Loisirs Cartes virtuelles Vidéos droles Jeux en ligne Géoguide AndroLib (Android Market)