Fatal error, qu'il dit... Je teste mes programmes (PHP5) et je me retrouve
de temps en temps avec le message d'erreur suivant :
Fatal error: Cannot redeclare add_url() (previously declared in
/home/lgv/www/valinfotest/func.php:4) in /home/lgv/www/valinfotest/func.php
on line 7
Explication : func.php est un programme qui contient toutes les fonctions
utiles au fonctionnement du site. On l'appelle systématiquement par un
include en début de programme, qu'on ait besoin ou non des fonctions en
question.
add_url() est tout bêtement la première fonction de la liste. Si on
l'enlève, c'est la deuxième qui ressort dans le message d'erreur.
Le truc bizarre, c'est que ce problème se produit... de temps en temps,
sans que je sache pourquoi ni comment, et qu'il disparaît de même ! Quand
il se produit, tous les programmes qui appellent func.php se plantent. J'ai
essayé de remplacer l'include par un require, cela ne change rien. Changer
de navigateur n'avance à rien non plus.
Les .inc ne sont generalement pas interprétés, ce qui veut dire qu'en cas d'appel direct, ton code sera visible.
Effectivement, mais bof, il n'y a rien de bien confidentiel dans ce code.
Tu n'en sais rien.
Il y a ta manière de programmer.
Le nom de tes variables.
Ta facon d'envisager la sécurité.
Si ca te trouve, il est meme possible, en passant les bon paramètres, de provoquer quelques dégats.
Dans le doute, il vaut mieux que le code reste non visible. Dans le meilleur des monde, un script pourrait meme n'etre appelé que via un controlleur (central ou particulier) qui se chargerait de toutes les vérifications d'usages avant de lancer ou non l'exécution du programme.
Stef
"Pascale" <chaton.tigre+spam@alussinan.org> wrote
Les .inc ne sont generalement pas interprétés, ce qui veut dire qu'en
cas d'appel direct, ton code sera visible.
Effectivement, mais bof, il n'y a rien de bien confidentiel dans ce code.
Tu n'en sais rien.
Il y a ta manière de programmer.
Le nom de tes variables.
Ta facon d'envisager la sécurité.
Si ca te trouve, il est meme possible, en passant les bon paramètres, de
provoquer quelques dégats.
Dans le doute, il vaut mieux que le code reste non visible. Dans le meilleur
des monde, un script pourrait meme n'etre appelé que via un controlleur
(central ou particulier) qui se chargerait de toutes les vérifications
d'usages avant de lancer ou non l'exécution du programme.
Les .inc ne sont generalement pas interprétés, ce qui veut dire qu'en cas d'appel direct, ton code sera visible.
Effectivement, mais bof, il n'y a rien de bien confidentiel dans ce code.
Tu n'en sais rien.
Il y a ta manière de programmer.
Le nom de tes variables.
Ta facon d'envisager la sécurité.
Si ca te trouve, il est meme possible, en passant les bon paramètres, de provoquer quelques dégats.
Dans le doute, il vaut mieux que le code reste non visible. Dans le meilleur des monde, un script pourrait meme n'etre appelé que via un controlleur (central ou particulier) qui se chargerait de toutes les vérifications d'usages avant de lancer ou non l'exécution du programme.
Stef
Denis Beauregard
Le 30 Dec 2008 12:38:34 GMT, Pascale <chaton.tigre+ écrivait dans fr.comp.lang.php:
slambert écrivait news:4957e6c1$0$2004$:
Les .inc ne sont generalement pas interprétés, ce qui veut dire qu'en cas d'appel direct, ton code sera visible.
Effectivement, mais bof, il n'y a rien de bien confidentiel dans ce code.
Il suffit que tu places le mot de passe d'une base de données dans un .inc appelé maladroitement motdepasse.inc ou password.inc et tu viens d'ouvrir ton site à tout le monde. De même, si tu laisses un fichier doc.txt avec tous les paramètres de connexion, quelqu'un peut tomber dessus par hasard. Quand je regarde mon log, je vois de temps en temps des noms de fichiers que je n'ai jamais eus.
Denis
Le 30 Dec 2008 12:38:34 GMT, Pascale <chaton.tigre+spam@alussinan.org>
écrivait dans fr.comp.lang.php:
Les .inc ne sont generalement pas interprétés, ce qui veut dire qu'en
cas d'appel direct, ton code sera visible.
Effectivement, mais bof, il n'y a rien de bien confidentiel dans ce code.
Il suffit que tu places le mot de passe d'une base de données
dans un .inc appelé maladroitement motdepasse.inc ou password.inc
et tu viens d'ouvrir ton site à tout le monde. De même, si tu laisses
un fichier doc.txt avec tous les paramètres de connexion, quelqu'un
peut tomber dessus par hasard. Quand je regarde mon log, je vois de
temps en temps des noms de fichiers que je n'ai jamais eus.
Le 30 Dec 2008 12:38:34 GMT, Pascale <chaton.tigre+ écrivait dans fr.comp.lang.php:
slambert écrivait news:4957e6c1$0$2004$:
Les .inc ne sont generalement pas interprétés, ce qui veut dire qu'en cas d'appel direct, ton code sera visible.
Effectivement, mais bof, il n'y a rien de bien confidentiel dans ce code.
Il suffit que tu places le mot de passe d'une base de données dans un .inc appelé maladroitement motdepasse.inc ou password.inc et tu viens d'ouvrir ton site à tout le monde. De même, si tu laisses un fichier doc.txt avec tous les paramètres de connexion, quelqu'un peut tomber dessus par hasard. Quand je regarde mon log, je vois de temps en temps des noms de fichiers que je n'ai jamais eus.
Denis
Pascale
Denis Beauregard écrivait news::
Il suffit que tu places le mot de passe d'une base de données dans un .inc appelé maladroitement motdepasse.inc ou password.inc et tu viens d'ouvrir ton site à tout le monde.
Merci à slambert et à toi pour les explications. Je n'ai pas de .inc aussi dangereux, mais je vais quand même les remplacer par des .php, par sécurité. Il me semble que dans des versions anciennes de PHP on ne pouvait pas faire d'include xxxxxx.php mais seulement xxxxxx.inc. Non ?
Il suffit que tu places le mot de passe d'une base de données
dans un .inc appelé maladroitement motdepasse.inc ou password.inc
et tu viens d'ouvrir ton site à tout le monde.
Merci à slambert et à toi pour les explications. Je n'ai pas de .inc aussi
dangereux, mais je vais quand même les remplacer par des .php, par
sécurité.
Il me semble que dans des versions anciennes de PHP on ne pouvait pas faire
d'include xxxxxx.php mais seulement xxxxxx.inc. Non ?
Il suffit que tu places le mot de passe d'une base de données dans un .inc appelé maladroitement motdepasse.inc ou password.inc et tu viens d'ouvrir ton site à tout le monde.
Merci à slambert et à toi pour les explications. Je n'ai pas de .inc aussi dangereux, mais je vais quand même les remplacer par des .php, par sécurité. Il me semble que dans des versions anciennes de PHP on ne pouvait pas faire d'include xxxxxx.php mais seulement xxxxxx.inc. Non ?
-- Pascale
Pascal PONCET
Pascale a écrit :
Je n'ai pas de .inc aussi dangereux, mais je vais quand même les remplacer par des .php, par sécurité. Il me semble que dans des versions anciennes de PHP on ne pouvait pas faire d'include xxxxxx.php mais seulement xxxxxx.inc. Non ?
Bonjour,
Peut-être avant la version 3, mais je n'ai jamais vu.
Sinon, il est possible de nommer les fichiers à inclure "xxx.inc.php", comme les classes "xxx.class.php", pour éventuellement plus de clarté. C'est une notation assez fréquente, même si elle est héritée d'autres langages. La sécurité sera toujours assurée puisque, pour le serveur, c'est la dernière extension qui compte.
Cordialement, Pascal
Pascale a écrit :
Je n'ai pas de .inc aussi
dangereux, mais je vais quand même les remplacer par des .php, par
sécurité.
Il me semble que dans des versions anciennes de PHP on ne pouvait pas faire
d'include xxxxxx.php mais seulement xxxxxx.inc. Non ?
Bonjour,
Peut-être avant la version 3, mais je n'ai jamais vu.
Sinon, il est possible de nommer les fichiers à inclure "xxx.inc.php",
comme les classes "xxx.class.php", pour éventuellement plus de clarté.
C'est une notation assez fréquente, même si elle est héritée d'autres
langages.
La sécurité sera toujours assurée puisque, pour le serveur, c'est la
dernière extension qui compte.
Je n'ai pas de .inc aussi dangereux, mais je vais quand même les remplacer par des .php, par sécurité. Il me semble que dans des versions anciennes de PHP on ne pouvait pas faire d'include xxxxxx.php mais seulement xxxxxx.inc. Non ?
Bonjour,
Peut-être avant la version 3, mais je n'ai jamais vu.
Sinon, il est possible de nommer les fichiers à inclure "xxx.inc.php", comme les classes "xxx.class.php", pour éventuellement plus de clarté. C'est une notation assez fréquente, même si elle est héritée d'autres langages. La sécurité sera toujours assurée puisque, pour le serveur, c'est la dernière extension qui compte.
Cordialement, Pascal
Mickael Wolff
> Merci à slambert et à toi pour les explications. Je n'ai pas de .inc aussi dangereux, mais je vais quand même les remplacer par des .php, par sécurité.
Attention, le remède peut être pire que le mal. Si en .inc ils sont lisibles en clair, en .php ils sont exécutables. Et si tu n'as pas mis de garde fous, le comportement peut être indéterminé.
Le mieux, c'est de reléguer les fichiers inclus dans un répertoire inaccessible via HTTP, mais tout de même accessibles par le script PHP.
>
Merci à slambert et à toi pour les explications. Je n'ai pas de .inc aussi
dangereux, mais je vais quand même les remplacer par des .php, par
sécurité.
Attention, le remède peut être pire que le mal. Si en .inc ils sont
lisibles en clair, en .php ils sont exécutables. Et si tu n'as pas mis
de garde fous, le comportement peut être indéterminé.
Le mieux, c'est de reléguer les fichiers inclus dans un répertoire
inaccessible via HTTP, mais tout de même accessibles par le script PHP.
> Merci à slambert et à toi pour les explications. Je n'ai pas de .inc aussi dangereux, mais je vais quand même les remplacer par des .php, par sécurité.
Attention, le remède peut être pire que le mal. Si en .inc ils sont lisibles en clair, en .php ils sont exécutables. Et si tu n'as pas mis de garde fous, le comportement peut être indéterminé.
Le mieux, c'est de reléguer les fichiers inclus dans un répertoire inaccessible via HTTP, mais tout de même accessibles par le script PHP.
Le mieux, c'est de reléguer les fichiers inclus dans un répertoire inaccessible via HTTP, mais tout de même accessibles par le script PHP.
Absolument.
Généralement, seul mon controlleur est accessible en http. Les autres fichiers sont en dehors du www, un cran plus bas. Par contre, il ne faut pas etre en mutualisé, ca complique.....
S.L.
"Mickael Wolff" <mickael.wolff@laposte.net>
Le mieux, c'est de reléguer les fichiers inclus dans un répertoire
inaccessible via HTTP, mais tout de même accessibles par le script PHP.
Absolument.
Généralement, seul mon controlleur est accessible en http. Les autres
fichiers sont en dehors du www, un cran plus bas. Par contre, il ne faut pas
etre en mutualisé, ca complique.....
Le mieux, c'est de reléguer les fichiers inclus dans un répertoire inaccessible via HTTP, mais tout de même accessibles par le script PHP.
Absolument.
Généralement, seul mon controlleur est accessible en http. Les autres fichiers sont en dehors du www, un cran plus bas. Par contre, il ne faut pas etre en mutualisé, ca complique.....
S.L.
Pascale
slambert écrivait news:49633410$0$732$:
Par contre, il ne faut pas etre en mutualisé, ca complique.....
Et nous y sommes, précisément... M'enfin, mes programmes appelés par include (que j'ai passés maintenant en .php) ne sont pas plus dangereux que le reste des programmes...
Par contre, il ne faut pas
etre en mutualisé, ca complique.....
Et nous y sommes, précisément...
M'enfin, mes programmes appelés par include (que j'ai passés maintenant
en .php) ne sont pas plus dangereux que le reste des programmes...
Par contre, il ne faut pas etre en mutualisé, ca complique.....
Et nous y sommes, précisément... M'enfin, mes programmes appelés par include (que j'ai passés maintenant en .php) ne sont pas plus dangereux que le reste des programmes...
