// connection à la DB NE PAS MODIFIER !
////////////////////////////////////////////////////////////////////////////
/////////////////
// $link = mysql_connect ($host,$user,$pass) or die ('Erreur :
'.mysql_error() ); ////
// mysql_select_db($db) or die ('Erreur :'.mysql_error());
echo "<a href='session3.php'><br>passer à la page suivante";
Regarde dans ton php.ini que les cookies de session sont activés
; Whether to use cookies. session.use_cookies = 1
Ensuite, vérifies que ton navigateur accepte les cookies (au moins pour ce site)
Sinon, ton code devrait marcher. En revanche, c'est pas top de mettre la chaine de connexion à la base de données en session (y compris le mot de passe). Tu ferais mieux de faire un fichier et de l'inclure par un include au début de chaque fichier.
Les sessions sont faite pour conserver des données propres à la session (ca parait évident comme ça !). Or ta chaine de connexion à la base de données est propre au serveur.
Regarde dans ton php.ini que les cookies de session sont activés
; Whether to use cookies.
session.use_cookies = 1
Ensuite, vérifies que ton navigateur accepte les cookies (au moins
pour ce site)
Sinon, ton code devrait marcher. En revanche, c'est pas top de mettre
la chaine de connexion à la base de données en session (y compris le
mot de passe). Tu ferais mieux de faire un fichier et de l'inclure par
un include au début de chaque fichier.
Les sessions sont faite pour conserver des données propres à la
session (ca parait évident comme ça !). Or ta chaine de connexion à
la base de données est propre au serveur.
Regarde dans ton php.ini que les cookies de session sont activés
; Whether to use cookies. session.use_cookies = 1
Ensuite, vérifies que ton navigateur accepte les cookies (au moins pour ce site)
Sinon, ton code devrait marcher. En revanche, c'est pas top de mettre la chaine de connexion à la base de données en session (y compris le mot de passe). Tu ferais mieux de faire un fichier et de l'inclure par un include au début de chaque fichier.
Les sessions sont faite pour conserver des données propres à la session (ca parait évident comme ça !). Or ta chaine de connexion à la base de données est propre au serveur.
Shewy80
voilà ayé ça marche ! un grand merci à toi. En effet IE accepte pas les cookies
par contre tu peux m'expliquer plus précisement comment faire ma connexion alors si ce n'est pas dans les pages ?
JE dois gérer plusieurs utilisateurs par la suite.
"" a écrit dans le message de news:
Regarde dans ton php.ini que les cookies de session sont activés
; Whether to use cookies. session.use_cookies = 1
Ensuite, vérifies que ton navigateur accepte les cookies (au moins pour ce site)
Sinon, ton code devrait marcher. En revanche, c'est pas top de mettre la chaine de connexion à la base de données en session (y compris le mot de passe). Tu ferais mieux de faire un fichier et de l'inclure par un include au début de chaque fichier.
Les sessions sont faite pour conserver des données propres à la session (ca parait évident comme ça !). Or ta chaine de connexion à la base de données est propre au serveur.
voilà ayé ça marche !
un grand merci à toi. En effet IE accepte pas les cookies
par contre tu peux m'expliquer plus précisement comment faire ma connexion
alors si ce n'est pas dans les pages ?
JE dois gérer plusieurs utilisateurs par la suite.
"dmetzler@myaccountingmail.com" <dmetzler@gmail.com> a écrit dans le message
de news:1108742232.013876.96990@f14g2000cwb.googlegroups.com...
Regarde dans ton php.ini que les cookies de session sont activés
; Whether to use cookies.
session.use_cookies = 1
Ensuite, vérifies que ton navigateur accepte les cookies (au moins
pour ce site)
Sinon, ton code devrait marcher. En revanche, c'est pas top de mettre
la chaine de connexion à la base de données en session (y compris le
mot de passe). Tu ferais mieux de faire un fichier et de l'inclure par
un include au début de chaque fichier.
Les sessions sont faite pour conserver des données propres à la
session (ca parait évident comme ça !). Or ta chaine de connexion à
la base de données est propre au serveur.
voilà ayé ça marche ! un grand merci à toi. En effet IE accepte pas les cookies
par contre tu peux m'expliquer plus précisement comment faire ma connexion alors si ce n'est pas dans les pages ?
JE dois gérer plusieurs utilisateurs par la suite.
"" a écrit dans le message de news:
Regarde dans ton php.ini que les cookies de session sont activés
; Whether to use cookies. session.use_cookies = 1
Ensuite, vérifies que ton navigateur accepte les cookies (au moins pour ce site)
Sinon, ton code devrait marcher. En revanche, c'est pas top de mettre la chaine de connexion à la base de données en session (y compris le mot de passe). Tu ferais mieux de faire un fichier et de l'inclure par un include au début de chaque fichier.
Les sessions sont faite pour conserver des données propres à la session (ca parait évident comme ça !). Or ta chaine de connexion à la base de données est propre au serveur.
Michael Alves
voilà ayé ça marche ! un grand merci à toi. En effet IE accepte pas les cookies
par contre tu peux m'expliquer plus précisement comment faire ma connexion alors si ce n'est pas dans les pages ?
JE dois gérer plusieurs utilisateurs par la suite.
Dans un config.db.inc par exemple, tu définis des constantes :
Puis, dans chaque page tu inclus ton config.db.inc :
require "config.db.inc" ;
John GALLET
require "config.db.inc" ;
YES !! Cracker's Paraside is back ! http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans. --> config.php
a++; JG
require "config.db.inc" ;
YES !! Cracker's Paraside is back !
http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un
fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP,
surtout s'il y a des données confidentielles dedans.
--> config.php
YES !! Cracker's Paraside is back ! http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans. --> config.php
a++; JG
FAb
John GALLET writes:
require "config.db.inc" ;
YES !! Cracker's Paraside is back ! http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans. --> config.php
config.inc.php ?
Et pis DBconnector.class.php ?
FAb
John GALLET <john.gallet@wanadoo.fr> writes:
require "config.db.inc" ;
YES !! Cracker's Paraside is back !
http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un
fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP,
surtout s'il y a des données confidentielles dedans.
--> config.php
YES !! Cracker's Paraside is back ! http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans. --> config.php
config.inc.php ?
Et pis DBconnector.class.php ?
FAb
Sebastian 'CrashandDie' Lauwers
John GALLET wrote:
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans.
Je suis d'accord, le simple .inc n'est pas suffisant, et complètement con... Autant les sauvegarder en .txt...
--> config.php
Parcontre, j'aime bien utiliser les machin.inc.php ... C'est sans doute parceque je suis un mauvais codeur php, mais j'ai cependant l'impression que cela permet une plus grande clareté.
De telle manière, je sais que je dois empêche un .inc.php d'être ouvert par autrechose que un script du server. On ne peut pas y accéder par un navigateur en tappant l'adresse:
<http://www.monserver.com/monscript.inc.php>
Tout simplement, parceque à chaque .inc.php je rajoute un petit
if (!defined ('MACONSTANTE') OR constant ('MACONSTANTE') != 'purée à la fraise') die ('Hahaha, owned');
Même si c'est un fichier de configuration où l'on ne fait que de la déclaration de variables (par exemple pour la connexion au server sql, ou autre), il n'est pas nécessaire d'utiliser une telle chose puisque la déclaration de variable ne montre rien au client.
Enfin, si t'as quelquechose à dire, je serai heureux d'être éduqué (non, pas la ceinture ;).
a++;
Best regards,
JG
S.
John GALLET wrote:
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un
fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP,
surtout s'il y a des données confidentielles dedans.
Je suis d'accord, le simple .inc n'est pas suffisant, et complètement
con... Autant les sauvegarder en .txt...
--> config.php
Parcontre, j'aime bien utiliser les machin.inc.php ... C'est sans doute
parceque je suis un mauvais codeur php, mais j'ai cependant l'impression
que cela permet une plus grande clareté.
De telle manière, je sais que je dois empêche un .inc.php d'être ouvert
par autrechose que un script du server. On ne peut pas y accéder par un
navigateur en tappant l'adresse:
<http://www.monserver.com/monscript.inc.php>
Tout simplement, parceque à chaque .inc.php je rajoute un petit
if (!defined ('MACONSTANTE') OR constant ('MACONSTANTE') != 'purée à la
fraise')
die ('Hahaha, owned');
Même si c'est un fichier de configuration où l'on ne fait que de la
déclaration de variables (par exemple pour la connexion au server sql,
ou autre), il n'est pas nécessaire d'utiliser une telle chose puisque la
déclaration de variable ne montre rien au client.
Enfin, si t'as quelquechose à dire, je serai heureux d'être éduqué (non,
pas la ceinture ;).
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans.
Je suis d'accord, le simple .inc n'est pas suffisant, et complètement con... Autant les sauvegarder en .txt...
--> config.php
Parcontre, j'aime bien utiliser les machin.inc.php ... C'est sans doute parceque je suis un mauvais codeur php, mais j'ai cependant l'impression que cela permet une plus grande clareté.
De telle manière, je sais que je dois empêche un .inc.php d'être ouvert par autrechose que un script du server. On ne peut pas y accéder par un navigateur en tappant l'adresse:
<http://www.monserver.com/monscript.inc.php>
Tout simplement, parceque à chaque .inc.php je rajoute un petit
if (!defined ('MACONSTANTE') OR constant ('MACONSTANTE') != 'purée à la fraise') die ('Hahaha, owned');
Même si c'est un fichier de configuration où l'on ne fait que de la déclaration de variables (par exemple pour la connexion au server sql, ou autre), il n'est pas nécessaire d'utiliser une telle chose puisque la déclaration de variable ne montre rien au client.
Enfin, si t'as quelquechose à dire, je serai heureux d'être éduqué (non, pas la ceinture ;).
a++;
Best regards,
JG
S.
Michael Alves
require "config.db.inc" ;
YES !! Cracker's Paraside is back ! http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans. --> config.php
Hum, c'était à titre d'exemple. J'ai pour habitude de les mettre dans un dossier protégé par un .htaccess, après si c'est le moyen le plus propre ou pas je ne sais pas en tout cas je répond A LA QUESTION QU'IL POSE. (il me semble o_O)
require "config.db.inc" ;
YES !! Cracker's Paraside is back !
http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un
fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP,
surtout s'il y a des données confidentielles dedans.
--> config.php
Hum, c'était à titre d'exemple. J'ai pour habitude de les mettre dans
un dossier protégé par un .htaccess, après si c'est le moyen le plus
propre ou pas je ne sais pas en tout cas je répond A LA QUESTION QU'IL
POSE. (il me semble o_O)
YES !! Cracker's Paraside is back ! http://lesite.com/config.db.inc et à moi les mots de passe en clair !
Arretez ces CONNERIES de ".inc" partour, ON S'EN BRANLE que ce soit un fichier inclus, ce qui est important, c'est une extension PARSEE PAR PHP, surtout s'il y a des données confidentielles dedans. --> config.php
Hum, c'était à titre d'exemple. J'ai pour habitude de les mettre dans un dossier protégé par un .htaccess, après si c'est le moyen le plus propre ou pas je ne sais pas en tout cas je répond A LA QUESTION QU'IL POSE. (il me semble o_O)
John Gallet
Bonjour,
Parcontre, j'aime bien utiliser les machin.inc.php ... C'est sans doute parceque je suis un mauvais codeur php, mais j'ai cependant l'impression que cela permet une plus grande clareté.
Tout à fait, les conventions de nommage, tant des variables que des fichiers, apportent de la facilité de lecture. Enfin, essaient de... Maintenant je te donne un exemple de construction classique : j'ai un seul fichier "public", index.php, et je fais un switch selon la variable $action (attention pour les neu² qui traînent, j'ai PAS DIT require($action), SURTOUT PAS). Donc à part index.php, ***TOUS*** mes fichiers sont appelés par require. A QUOI ça sert que je rajoute ".inc." dans leur nom ?
De telle manière, je sais que je dois empêche un .inc.php d'être ouvert par autrechose que un script du server. On ne peut pas y accéder par un navigateur en tappant l'adresse: <http://www.monserver.com/monscript.inc.php> Tout simplement, parceque à chaque .inc.php je rajoute un petit if (!defined ('MACONSTANTE') OR constant ('MACONSTANTE') != 'purée à la fraise') die ('Hahaha, owned');
Si cette convention de nommage te permet de te souvenir que ce sont des fichiers "privés" (qui donc, sur le fond, devraient carrément être **en dehors** de DOCUMENT_ROOT) alors n'hésite pas à l'utiliser. Toute convention de nommage n'a d'utilité qu'humaine. Moi j'ai d'autres conventions de nommage qui me permettent aussi de savoir instantanément si c'est un fichier public ou privé, mais en effet, pourquoi pas celle-ci, mais il faudrait que ce soit explicite alors, je sais pas moi, config.priv.php ou config.priv_inc.php car .inc. ne fait pas penser à "fichier non public" mais à "fichier appelé par require qq part".
Sur le fond, il faudrait : - mettre tous ces fichiers "privés" dans un (sous) répertoire (en ajoutant un index.html vide). - y coller un .htacess <DENY FROM ALL> pour être peinard sous apache - faire le test sur une constante que tu décris pour rester compatibles en termes de sécurité hors apache, dans tous les fichiers qui ne sont pas des librairies (perso, je ne mélange jamais les librairies qui définissent des fonctions et constantes des fichiers qui exécutent réellement du code).
Même si c'est un fichier de configuration où l'on ne fait que de la déclaration de variables (par exemple pour la connexion au server sql, ou autre), il n'est pas nécessaire d'utiliser une telle chose puisque la déclaration de variable ne montre rien au client.
Toutafé, ce qui définit d'un côté, ce qui exécute ailleurs. Là en effet, il n'est pas "utile" de faire la vérif sur la constante définie (au sens, ça prend une ligne de code <?php if(!defined("MACONSTANTE")) exit(); ?> mais si on la mettait pas, on ne risquerait rien, enfin pour le moment).
a++; JG
Bonjour,
Parcontre, j'aime bien utiliser les machin.inc.php ... C'est sans doute
parceque je suis un mauvais codeur php, mais j'ai cependant l'impression
que cela permet une plus grande clareté.
Tout à fait, les conventions de nommage, tant des variables que des
fichiers, apportent de la facilité de lecture. Enfin, essaient de...
Maintenant je te donne un exemple de construction classique : j'ai un
seul fichier "public", index.php, et je fais un switch selon la variable
$action (attention pour les neu² qui traînent, j'ai PAS DIT
require($action), SURTOUT PAS). Donc à part index.php, ***TOUS*** mes
fichiers sont appelés par require. A QUOI ça sert que je rajoute ".inc."
dans leur nom ?
De telle manière, je sais que je dois empêche un .inc.php d'être ouvert
par autrechose que un script du server. On ne peut pas y accéder par un
navigateur en tappant l'adresse:
<http://www.monserver.com/monscript.inc.php>
Tout simplement, parceque à chaque .inc.php je rajoute un petit
if (!defined ('MACONSTANTE') OR constant ('MACONSTANTE') != 'purée à la
fraise')
die ('Hahaha, owned');
Si cette convention de nommage te permet de te souvenir que ce sont des
fichiers "privés" (qui donc, sur le fond, devraient carrément être **en
dehors** de DOCUMENT_ROOT) alors n'hésite pas à l'utiliser. Toute
convention de nommage n'a d'utilité qu'humaine. Moi j'ai d'autres
conventions de nommage qui me permettent aussi de savoir instantanément
si c'est un fichier public ou privé, mais en effet, pourquoi pas
celle-ci, mais il faudrait que ce soit explicite alors, je sais pas moi,
config.priv.php ou config.priv_inc.php car .inc. ne fait pas penser à
"fichier non public" mais à "fichier appelé par require qq part".
Sur le fond, il faudrait :
- mettre tous ces fichiers "privés" dans un (sous) répertoire (en
ajoutant un index.html vide).
- y coller un .htacess <DENY FROM ALL> pour être peinard sous apache
- faire le test sur une constante que tu décris pour rester compatibles
en termes de sécurité hors apache, dans tous les fichiers qui ne sont
pas des librairies (perso, je ne mélange jamais les librairies qui
définissent des fonctions et constantes des fichiers qui exécutent
réellement du code).
Même si c'est un fichier de configuration où l'on ne fait que de la
déclaration de variables (par exemple pour la connexion au server sql,
ou autre), il n'est pas nécessaire d'utiliser une telle chose puisque la
déclaration de variable ne montre rien au client.
Toutafé, ce qui définit d'un côté, ce qui exécute ailleurs. Là en effet,
il n'est pas "utile" de faire la vérif sur la constante définie (au
sens, ça prend une ligne de code <?php if(!defined("MACONSTANTE"))
exit(); ?> mais si on la mettait pas, on ne risquerait rien, enfin pour
le moment).
Parcontre, j'aime bien utiliser les machin.inc.php ... C'est sans doute parceque je suis un mauvais codeur php, mais j'ai cependant l'impression que cela permet une plus grande clareté.
Tout à fait, les conventions de nommage, tant des variables que des fichiers, apportent de la facilité de lecture. Enfin, essaient de... Maintenant je te donne un exemple de construction classique : j'ai un seul fichier "public", index.php, et je fais un switch selon la variable $action (attention pour les neu² qui traînent, j'ai PAS DIT require($action), SURTOUT PAS). Donc à part index.php, ***TOUS*** mes fichiers sont appelés par require. A QUOI ça sert que je rajoute ".inc." dans leur nom ?
De telle manière, je sais que je dois empêche un .inc.php d'être ouvert par autrechose que un script du server. On ne peut pas y accéder par un navigateur en tappant l'adresse: <http://www.monserver.com/monscript.inc.php> Tout simplement, parceque à chaque .inc.php je rajoute un petit if (!defined ('MACONSTANTE') OR constant ('MACONSTANTE') != 'purée à la fraise') die ('Hahaha, owned');
Si cette convention de nommage te permet de te souvenir que ce sont des fichiers "privés" (qui donc, sur le fond, devraient carrément être **en dehors** de DOCUMENT_ROOT) alors n'hésite pas à l'utiliser. Toute convention de nommage n'a d'utilité qu'humaine. Moi j'ai d'autres conventions de nommage qui me permettent aussi de savoir instantanément si c'est un fichier public ou privé, mais en effet, pourquoi pas celle-ci, mais il faudrait que ce soit explicite alors, je sais pas moi, config.priv.php ou config.priv_inc.php car .inc. ne fait pas penser à "fichier non public" mais à "fichier appelé par require qq part".
Sur le fond, il faudrait : - mettre tous ces fichiers "privés" dans un (sous) répertoire (en ajoutant un index.html vide). - y coller un .htacess <DENY FROM ALL> pour être peinard sous apache - faire le test sur une constante que tu décris pour rester compatibles en termes de sécurité hors apache, dans tous les fichiers qui ne sont pas des librairies (perso, je ne mélange jamais les librairies qui définissent des fonctions et constantes des fichiers qui exécutent réellement du code).
Même si c'est un fichier de configuration où l'on ne fait que de la déclaration de variables (par exemple pour la connexion au server sql, ou autre), il n'est pas nécessaire d'utiliser une telle chose puisque la déclaration de variable ne montre rien au client.
Toutafé, ce qui définit d'un côté, ce qui exécute ailleurs. Là en effet, il n'est pas "utile" de faire la vérif sur la constante définie (au sens, ça prend une ligne de code <?php if(!defined("MACONSTANTE")) exit(); ?> mais si on la mettait pas, on ne risquerait rien, enfin pour le moment).
a++; JG
Sebastian 'CrashandDie' Lauwers
John Gallet wrote:
Bonjour,
Re,
Tout à fait, les conventions de nommage, tant des variables que des fichiers, apportent de la facilité de lecture. Enfin, essaient de... Maintenant je te donne un exemple de construction classique : j'ai un seul fichier "public", index.php, et je fais un switch selon la variable $action (attention pour les neu² qui traînent, j'ai PAS DIT require($action), SURTOUT PAS). Donc à part index.php, ***TOUS*** mes fichiers sont appelés par require. A QUOI ça sert que je rajoute ".inc." dans leur nom ?
Je récapitule:
- Le fait de rajouter .inc. dans le nom, ou tout autre notation n'est pas nécessaire, elle est juste utile, pour certains codeurs. Passer outre n'est qu'une question de choix ou de religion personnelle.
Si cette convention de nommage te permet de te souvenir que ce sont des fichiers "privés" (qui donc, sur le fond, devraient carrément être **en dehors** de DOCUMENT_ROOT) alors n'hésite pas à l'utiliser. Toute convention de nommage n'a d'utilité qu'humaine. Moi j'ai d'autres conventions de nommage qui me permettent aussi de savoir instantanément si c'est un fichier public ou privé, mais en effet, pourquoi pas celle-ci, mais il faudrait que ce soit explicite alors, je sais pas moi, config.priv.php ou config.priv_inc.php car .inc. ne fait pas penser à "fichier non public" mais à "fichier appelé par require qq part".
Sur le fond, il faudrait : - mettre tous ces fichiers "privés" dans un (sous) répertoire (en ajoutant un index.html vide). - y coller un .htacess <DENY FROM ALL> pour être peinard sous apache - faire le test sur une constante que tu décris pour rester compatibles en termes de sécurité hors apache, dans tous les fichiers qui ne sont pas des librairies (perso, je ne mélange jamais les librairies qui définissent des fonctions et constantes des fichiers qui exécutent réellement du code).
Perso, je n'ai pas encore eu d'expériences professionelles suffisantent pour me permettre de travailler sur un serveur de production sur lequel j'ai un accès *plus* complèt. Pour ainsi dire, les seuls serveurs autres que mon mien sur ma box cachée au fond de mon cercueil, je n'ai travaillé que sur free. Mettre des fichiers hors du DOCUMENT_ROOT m'est donc un peu plus difficile. La technique du dossier qui contient les scripts appellés par require (), je l'utilise régulièrement, le index.htm vide je l'utilise depuis que j'utilise des ftp pour éviter les dossiers "ouverts", et le .htaccess, je l'utilise régulièrement, pas systématiquement, loin de là, uniquement quand l'utilité s'en fait ressentir. Erreurs, sans doute, manque de pratique, nul doute.
J'ai la grande chance (lisez: trop petite expérience?) de n'avoir pas travaillé sur des projets assés importants pour nécessiter une sécurité draconnienne, et mes collaborateurs m'ont souvents épargnés ces problèmes pour me laisser me détruire mes 3 neurones sur l'algorythmie (mmorpg).
[...]
a++; JG
S.
John Gallet wrote:
Bonjour,
Re,
Tout à fait, les conventions de nommage, tant des variables que des
fichiers, apportent de la facilité de lecture. Enfin, essaient de...
Maintenant je te donne un exemple de construction classique : j'ai un
seul fichier "public", index.php, et je fais un switch selon la variable
$action (attention pour les neu² qui traînent, j'ai PAS DIT
require($action), SURTOUT PAS). Donc à part index.php, ***TOUS*** mes
fichiers sont appelés par require. A QUOI ça sert que je rajoute ".inc."
dans leur nom ?
Je récapitule:
- Le fait de rajouter .inc. dans le nom, ou tout autre notation n'est
pas nécessaire, elle est juste utile, pour certains codeurs. Passer
outre n'est qu'une question de choix ou de religion personnelle.
Si cette convention de nommage te permet de te souvenir que ce sont des
fichiers "privés" (qui donc, sur le fond, devraient carrément être **en
dehors** de DOCUMENT_ROOT) alors n'hésite pas à l'utiliser. Toute
convention de nommage n'a d'utilité qu'humaine. Moi j'ai d'autres
conventions de nommage qui me permettent aussi de savoir instantanément
si c'est un fichier public ou privé, mais en effet, pourquoi pas
celle-ci, mais il faudrait que ce soit explicite alors, je sais pas moi,
config.priv.php ou config.priv_inc.php car .inc. ne fait pas penser à
"fichier non public" mais à "fichier appelé par require qq part".
Sur le fond, il faudrait :
- mettre tous ces fichiers "privés" dans un (sous) répertoire (en
ajoutant un index.html vide).
- y coller un .htacess <DENY FROM ALL> pour être peinard sous apache
- faire le test sur une constante que tu décris pour rester compatibles
en termes de sécurité hors apache, dans tous les fichiers qui ne sont
pas des librairies (perso, je ne mélange jamais les librairies qui
définissent des fonctions et constantes des fichiers qui exécutent
réellement du code).
Perso, je n'ai pas encore eu d'expériences professionelles suffisantent
pour me permettre de travailler sur un serveur de production sur lequel
j'ai un accès *plus* complèt. Pour ainsi dire, les seuls serveurs autres
que mon mien sur ma box cachée au fond de mon cercueil, je n'ai
travaillé que sur free. Mettre des fichiers hors du DOCUMENT_ROOT m'est
donc un peu plus difficile. La technique du dossier qui contient les
scripts appellés par require (), je l'utilise régulièrement, le
index.htm vide je l'utilise depuis que j'utilise des ftp pour éviter les
dossiers "ouverts", et le .htaccess, je l'utilise régulièrement, pas
systématiquement, loin de là, uniquement quand l'utilité s'en fait
ressentir. Erreurs, sans doute, manque de pratique, nul doute.
J'ai la grande chance (lisez: trop petite expérience?) de n'avoir pas
travaillé sur des projets assés importants pour nécessiter une sécurité
draconnienne, et mes collaborateurs m'ont souvents épargnés ces
problèmes pour me laisser me détruire mes 3 neurones sur l'algorythmie
(mmorpg).
Tout à fait, les conventions de nommage, tant des variables que des fichiers, apportent de la facilité de lecture. Enfin, essaient de... Maintenant je te donne un exemple de construction classique : j'ai un seul fichier "public", index.php, et je fais un switch selon la variable $action (attention pour les neu² qui traînent, j'ai PAS DIT require($action), SURTOUT PAS). Donc à part index.php, ***TOUS*** mes fichiers sont appelés par require. A QUOI ça sert que je rajoute ".inc." dans leur nom ?
Je récapitule:
- Le fait de rajouter .inc. dans le nom, ou tout autre notation n'est pas nécessaire, elle est juste utile, pour certains codeurs. Passer outre n'est qu'une question de choix ou de religion personnelle.
Si cette convention de nommage te permet de te souvenir que ce sont des fichiers "privés" (qui donc, sur le fond, devraient carrément être **en dehors** de DOCUMENT_ROOT) alors n'hésite pas à l'utiliser. Toute convention de nommage n'a d'utilité qu'humaine. Moi j'ai d'autres conventions de nommage qui me permettent aussi de savoir instantanément si c'est un fichier public ou privé, mais en effet, pourquoi pas celle-ci, mais il faudrait que ce soit explicite alors, je sais pas moi, config.priv.php ou config.priv_inc.php car .inc. ne fait pas penser à "fichier non public" mais à "fichier appelé par require qq part".
Sur le fond, il faudrait : - mettre tous ces fichiers "privés" dans un (sous) répertoire (en ajoutant un index.html vide). - y coller un .htacess <DENY FROM ALL> pour être peinard sous apache - faire le test sur une constante que tu décris pour rester compatibles en termes de sécurité hors apache, dans tous les fichiers qui ne sont pas des librairies (perso, je ne mélange jamais les librairies qui définissent des fonctions et constantes des fichiers qui exécutent réellement du code).
Perso, je n'ai pas encore eu d'expériences professionelles suffisantent pour me permettre de travailler sur un serveur de production sur lequel j'ai un accès *plus* complèt. Pour ainsi dire, les seuls serveurs autres que mon mien sur ma box cachée au fond de mon cercueil, je n'ai travaillé que sur free. Mettre des fichiers hors du DOCUMENT_ROOT m'est donc un peu plus difficile. La technique du dossier qui contient les scripts appellés par require (), je l'utilise régulièrement, le index.htm vide je l'utilise depuis que j'utilise des ftp pour éviter les dossiers "ouverts", et le .htaccess, je l'utilise régulièrement, pas systématiquement, loin de là, uniquement quand l'utilité s'en fait ressentir. Erreurs, sans doute, manque de pratique, nul doute.
J'ai la grande chance (lisez: trop petite expérience?) de n'avoir pas travaillé sur des projets assés importants pour nécessiter une sécurité draconnienne, et mes collaborateurs m'ont souvents épargnés ces problèmes pour me laisser me détruire mes 3 neurones sur l'algorythmie (mmorpg).
[...]
a++; JG
S.
John GALLET
Je récapitule: - Le fait de rajouter .inc. dans le nom, ou tout autre notation n'est pas nécessaire, elle est juste utile, pour certains codeurs. Passer outre n'est qu'une question de choix ou de religion personnelle. Excellente synthèse, j'aime bien la "religion", c'est à peu près ça,
j'ajouterais donc que dans certains cas, des gourous autoproclamés qui pnt rarement codé plus de 10 lignes dans les 10 derniers mois tentent et sont payés pour imposer aux dévelopeurs leurs conventions de nommage ça s'appelle des "responsables qualité", ça cause "merise" ou "uml", "modélisation", "N-tiers", "TCO", etc... Blague à part, si on arive dans une équipe de dev qui possède déjà des normes de nommage, il faut les respecter, même si on pense qu'elles sont débiles^W améliorables.
J'ai la grande chance (lisez: trop petite expérience?) de n'avoir pas travaillé sur des projets assés importants pour nécessiter une sécurité draconnienne, et mes collaborateurs m'ont souvents épargnés ces problèmes pour me laisser me détruire mes 3 neurones sur l'algorythmie (mmorpg). Faut bien commencer qq part, et surtout, glaner de l'expérience auprès
des autres en gardant un esprit critique.
a++; JG
Je récapitule:
- Le fait de rajouter .inc. dans le nom, ou tout autre notation n'est
pas nécessaire, elle est juste utile, pour certains codeurs. Passer
outre n'est qu'une question de choix ou de religion personnelle.
Excellente synthèse, j'aime bien la "religion", c'est à peu près ça,
j'ajouterais donc que dans certains cas, des gourous autoproclamés qui pnt
rarement codé plus de 10 lignes dans les 10 derniers mois tentent et sont
payés pour imposer aux dévelopeurs leurs conventions de nommage ça
s'appelle des "responsables qualité", ça cause "merise" ou "uml",
"modélisation", "N-tiers", "TCO", etc...
Blague à part, si on arive dans une équipe de dev qui possède déjà des
normes de nommage, il faut les respecter, même si on pense qu'elles sont
débiles^W améliorables.
J'ai la grande chance (lisez: trop petite expérience?) de n'avoir pas
travaillé sur des projets assés importants pour nécessiter une sécurité
draconnienne, et mes collaborateurs m'ont souvents épargnés ces
problèmes pour me laisser me détruire mes 3 neurones sur l'algorythmie
(mmorpg).
Faut bien commencer qq part, et surtout, glaner de l'expérience auprès
Je récapitule: - Le fait de rajouter .inc. dans le nom, ou tout autre notation n'est pas nécessaire, elle est juste utile, pour certains codeurs. Passer outre n'est qu'une question de choix ou de religion personnelle. Excellente synthèse, j'aime bien la "religion", c'est à peu près ça,
j'ajouterais donc que dans certains cas, des gourous autoproclamés qui pnt rarement codé plus de 10 lignes dans les 10 derniers mois tentent et sont payés pour imposer aux dévelopeurs leurs conventions de nommage ça s'appelle des "responsables qualité", ça cause "merise" ou "uml", "modélisation", "N-tiers", "TCO", etc... Blague à part, si on arive dans une équipe de dev qui possède déjà des normes de nommage, il faut les respecter, même si on pense qu'elles sont débiles^W améliorables.
J'ai la grande chance (lisez: trop petite expérience?) de n'avoir pas travaillé sur des projets assés importants pour nécessiter une sécurité draconnienne, et mes collaborateurs m'ont souvents épargnés ces problèmes pour me laisser me détruire mes 3 neurones sur l'algorythmie (mmorpg). Faut bien commencer qq part, et surtout, glaner de l'expérience auprès
