SERSESSIONS > CLASS PHP5 POUR GERER LES SESSIONS SIMPLEMENT (PROTECTION XSS)
Utilisateur anonyme
-
26 févr. 2009 à 15:29
cs_eltyty Messages postés 86 Date d'inscription mercredi 31 janvier 2007 Statut Membre Dernière intervention 22 novembre 2011 - 4 oct. 2009 à 17:56
cs_eltyty Messages postés 86 Date d'inscription mercredi 31 janvier 2007 Statut Membre Dernière intervention 22 novembre 2011 - 4 oct. 2009 à 17:56
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/49367-sersessions-class-php5-pour-gerer-les-sessions-simplement-protection-xss
https://codes-sources.commentcamarche.net/source/49367-sersessions-class-php5-pour-gerer-les-sessions-simplement-protection-xss
4 oct. 2009 à 17:56
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
4 oct. 2009 à 16:32
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() ?
4 oct. 2009 à 14:37
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.
15 mars 2009 à 15:31
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.
15 mars 2009 à 14:43
Et pour ceux que sa n'intéresse pas ; tous les accès au valeurs de la session sont affiché :)
15 mars 2009 à 08:37
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 :-)
15 mars 2009 à 00:56
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+
5 mars 2009 à 17:25
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 ...
5 mars 2009 à 17:13
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?
4 mars 2009 à 23:55
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 ...
4 mars 2009 à 17:12
# // 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 :)
1 mars 2009 à 11:48
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.
27 févr. 2009 à 16:25
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.
27 févr. 2009 à 10:26
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.
27 févr. 2009 à 10:23
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.
27 févr. 2009 à 02:02
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é ...
27 févr. 2009 à 00:27
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.
26 févr. 2009 à 23:15
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
26 févr. 2009 à 21:23
26 févr. 2009 à 21:23
26 févr. 2009 à 21:22
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.
++
26 févr. 2009 à 16:25
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 ;)
26 févr. 2009 à 16:11
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 ?
26 févr. 2009 à 15:29
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