register_globals off, error_reporting E_ALL et design
6 réponses
Christophe MERESSE
Bonsoir,
A force de voir sur le forum qu'il fallait travailler avec register_global à
off et error_reporting E_ALL,
j'ai fini par franchir le pas. Depuis, je me pose de grosses questions
existentielles...
1. A quoi sert le register_global à off lorsqu'on travaille avec
error_reporting E_ALL puisque les variables
non initialisées produisent une erreur (Je ne vois plus trop de problème
éventuel de sécurité...)
Au passage, ce qui est amusant c'est l'avis de Rasmus Lerdorf sur ce
register_global à off.... (voir par
exemple http://www.zend.com/lists/php-dev/200201/msg02620.html)
2. D'autre part, pour passer de pages en pages j'avais:
2.1. soit la solution de faire comme avant des href avec les paramètres dans
l'url et les récupérer cette fois
par $_GET. Mais ou se trouve l'intérêt de faire if ($_GET[param1]=="toto")
.....quand le register est à off
plutôt que if ($param1=="toto") .... quand le register est à on ???
L'utilisateur peut toujours rentrer ce qu'il veut dans les deux cas dans la
variable $param1 pour essayer de trouver
un trou de secu éventuel.
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais
probablement tout rechanger), des
href="javascript:param1.value='toto';... submit();" avec tous les <INPUT
type="hidden"...> qu'il faut. Et la
je récupère mes données avec $_POST mais ça me fout en l'air toute
possibilité d'utilisation du bouton back
du browser (Ce qui est selon moi, inacceptable).
Comment faites-vous ? On pourrait imaginer peut-être la solution de mettre
ces paramètres en session mais
est-ce que ça vaut le coup (je pense que ça oblige l'utilisateur à accepter
les cookies et est-ce plus secure pour
autant ??)
Bref, mon envie c'est de tout refaire comme j'explique dans le 2.1. mais
dans ce cas je me pose toujours la question 1.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jedi121
"Christophe MERESSE" a écrit le 29/10/2003 :
Bonsoir, Bonne nuit même ;)
1. A quoi sert le register_global à off lorsqu'on travaille avec error_reporting E_ALL puisque les variables non initialisées produisent une erreur (Je ne vois plus trop de problème éventuel de sécurité...) Eviter qu'une variable que tu désires voir venir d'un formulaire via un
POST soit en fait passée par un GET. Pire qu'une valeur contenue dans un cookie puisse être passée par un GET à la place.
Au passage, ce qui est amusant c'est l'avis de Rasmus Lerdorf sur ce register_global à off.... (voir par exemple http://www.zend.com/lists/php-dev/200201/msg02620.html) Ben oui, il préfère conserver la facilité de PHP.
2. D'autre part, pour passer de pages en pages j'avais:
2.1. soit la solution de faire comme avant des href avec les paramètres dans l'url et les récupérer cette fois par $_GET. Mais ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") .....quand le register est à off plutôt que if ($param1=="toto") .... quand le register est à on ??? Avec un GET pas vraiment d'intérêt je te l'accorde, avec un POST :
s'assurer qu'on vient d'un formulaire (couplé à l'adresse REFERER pour s'assurer quon vient bien de son propre formulaire), avec un COOKIE ben... voir 1.
L'utilisateur peut toujours rentrer ce qu'il veut dans les deux cas dans la variable $param1 pour essayer de trouver un trou de secu éventuel. Avec GET oui.
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable). Pourquoi? Le bouton Back te demandera si tu veux reposter les données
du formulaire il me semble non?
Comment faites-vous ? On pourrait imaginer peut-être la solution de mettre ces paramètres en session mais est-ce que ça vaut le coup (je pense que ça oblige l'utilisateur à accepter les cookies et est-ce plus secure pour autant ??) Houlala comprends pas tout moi : les sessions ne sont pas forcément des
cookie, elles peuvent être propagées dans l'URL. Non ce n'est pas sûr comme aucune méthode toute simple comme ça. Il faut passer en https:// voir sur ce newsgroup les messages sur sécurisation d'accès, espace membre, etc.
Bref, mon envie c'est de tout refaire comme j'explique dans le 2.1. mais dans ce cas je me pose toujours la question 1.
Merci pour votre avis sur tout ça :) Christophe
"Christophe MERESSE" a écrit le 29/10/2003 :
Bonsoir,
Bonne nuit même ;)
1. A quoi sert le register_global à off lorsqu'on travaille avec
error_reporting E_ALL puisque les variables
non initialisées produisent une erreur (Je ne vois plus trop de problème
éventuel de sécurité...)
Eviter qu'une variable que tu désires voir venir d'un formulaire via un
POST soit en fait passée par un GET. Pire qu'une valeur contenue dans
un cookie puisse être passée par un GET à la place.
Au passage, ce qui est amusant c'est l'avis de Rasmus Lerdorf sur ce
register_global à off.... (voir par
exemple http://www.zend.com/lists/php-dev/200201/msg02620.html)
Ben oui, il préfère conserver la facilité de PHP.
2. D'autre part, pour passer de pages en pages j'avais:
2.1. soit la solution de faire comme avant des href avec les paramètres dans
l'url et les récupérer cette fois
par $_GET. Mais ou se trouve l'intérêt de faire if ($_GET[param1]=="toto")
.....quand le register est à off
plutôt que if ($param1=="toto") .... quand le register est à on ???
Avec un GET pas vraiment d'intérêt je te l'accorde, avec un POST :
s'assurer qu'on vient d'un formulaire (couplé à l'adresse REFERER pour
s'assurer quon vient bien de son propre formulaire), avec un COOKIE
ben... voir 1.
L'utilisateur peut toujours rentrer ce qu'il veut dans les deux cas dans la
variable $param1 pour essayer de trouver
un trou de secu éventuel.
Avec GET oui.
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais
probablement tout rechanger), des
href="javascript:param1.value='toto';... submit();" avec tous les <INPUT
type="hidden"...> qu'il faut. Et la
je récupère mes données avec $_POST mais ça me fout en l'air toute
possibilité d'utilisation du bouton back
du browser (Ce qui est selon moi, inacceptable).
Pourquoi? Le bouton Back te demandera si tu veux reposter les données
du formulaire il me semble non?
Comment faites-vous ? On pourrait imaginer peut-être la solution de mettre
ces paramètres en session mais
est-ce que ça vaut le coup (je pense que ça oblige l'utilisateur à accepter
les cookies et est-ce plus secure pour
autant ??)
Houlala comprends pas tout moi : les sessions ne sont pas forcément des
cookie, elles peuvent être propagées dans l'URL. Non ce n'est pas sûr
comme aucune méthode toute simple comme ça. Il faut passer en https://
voir sur ce newsgroup les messages sur sécurisation d'accès, espace
membre, etc.
Bref, mon envie c'est de tout refaire comme j'explique dans le 2.1. mais
dans ce cas je me pose toujours la question 1.
1. A quoi sert le register_global à off lorsqu'on travaille avec error_reporting E_ALL puisque les variables non initialisées produisent une erreur (Je ne vois plus trop de problème éventuel de sécurité...) Eviter qu'une variable que tu désires voir venir d'un formulaire via un
POST soit en fait passée par un GET. Pire qu'une valeur contenue dans un cookie puisse être passée par un GET à la place.
Au passage, ce qui est amusant c'est l'avis de Rasmus Lerdorf sur ce register_global à off.... (voir par exemple http://www.zend.com/lists/php-dev/200201/msg02620.html) Ben oui, il préfère conserver la facilité de PHP.
2. D'autre part, pour passer de pages en pages j'avais:
2.1. soit la solution de faire comme avant des href avec les paramètres dans l'url et les récupérer cette fois par $_GET. Mais ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") .....quand le register est à off plutôt que if ($param1=="toto") .... quand le register est à on ??? Avec un GET pas vraiment d'intérêt je te l'accorde, avec un POST :
s'assurer qu'on vient d'un formulaire (couplé à l'adresse REFERER pour s'assurer quon vient bien de son propre formulaire), avec un COOKIE ben... voir 1.
L'utilisateur peut toujours rentrer ce qu'il veut dans les deux cas dans la variable $param1 pour essayer de trouver un trou de secu éventuel. Avec GET oui.
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable). Pourquoi? Le bouton Back te demandera si tu veux reposter les données
du formulaire il me semble non?
Comment faites-vous ? On pourrait imaginer peut-être la solution de mettre ces paramètres en session mais est-ce que ça vaut le coup (je pense que ça oblige l'utilisateur à accepter les cookies et est-ce plus secure pour autant ??) Houlala comprends pas tout moi : les sessions ne sont pas forcément des
cookie, elles peuvent être propagées dans l'URL. Non ce n'est pas sûr comme aucune méthode toute simple comme ça. Il faut passer en https:// voir sur ce newsgroup les messages sur sécurisation d'accès, espace membre, etc.
Bref, mon envie c'est de tout refaire comme j'explique dans le 2.1. mais dans ce cas je me pose toujours la question 1.
Merci pour votre avis sur tout ça :) Christophe
Thibaut Allender
Christophe MERESSE wrote:
1. A quoi sert le register_global à off lorsqu'on travaille avec error_reporting E_ALL puisque les variables non initialisées produisent une erreur (Je ne vois plus trop de problème éventuel de sécurité...) Au passage, ce qui est amusant c'est l'avis de Rasmus Lerdorf sur ce register_global à off.... (voir par exemple http://www.zend.com/lists/php-dev/200201/msg02620.html)
sur un serveur de prod il faut de toutes facons supprimer l'output des erreurs.
donc error_reporting E_ALL sur le serveur de test, et rien sur la prod
et je suis du meme avis que Rasmus ;)
2.1. soit la solution de faire comme avant des href avec les paramètres dans l'url et les récupérer cette fois par $_GET. Mais ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") .....quand le register est à off plutôt que if ($param1=="toto") .... quand le register est à on ???
l'interet c'est qu'on est sur que la variable qu'on utilise vient d'un parametre GET et pas d'ailleurs (post, session...)
L'utilisateur peut toujours rentrer ce qu'il veut dans les deux cas dans la variable $param1 pour essayer de trouver un trou de secu éventuel.
sauf qu'il est obligé de le faire par la voie prevue, a savoir GET
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable).
euh pourquoi avoir fait ca ?
Comment faites-vous ? On pourrait imaginer peut-être la solution de mettre ces paramètres en session mais est-ce que ça vaut le coup (je pense que ça oblige l'utilisateur à accepter les cookies et est-ce plus secure pour autant ??)
moi je suis en register globals On la plupart du temps (parce qu'a l'epoque, par defaut c'etait On alors tout le monde ou presque codait avec ca a l'esprit)
le dernier site que j'ai developpé est prevu pour tourner sur du Off... ca n'est pas specialement genant, faut juste faire un peu plus attention
mais encore une fois, on peut tres bien rester en On, faut pas faire n'importe quoi c'est tout :)
a+
-- freelance + web design + php dev + digital photo + http://www.capsule.org
Christophe MERESSE wrote:
1. A quoi sert le register_global à off lorsqu'on travaille avec
error_reporting E_ALL puisque les variables
non initialisées produisent une erreur (Je ne vois plus trop de problème
éventuel de sécurité...)
Au passage, ce qui est amusant c'est l'avis de Rasmus Lerdorf sur ce
register_global à off.... (voir par
exemple http://www.zend.com/lists/php-dev/200201/msg02620.html)
sur un serveur de prod il faut de toutes facons supprimer l'output des
erreurs.
donc error_reporting E_ALL sur le serveur de test, et rien sur la prod
et je suis du meme avis que Rasmus ;)
2.1. soit la solution de faire comme avant des href avec les paramètres dans
l'url et les récupérer cette fois
par $_GET. Mais ou se trouve l'intérêt de faire if ($_GET[param1]=="toto")
.....quand le register est à off
plutôt que if ($param1=="toto") .... quand le register est à on ???
l'interet c'est qu'on est sur que la variable qu'on utilise vient d'un
parametre GET et pas d'ailleurs (post, session...)
L'utilisateur peut toujours rentrer ce qu'il veut dans les deux cas dans la
variable $param1 pour essayer de trouver
un trou de secu éventuel.
sauf qu'il est obligé de le faire par la voie prevue, a savoir GET
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais
probablement tout rechanger), des
href="javascript:param1.value='toto';... submit();" avec tous les <INPUT
type="hidden"...> qu'il faut. Et la
je récupère mes données avec $_POST mais ça me fout en l'air toute
possibilité d'utilisation du bouton back
du browser (Ce qui est selon moi, inacceptable).
euh pourquoi avoir fait ca ?
Comment faites-vous ? On pourrait imaginer peut-être la solution de mettre
ces paramètres en session mais
est-ce que ça vaut le coup (je pense que ça oblige l'utilisateur à accepter
les cookies et est-ce plus secure pour
autant ??)
moi je suis en register globals On la plupart du temps (parce qu'a
l'epoque, par defaut c'etait On alors tout le monde ou presque codait
avec ca a l'esprit)
le dernier site que j'ai developpé est prevu pour tourner sur du Off...
ca n'est pas specialement genant, faut juste faire un peu plus attention
mais encore une fois, on peut tres bien rester en On, faut pas faire
n'importe quoi c'est tout :)
a+
--
freelance + web design + php dev + digital photo
+ http://www.capsule.org
1. A quoi sert le register_global à off lorsqu'on travaille avec error_reporting E_ALL puisque les variables non initialisées produisent une erreur (Je ne vois plus trop de problème éventuel de sécurité...) Au passage, ce qui est amusant c'est l'avis de Rasmus Lerdorf sur ce register_global à off.... (voir par exemple http://www.zend.com/lists/php-dev/200201/msg02620.html)
sur un serveur de prod il faut de toutes facons supprimer l'output des erreurs.
donc error_reporting E_ALL sur le serveur de test, et rien sur la prod
et je suis du meme avis que Rasmus ;)
2.1. soit la solution de faire comme avant des href avec les paramètres dans l'url et les récupérer cette fois par $_GET. Mais ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") .....quand le register est à off plutôt que if ($param1=="toto") .... quand le register est à on ???
l'interet c'est qu'on est sur que la variable qu'on utilise vient d'un parametre GET et pas d'ailleurs (post, session...)
L'utilisateur peut toujours rentrer ce qu'il veut dans les deux cas dans la variable $param1 pour essayer de trouver un trou de secu éventuel.
sauf qu'il est obligé de le faire par la voie prevue, a savoir GET
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable).
euh pourquoi avoir fait ca ?
Comment faites-vous ? On pourrait imaginer peut-être la solution de mettre ces paramètres en session mais est-ce que ça vaut le coup (je pense que ça oblige l'utilisateur à accepter les cookies et est-ce plus secure pour autant ??)
moi je suis en register globals On la plupart du temps (parce qu'a l'epoque, par defaut c'etait On alors tout le monde ou presque codait avec ca a l'esprit)
le dernier site que j'ai developpé est prevu pour tourner sur du Off... ca n'est pas specialement genant, faut juste faire un peu plus attention
mais encore une fois, on peut tres bien rester en On, faut pas faire n'importe quoi c'est tout :)
a+
-- freelance + web design + php dev + digital photo + http://www.capsule.org
Olivier Miakinen
Christophe, je profite de ton article pour rappeler une erreur fréquente qu'il est bon d'éviter :
[...] ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") [...]
Voir : http://fr3.php.net/manual/fr/print/language.types.array.php (Attention aux tableaux - Pourquoi est-ce que $foo[bar] est invalide)
Christophe, je profite de ton article pour rappeler une erreur fréquente
qu'il est bon d'éviter :
[...] ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") [...]
Voir : http://fr3.php.net/manual/fr/print/language.types.array.php
(Attention aux tableaux - Pourquoi est-ce que $foo[bar] est invalide)
Christophe, je profite de ton article pour rappeler une erreur fréquente qu'il est bon d'éviter :
[...] ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") [...]
Voir : http://fr3.php.net/manual/fr/print/language.types.array.php (Attention aux tableaux - Pourquoi est-ce que $foo[bar] est invalide)
Christophe MERESSE
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais
probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable). Pourquoi? Le bouton Back te demandera si tu veux reposter les données
du formulaire il me semble non?
Oui effectivement mais ca ne me plait pas, c'est génant et ca casse pas mal l'integrité du site...
En tout cas, merci pour tes réponses. Christophe
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je
vais
probablement tout rechanger), des
href="javascript:param1.value='toto';... submit();" avec tous les <INPUT
type="hidden"...> qu'il faut. Et la
je récupère mes données avec $_POST mais ça me fout en l'air toute
possibilité d'utilisation du bouton back
du browser (Ce qui est selon moi, inacceptable).
Pourquoi? Le bouton Back te demandera si tu veux reposter les données
du formulaire il me semble non?
Oui effectivement mais ca ne me plait pas, c'est génant et ca casse pas mal
l'integrité du site...
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais
probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable). Pourquoi? Le bouton Back te demandera si tu veux reposter les données
du formulaire il me semble non?
Oui effectivement mais ca ne me plait pas, c'est génant et ca casse pas mal l'integrité du site...
En tout cas, merci pour tes réponses. Christophe
Christophe MERESSE
sur un serveur de prod il faut de toutes facons supprimer l'output des erreurs.
Je le note !
et je suis du meme avis que Rasmus ;)
Aaaah :)
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais
probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable).
euh pourquoi avoir fait ca ?
Je me pose encore la question :) Probablement parceque j'avais mal interpreté ces éventuels problèmes de securité... Mais je vais rechanger.
moi je suis en register globals On la plupart du temps (parce qu'a l'epoque, par defaut c'etait On alors tout le monde ou presque codait avec ca a l'esprit)
le dernier site que j'ai developpé est prevu pour tourner sur du Off... ca n'est pas specialement genant, faut juste faire un peu plus attention
mais encore une fois, on peut tres bien rester en On, faut pas faire n'importe quoi c'est tout :)
Ok, merci beaucoup Christophe
sur un serveur de prod il faut de toutes facons supprimer l'output des
erreurs.
Je le note !
et je suis du meme avis que Rasmus ;)
Aaaah :)
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je
vais
probablement tout rechanger), des
href="javascript:param1.value='toto';... submit();" avec tous les <INPUT
type="hidden"...> qu'il faut. Et la
je récupère mes données avec $_POST mais ça me fout en l'air toute
possibilité d'utilisation du bouton back
du browser (Ce qui est selon moi, inacceptable).
euh pourquoi avoir fait ca ?
Je me pose encore la question :) Probablement parceque j'avais mal
interpreté ces
éventuels problèmes de securité... Mais je vais rechanger.
moi je suis en register globals On la plupart du temps (parce qu'a
l'epoque, par defaut c'etait On alors tout le monde ou presque codait
avec ca a l'esprit)
le dernier site que j'ai developpé est prevu pour tourner sur du Off...
ca n'est pas specialement genant, faut juste faire un peu plus attention
mais encore une fois, on peut tres bien rester en On, faut pas faire
n'importe quoi c'est tout :)
sur un serveur de prod il faut de toutes facons supprimer l'output des erreurs.
Je le note !
et je suis du meme avis que Rasmus ;)
Aaaah :)
2.2. soit ce que j'ai fait maintenant et que je regrette amèrement (Je vais
probablement tout rechanger), des href="javascript:param1.value='toto';... submit();" avec tous les <INPUT type="hidden"...> qu'il faut. Et la je récupère mes données avec $_POST mais ça me fout en l'air toute possibilité d'utilisation du bouton back du browser (Ce qui est selon moi, inacceptable).
euh pourquoi avoir fait ca ?
Je me pose encore la question :) Probablement parceque j'avais mal interpreté ces éventuels problèmes de securité... Mais je vais rechanger.
moi je suis en register globals On la plupart du temps (parce qu'a l'epoque, par defaut c'etait On alors tout le monde ou presque codait avec ca a l'esprit)
le dernier site que j'ai developpé est prevu pour tourner sur du Off... ca n'est pas specialement genant, faut juste faire un peu plus attention
mais encore une fois, on peut tres bien rester en On, faut pas faire n'importe quoi c'est tout :)
Ok, merci beaucoup Christophe
Christophe MERESSE
"Olivier Miakinen" a écrit dans le message de news:bnr40d$9ba$
Christophe, je profite de ton article pour rappeler une erreur fréquente qu'il est bon d'éviter :
[...] ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") [...]
Voir : http://fr3.php.net/manual/fr/print/language.types.array.php (Attention aux tableaux - Pourquoi est-ce que $foo[bar] est invalide)
Oui merci, effectivement ces erreurs sont d'ailleurs repérées avec error_reporting E_ALL, comme quoi je n'y suis pas encore habitué ;)
A+ Christophe
"Olivier Miakinen" <Olivier.Miakinen@evidian.com> a écrit dans le message de
news:bnr40d$9ba$1@cabale.usenet-fr.net...
Christophe, je profite de ton article pour rappeler une erreur fréquente
qu'il est bon d'éviter :
[...] ou se trouve l'intérêt de faire if ($_GET[param1]=="toto") [...]
Voir : http://fr3.php.net/manual/fr/print/language.types.array.php
(Attention aux tableaux - Pourquoi est-ce que $foo[bar] est invalide)
Oui merci, effectivement ces erreurs sont d'ailleurs repérées avec
error_reporting E_ALL, comme
quoi je n'y suis pas encore habitué ;)
