Bonjour,
Je faisais mon premier squelette profitant de page.php3 et reçoit sur ouvaton :
fond interdite
alors qu'en local tout allait bien.
Pour vérifier, j'ai appelé :
http://www.spip-contrib.net/page.php3?fond=sommaire
même erreur
Idem pour :
http://www.spip-contrib.net/index.php3?fond=sommaire
Il doit y avoir une config chez ouvaton qui interdit "fond" dans les paramètres url.
Jacques
Jacques PYRAT a écrit :
Il doit y avoir une config chez ouvaton qui interdit "fond" dans les paramètres url.
Et en changeant dans le code "fond" en "fondspip" dans les $_GET de page.php3, ça résoud le problème.
Jacques
Jacques PYRAT wrote:
Bonjour,
Je faisais mon premier squelette profitant de page.php3 et reçoit sur ouvaton :
fond interditealors qu'en local tout allait bien.
Pour vérifier, j'ai appelé :
SPIP-Contrib - Toutes les contributions à SPIP
même erreur
Idem pour :
http://www.spip-contrib.net/index.php3?fond=sommaireIl doit y avoir une config chez ouvaton qui interdit "fond" dans les paramètres url.
Jacques
Est-ce à dire que quelqu'un pourrait écrire fond=http://ma.page.qui.pirate ?
Olivier GENDRIN wrote:
Jacques PYRAT wrote:
Bonjour,
Je faisais mon premier squelette profitant de page.php3 et reçoit sur ouvaton :
fond interditealors qu'en local tout allait bien.
Pour vérifier, j'ai appelé :
SPIP-Contrib - Toutes les contributions à SPIP
même erreur
Idem pour :
http://www.spip-contrib.net/index.php3?fond=sommaireIl doit y avoir une config chez ouvaton qui interdit "fond" dans les paramètres url.
Jacques
Est-ce à dire que quelqu'un pourrait écrire fond=http://ma.page.qui.pirate ?
Dans le doute, j'ai essayé sur spip.net, mais rien à signaler.
J'avais le même pb sur un de mes serveurs
et j'ai trouvé ceci :
cela pourrait provenir du register_global à on chez ton hébergeur voir
avec un phpinfo()
dans ecrire/inc_version.php3 il y a un appel à
function spip_register_globals() {
// Liste des variables dont on refuse qu'elles puissent provenir du client
$refuse_gpc = array (
# inc-public.php3
'fond', 'delais',
-- le filtrage est fait plus loin dans la fonction
if (@ini_get('register_globals')) {
foreach ($refuse_gpc as $var) {
if (isset($GLOBALS[$var])) {
foreach (array('_GET', '_POST', '_COOKIE') as $_table) {
if (
// demande par le client
isset ($GLOBALS[$_table][$var])
// et pas modifie par les fichiers d'appel
AND $GLOBALS[$_table][$var] == $GLOBALS[$var]
) // On ne sait pas si c'est un hack
{
# REMOTE_USER ou fond, c'est grave ;
# pour le reste (cookie 'lang', par exemple), simplement
# interdire la mise en cache de la page produite
switch ($var) {
case 'REMOTE_USER':
case 'fond':
die ("$var interdite");
break;
default:
define ('spip_interdire_cache', true);
Ventre Arnaud a écrit :
J'avais le même pb sur un de mes serveurs
et j'ai trouvé ceci :cela pourrait provenir du register_global à on chez ton hébergeur voir
avec un phpinfo()
Effectivement :
register_globals On On
Et dans le .htaccess, rajouter :
php_flag register_globals off
Résoud le bug chez ouvaton
Jacques