Et lorsque j'affiche un texte avec une ', j'ai un slash qui
se met devant. Le truc, c'est que c'est de manière aléatoire.
Mon texte est pris d'une base de données et dans la base, le
texte est comme il faut, avec l'apostrophe et sans slash.
Exemple :
à l'internationnal se transforme en l\'international et ceci
de manière aléatoire. En rechargeant la page, soit le slash apparait
soit il disparait ........
Est-ce que quelqu'un a déjà rencontré le problème ou si quelqu'un
a une idée. Merci d'avance pour vos réponses.
C'est un comportement totalement stupide de PHP qui a été créé pour empêcher qu'il y ait des failles de sécurité dans les sites mal codés faits pour fonctionner avec MySQL.
heu, juste comme ça, tu la connais, la faille de sécurité en question ??? tu serais capable de l'appliquer, ou tu en as juste entendu parler??? parce que franchement sans magic_quotes, je suis sur qu'en gros 3 site sur 4 seraient vulnérables. Et il ne s'agit pas juste de pouvoir passer un formulaire d'authentification....
les magic_quotes, c'est bon, mangez en
Lascap
C'est un comportement totalement stupide de PHP qui a été créé pour
empêcher qu'il y ait des failles de sécurité dans les sites mal codés
faits pour fonctionner avec MySQL.
heu, juste comme ça, tu la connais, la faille de sécurité en question ??? tu
serais capable de l'appliquer, ou tu en as juste entendu parler??? parce que
franchement sans magic_quotes, je suis sur qu'en gros 3 site sur 4 seraient
vulnérables. Et il ne s'agit pas juste de pouvoir passer un formulaire
d'authentification....
C'est un comportement totalement stupide de PHP qui a été créé pour empêcher qu'il y ait des failles de sécurité dans les sites mal codés faits pour fonctionner avec MySQL.
heu, juste comme ça, tu la connais, la faille de sécurité en question ??? tu serais capable de l'appliquer, ou tu en as juste entendu parler??? parce que franchement sans magic_quotes, je suis sur qu'en gros 3 site sur 4 seraient vulnérables. Et il ne s'agit pas juste de pouvoir passer un formulaire d'authentification....
les magic_quotes, c'est bon, mangez en
Lascap
John Gallet
Bonjour,
Il est totalement illogique de mettre des slashes comme ça pour déconner au données GET, POST et Cookie.
Sur le fond oui. Mais notons quand même que :
- si ce n'était pas fait automatiquement ce serait reproché au langage en tant que faille de sécurité, même si c'est idiot (cf l'affaire register_globals même sur des listes en général sérieuses comme bugtrack) - il suffit de tester par get_magic_quotes_gpc() si les slahes ont été ajoutés - en version bourrin on peut toujours utiliser un addslashes(stripslashes($toto)) (oui je sais c'est sous optimal) sur les variables sensibles - si on fait les choses proprement on écrit le code de traitement des variables à un et un seul endroit donc c'est pas 4 lignes de plus qui vont vraiement gêner le développeur.
Surtout que d'autres bases de données n'utilisent pas les slashes pour échapper les guillemets ou apostrophes.
Lesquelles ? Et avec quel caractère d'échappement si elles en utilisent ? Là au réveil et sans oracle ni sybase sous la main, je n'ai pas de quoi faire un test unitaire avant lundi. Bien entendu on parle de leur utilisation en conjonction avec PHP.
Alors là on pourrait faire jouer magic_quotes_sybase... Enfin ces options sont bien peu pratiques, mieux vaut utiliser une fonction spécifique à sa base de données pour échapper ce qui est nécessaire.
Si on veut faire les choses proprement il faut faire bien plus que ça, à commencer par filtrer ses variables en entrée par type en les comparant par rapport à une liste de caractères autorisés. Alors ajouter un coup de addslashes manuellement sur les types qui autorisent la présence de ' et " ne devrait pas être trop dur.
a++ JG
Bonjour,
Il est totalement illogique de mettre des slashes comme ça pour déconner
au données GET, POST et Cookie.
Sur le fond oui. Mais notons quand même que :
- si ce n'était pas fait automatiquement ce serait reproché au langage en
tant que faille de sécurité, même si c'est idiot (cf l'affaire
register_globals même sur des listes en général sérieuses comme bugtrack)
- il suffit de tester par get_magic_quotes_gpc() si les slahes ont été
ajoutés
- en version bourrin on peut toujours utiliser un
addslashes(stripslashes($toto)) (oui je sais c'est sous optimal) sur les
variables sensibles
- si on fait les choses proprement on écrit le code de traitement des
variables à un et un seul endroit donc c'est pas 4 lignes de plus qui vont
vraiement gêner le développeur.
Surtout que d'autres bases de données
n'utilisent pas les slashes pour échapper les guillemets ou apostrophes.
Lesquelles ? Et avec quel caractère d'échappement si elles en utilisent ? Là
au réveil et sans oracle ni sybase sous la main, je n'ai pas de quoi faire
un test unitaire avant lundi. Bien entendu on parle de leur utilisation en
conjonction avec PHP.
Alors là on pourrait faire jouer magic_quotes_sybase... Enfin ces
options sont bien peu pratiques, mieux vaut utiliser une fonction
spécifique à sa base de données pour échapper ce qui est nécessaire.
Si on veut faire les choses proprement il faut faire bien plus que ça, à
commencer par filtrer ses variables en entrée par type en les comparant par
rapport à une liste de caractères autorisés. Alors ajouter un coup de
addslashes manuellement sur les types qui autorisent la présence de ' et "
ne devrait pas être trop dur.
Il est totalement illogique de mettre des slashes comme ça pour déconner au données GET, POST et Cookie.
Sur le fond oui. Mais notons quand même que :
- si ce n'était pas fait automatiquement ce serait reproché au langage en tant que faille de sécurité, même si c'est idiot (cf l'affaire register_globals même sur des listes en général sérieuses comme bugtrack) - il suffit de tester par get_magic_quotes_gpc() si les slahes ont été ajoutés - en version bourrin on peut toujours utiliser un addslashes(stripslashes($toto)) (oui je sais c'est sous optimal) sur les variables sensibles - si on fait les choses proprement on écrit le code de traitement des variables à un et un seul endroit donc c'est pas 4 lignes de plus qui vont vraiement gêner le développeur.
Surtout que d'autres bases de données n'utilisent pas les slashes pour échapper les guillemets ou apostrophes.
Lesquelles ? Et avec quel caractère d'échappement si elles en utilisent ? Là au réveil et sans oracle ni sybase sous la main, je n'ai pas de quoi faire un test unitaire avant lundi. Bien entendu on parle de leur utilisation en conjonction avec PHP.
Alors là on pourrait faire jouer magic_quotes_sybase... Enfin ces options sont bien peu pratiques, mieux vaut utiliser une fonction spécifique à sa base de données pour échapper ce qui est nécessaire.
Si on veut faire les choses proprement il faut faire bien plus que ça, à commencer par filtrer ses variables en entrée par type en les comparant par rapport à une liste de caractères autorisés. Alors ajouter un coup de addslashes manuellement sur les types qui autorisent la présence de ' et " ne devrait pas être trop dur.
a++ JG
loufoque
Message d'origine de John Gallet :
Lesquelles ? Et avec quel caractère d'échappement si elles en utilisent ? Là au réveil et sans oracle ni sybase sous la main, je n'ai pas de quoi faire un test unitaire avant lundi. Bien entendu on parle de leur utilisation en conjonction avec PHP.
SQLite par exemple (qui devrait devenir très populaire à partir de php5)
Un ' est échappé par un autre '.
Dans un soucis d'interopératibilité avec les différentes bases de données, utiliser une fonction spécifique à sa bdd est plus pratique. mysql_escape_string() pour MySQL sqlite_escape_string() pour SQLite
Et il est évident qu'il faut échapper certains caractères lors d'une requête SQL... SELECT truc FROM table WHERE machin = 'J'adore l'SQL' On a un problème évident. Il faut utiliser SELECT truc FROM table WHERE machin = 'J'adore l'SQL' pour MySQL par exemple. Après, si les gens sont pas capables de voir qu'il faut échapper certains caractères pour créer une requête, ça ne sert à rien d'essayer de développer des sites webs.
Message d'origine de Thibaut Allender :
pas si stupide que ca si on dénombre les sites mal codés qui utilisent mysql :) Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
l'utilise qui veut magic_quotes_gpc n'est pas activable/désactivable si facilement
On ne peut même pas y accéder avec ini_set() Donc pour une compatibilité sur la plupart des serveurs ont est obligé de se taper des stripslashes sur tous les tableaux.
Message d'origine de John Gallet :
Lesquelles ? Et avec quel caractère d'échappement si elles en utilisent ? Là
au réveil et sans oracle ni sybase sous la main, je n'ai pas de quoi faire
un test unitaire avant lundi. Bien entendu on parle de leur utilisation en
conjonction avec PHP.
SQLite par exemple (qui devrait devenir très populaire à partir de php5)
Un ' est échappé par un autre '.
Dans un soucis d'interopératibilité avec les différentes bases de
données, utiliser une fonction spécifique à sa bdd est plus pratique.
mysql_escape_string() pour MySQL
sqlite_escape_string() pour SQLite
Et il est évident qu'il faut échapper certains caractères lors d'une
requête SQL...
SELECT truc FROM table WHERE machin = 'J'adore l'SQL'
On a un problème évident.
Il faut utiliser SELECT truc FROM table WHERE machin = 'J'adore l'SQL'
pour MySQL par exemple.
Après, si les gens sont pas capables de voir qu'il faut échapper
certains caractères pour créer une requête, ça ne sert à rien d'essayer
de développer des sites webs.
Message d'origine de Thibaut Allender :
pas si stupide que ca si on dénombre les sites mal codés qui utilisent
mysql :)
Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
l'utilise qui veut
magic_quotes_gpc n'est pas activable/désactivable si facilement
On ne peut même pas y accéder avec ini_set()
Donc pour une compatibilité sur la plupart des serveurs ont est obligé
de se taper des stripslashes sur tous les tableaux.
Lesquelles ? Et avec quel caractère d'échappement si elles en utilisent ? Là au réveil et sans oracle ni sybase sous la main, je n'ai pas de quoi faire un test unitaire avant lundi. Bien entendu on parle de leur utilisation en conjonction avec PHP.
SQLite par exemple (qui devrait devenir très populaire à partir de php5)
Un ' est échappé par un autre '.
Dans un soucis d'interopératibilité avec les différentes bases de données, utiliser une fonction spécifique à sa bdd est plus pratique. mysql_escape_string() pour MySQL sqlite_escape_string() pour SQLite
Et il est évident qu'il faut échapper certains caractères lors d'une requête SQL... SELECT truc FROM table WHERE machin = 'J'adore l'SQL' On a un problème évident. Il faut utiliser SELECT truc FROM table WHERE machin = 'J'adore l'SQL' pour MySQL par exemple. Après, si les gens sont pas capables de voir qu'il faut échapper certains caractères pour créer une requête, ça ne sert à rien d'essayer de développer des sites webs.
Message d'origine de Thibaut Allender :
pas si stupide que ca si on dénombre les sites mal codés qui utilisent mysql :) Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
l'utilise qui veut magic_quotes_gpc n'est pas activable/désactivable si facilement
On ne peut même pas y accéder avec ini_set() Donc pour une compatibilité sur la plupart des serveurs ont est obligé de se taper des stripslashes sur tous les tableaux.
Thibaut Allender
Après, si les gens sont pas capables de voir qu'il faut échapper certains caractères pour créer une requête, ça ne sert à rien d'essayer de développer des sites webs.
connais-tu la notion d'apprentissage ?
Message d'origine de Thibaut Allender :
pas si stupide que ca si on dénombre les sites mal codés qui utilisent mysql :) Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
je ne vois pas le rapport entre ma remarque et ta reponse je dis que ca n'est pas si stupide le magic_quotes par defaut, justement pour cette categorie de personnes
quant a utiliser php comme un jouet, pourquoi pas, il y a plein de gens qui font du php pour le plaisir, ils n'ont pas forcemment la pretention d'en faire leur metier
l'utilise qui veut magic_quotes_gpc n'est pas activable/désactivable si facilement
On ne peut même pas y accéder avec ini_set() Donc pour une compatibilité sur la plupart des serveurs ont est obligé de se taper des stripslashes sur tous les tableaux.
ben... en lisant tes propos, tu parles d'une certaine elite. quand on fait partie de cette elite, on peut bien demander a l'hebergeur d'activiter/desactiver certaines options non ?
Après, si les gens sont pas capables de voir qu'il faut échapper
certains caractères pour créer une requête, ça ne sert à rien d'essayer
de développer des sites webs.
connais-tu la notion d'apprentissage ?
Message d'origine de Thibaut Allender :
pas si stupide que ca si on dénombre les sites mal codés qui utilisent
mysql :)
Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
je ne vois pas le rapport entre ma remarque et ta reponse
je dis que ca n'est pas si stupide le magic_quotes par defaut, justement
pour cette categorie de personnes
quant a utiliser php comme un jouet, pourquoi pas, il y a plein de gens
qui font du php pour le plaisir, ils n'ont pas forcemment la pretention
d'en faire leur metier
l'utilise qui veut
magic_quotes_gpc n'est pas activable/désactivable si facilement
On ne peut même pas y accéder avec ini_set()
Donc pour une compatibilité sur la plupart des serveurs ont est obligé
de se taper des stripslashes sur tous les tableaux.
ben... en lisant tes propos, tu parles d'une certaine elite.
quand on fait partie de cette elite, on peut bien demander a l'hebergeur
d'activiter/desactiver certaines options non ?
Après, si les gens sont pas capables de voir qu'il faut échapper certains caractères pour créer une requête, ça ne sert à rien d'essayer de développer des sites webs.
connais-tu la notion d'apprentissage ?
Message d'origine de Thibaut Allender :
pas si stupide que ca si on dénombre les sites mal codés qui utilisent mysql :) Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
je ne vois pas le rapport entre ma remarque et ta reponse je dis que ca n'est pas si stupide le magic_quotes par defaut, justement pour cette categorie de personnes
quant a utiliser php comme un jouet, pourquoi pas, il y a plein de gens qui font du php pour le plaisir, ils n'ont pas forcemment la pretention d'en faire leur metier
l'utilise qui veut magic_quotes_gpc n'est pas activable/désactivable si facilement
On ne peut même pas y accéder avec ini_set() Donc pour une compatibilité sur la plupart des serveurs ont est obligé de se taper des stripslashes sur tous les tableaux.
ben... en lisant tes propos, tu parles d'une certaine elite. quand on fait partie de cette elite, on peut bien demander a l'hebergeur d'activiter/desactiver certaines options non ?
SQLite par exemple (qui devrait devenir très populaire à partir de php5) Ah bon ? Moi le jour où j'ai enfin des transactions et des clefs
étrangères dans mysql je vois pas pourquoi j'irais en prendre une autre hein. Et j'ai déjà PostGresql si j'en veux vraiment. Alors **encore** une ? Mais bon bref, on s'éloigne largeemnt du sujet
Un ' est échappé par un autre '. Et sous sybase aussi de toutes façons.
Dans un soucis d'interopératibilité avec les différentes bases de données, utiliser une fonction spécifique à sa bdd est plus pratique.
Ce qui serait le plus pratique ce serait surtout de pouvoir configurer quelque part la listedes caractères impactés par magic quotes runtime avec le caractère d'échappement à choisir. Ca ce serait faire les choses proprement.
Après, si les gens sont pas capables de voir qu'il faut échapper certains caractères pour créer une requête, ça ne sert à rien d'essayer de développer des sites webs.
Oui et non. Il y a une énorme différence entre être capable de détecter une erreur de syntaxe sql et comprendre le principe d'une injection sql. Je suis le premier à dire qu'on ne s'improvise pas développeur mais j'en connais un certain nombre qui se donnent cette fonction qui n'ont jamais vu une attaque dans la vraie vie.
pas si stupide que ca si on dénombre les sites mal codés qui utilisent mysql :) Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
Mais comme je le disais si ces sites là codés à la petite semaine présentent des failles c'est tout le langage qui en prend un coup pour son image de marque. C'est stupide mais on l'a déjà vu avec le coup de register_globals. D'ailleurs c'est un principe très simple : la configuration par défaut protège ceux qui ne connaissent pas bien. Libre aux autres de faire ce qu'ils veulent.
magic_quotes_gpc n'est pas activable/désactivable si facilement On ne peut même pas y accéder avec ini_set()
Sachant qu'on peut y accéder avec un .htaccess donc ça reste quand même suffisement souple avec apache.
Donc pour une compatibilité sur la plupart des serveurs ont est obligé de se taper des stripslashes sur tous les tableaux.
Enfin la plupart des serveurs, allons y doucement, si ce serveur te propose une autre base de données que mysqsl c'est qu'on doit pouvoir le paramétrer un strict minimum à son goût quand même non ? Et quand à se faire "tous" les tableaux, personnellement je n'en vois qu'un seul : $_REQUEST. Et de plus il suffit de faire ça dans sa fonction de filtrage et on a trois lignes de code à écrire.
Donc que le comportement par défaut de php ne convienne pas à tes besoins, soit, mais n'exagère quand même pas l'impact que ça peut avoir sur les développements.
a++ JG
Re,
SQLite par exemple (qui devrait devenir très populaire à partir de php5)
Ah bon ? Moi le jour où j'ai enfin des transactions et des clefs
étrangères dans mysql je vois pas pourquoi j'irais en prendre une autre
hein. Et j'ai déjà PostGresql si j'en veux vraiment. Alors **encore**
une ? Mais bon bref, on s'éloigne largeemnt du sujet
Un ' est échappé par un autre '.
Et sous sybase aussi de toutes façons.
Dans un soucis d'interopératibilité avec les différentes bases de
données, utiliser une fonction spécifique à sa bdd est plus pratique.
Ce qui serait le plus pratique ce serait surtout de pouvoir configurer
quelque part la listedes caractères impactés par magic quotes runtime
avec le caractère d'échappement à choisir. Ca ce serait faire les choses
proprement.
Après, si les gens sont pas capables de voir qu'il faut échapper
certains caractères pour créer une requête, ça ne sert à rien d'essayer
de développer des sites webs.
Oui et non. Il y a une énorme différence entre être capable de détecter
une erreur de syntaxe sql et comprendre le principe d'une injection sql.
Je suis le premier à dire qu'on ne s'improvise pas développeur mais j'en
connais un certain nombre qui se donnent cette fonction qui n'ont jamais
vu une attaque dans la vraie vie.
pas si stupide que ca si on dénombre les sites mal codés qui utilisent
mysql :)
Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
Mais comme je le disais si ces sites là codés à la petite semaine
présentent des failles c'est tout le langage qui en prend un coup pour
son image de marque. C'est stupide mais on l'a déjà vu avec le coup de
register_globals.
D'ailleurs c'est un principe très simple : la configuration par défaut
protège ceux qui ne connaissent pas bien. Libre aux autres de faire ce
qu'ils veulent.
magic_quotes_gpc n'est pas activable/désactivable si facilement
On ne peut même pas y accéder avec ini_set()
Sachant qu'on peut y accéder avec un .htaccess donc ça reste quand même
suffisement souple avec apache.
Donc pour une compatibilité sur la plupart des serveurs ont est obligé
de se taper des stripslashes sur tous les tableaux.
Enfin la plupart des serveurs, allons y doucement, si ce serveur te
propose une autre base de données que mysqsl c'est qu'on doit pouvoir le
paramétrer un strict minimum à son goût quand même non ? Et quand à se
faire "tous" les tableaux, personnellement je n'en vois qu'un seul :
$_REQUEST. Et de plus il suffit de faire ça dans sa fonction de filtrage
et on a trois lignes de code à écrire.
Donc que le comportement par défaut de php ne convienne pas à tes
besoins, soit, mais n'exagère quand même pas l'impact que ça peut avoir
sur les développements.
SQLite par exemple (qui devrait devenir très populaire à partir de php5) Ah bon ? Moi le jour où j'ai enfin des transactions et des clefs
étrangères dans mysql je vois pas pourquoi j'irais en prendre une autre hein. Et j'ai déjà PostGresql si j'en veux vraiment. Alors **encore** une ? Mais bon bref, on s'éloigne largeemnt du sujet
Un ' est échappé par un autre '. Et sous sybase aussi de toutes façons.
Dans un soucis d'interopératibilité avec les différentes bases de données, utiliser une fonction spécifique à sa bdd est plus pratique.
Ce qui serait le plus pratique ce serait surtout de pouvoir configurer quelque part la listedes caractères impactés par magic quotes runtime avec le caractère d'échappement à choisir. Ca ce serait faire les choses proprement.
Après, si les gens sont pas capables de voir qu'il faut échapper certains caractères pour créer une requête, ça ne sert à rien d'essayer de développer des sites webs.
Oui et non. Il y a une énorme différence entre être capable de détecter une erreur de syntaxe sql et comprendre le principe d'une injection sql. Je suis le premier à dire qu'on ne s'improvise pas développeur mais j'en connais un certain nombre qui se donnent cette fonction qui n'ont jamais vu une attaque dans la vraie vie.
pas si stupide que ca si on dénombre les sites mal codés qui utilisent mysql :) Ce n'est pas parce qu'une majorité de gens considère PHP comme un jouet
et code au petit bonheur la chance que tout le monde doit le faire.
Mais comme je le disais si ces sites là codés à la petite semaine présentent des failles c'est tout le langage qui en prend un coup pour son image de marque. C'est stupide mais on l'a déjà vu avec le coup de register_globals. D'ailleurs c'est un principe très simple : la configuration par défaut protège ceux qui ne connaissent pas bien. Libre aux autres de faire ce qu'ils veulent.
magic_quotes_gpc n'est pas activable/désactivable si facilement On ne peut même pas y accéder avec ini_set()
Sachant qu'on peut y accéder avec un .htaccess donc ça reste quand même suffisement souple avec apache.
Donc pour une compatibilité sur la plupart des serveurs ont est obligé de se taper des stripslashes sur tous les tableaux.
Enfin la plupart des serveurs, allons y doucement, si ce serveur te propose une autre base de données que mysqsl c'est qu'on doit pouvoir le paramétrer un strict minimum à son goût quand même non ? Et quand à se faire "tous" les tableaux, personnellement je n'en vois qu'un seul : $_REQUEST. Et de plus il suffit de faire ça dans sa fonction de filtrage et on a trois lignes de code à écrire.
Donc que le comportement par défaut de php ne convienne pas à tes besoins, soit, mais n'exagère quand même pas l'impact que ça peut avoir sur les développements.
a++ JG
Nicolas Krebs
Bonjour,
john gallet écrivit dans l'article news:
Re,
SQLite par exemple (qui devrait devenir très populaire à partir de php5) Ah bon ?
Peut être la personne à qui vous répondez pense à ce que j'ai cité dans news:bngnte$c7b$ .
Bonjour,
john gallet écrivit dans l'article news:4014E5FE.4FC5E78E@wanadoo.fr
Re,
SQLite par exemple (qui devrait devenir très populaire à partir de php5)
Ah bon ?
Peut être la personne à qui vous répondez pense à ce que j'ai cité dans
news:bngnte$c7b$1@news-reader1.wanadoo.fr .
SQLite par exemple (qui devrait devenir très populaire à partir de php5) Ah bon ?
Peut être la personne à qui vous répondez pense à ce que j'ai cité dans news:bngnte$c7b$ .
John Gallet
SQLite par exemple (qui devrait devenir très populaire à partir de php5) Ah bon ?
Peut être la personne à qui vous répondez pense à ce que j'ai cité dans
news:bngnte$c7b$ .
En effet, je comprends mieux le sens de la remarque. Et ne connaissant absolument rien à sqllite, je vais commencer par me renseigner mais je sens les emmerdements arriver... On a pas finit de refuser des articles sur ce suejt pour les renvoyer sur fcas, j'vous l'dis moi...
a++ JG
SQLite par exemple (qui devrait devenir très populaire à partir de php5)
Ah bon ?
Peut être la personne à qui vous répondez pense à ce que j'ai cité dans
news:bngnte$c7b$1@news-reader1.wanadoo.fr .
En effet, je comprends mieux le sens de la remarque. Et ne connaissant
absolument rien à sqllite, je vais commencer par me renseigner mais je
sens les emmerdements arriver... On a pas finit de refuser des articles
sur ce suejt pour les renvoyer sur fcas, j'vous l'dis moi...
SQLite par exemple (qui devrait devenir très populaire à partir de php5) Ah bon ?
Peut être la personne à qui vous répondez pense à ce que j'ai cité dans
news:bngnte$c7b$ .
En effet, je comprends mieux le sens de la remarque. Et ne connaissant absolument rien à sqllite, je vais commencer par me renseigner mais je sens les emmerdements arriver... On a pas finit de refuser des articles sur ce suejt pour les renvoyer sur fcas, j'vous l'dis moi...
a++ JG
Nicolas Krebs
Bonjour,
John Gallet écrivit dans l'article news: dans news:fr.comp.lang.php :
En effet, je comprends mieux le sens de la remarque. Et ne connaissant absolument rien à sqllite, je vais commencer par me renseigner mais je sens les emmerdements arriver... On a pas finit de refuser des articles sur ce suejt pour les renvoyer sur fcas, j'vous l'dis moi...
Ne vous inquiétez pas. Il suffit de faire comme dans les autres forums modérés de la hiérarchie de second niveau fr.comp.*. Heu... Comment font-ils, dans les forums modérés de fr.comp.* ?
John Gallet écrivit dans l'article news:401685E5.57A9E800@wanadoo.fr
dans news:fr.comp.lang.php :
En effet, je comprends mieux le sens de la remarque. Et ne connaissant
absolument rien à sqllite, je vais commencer par me renseigner mais je
sens les emmerdements arriver... On a pas finit de refuser des articles
sur ce suejt pour les renvoyer sur fcas, j'vous l'dis moi...
Ne vous inquiétez pas. Il suffit de faire comme dans les autres forums
modérés de la hiérarchie de second niveau fr.comp.*.
Heu...
Comment font-ils, dans les forums modérés de fr.comp.* ?
John Gallet écrivit dans l'article news: dans news:fr.comp.lang.php :
En effet, je comprends mieux le sens de la remarque. Et ne connaissant absolument rien à sqllite, je vais commencer par me renseigner mais je sens les emmerdements arriver... On a pas finit de refuser des articles sur ce suejt pour les renvoyer sur fcas, j'vous l'dis moi...
Ne vous inquiétez pas. Il suffit de faire comme dans les autres forums modérés de la hiérarchie de second niveau fr.comp.*. Heu... Comment font-ils, dans les forums modérés de fr.comp.* ?
