[spip-dev] [Bug] Page.php3 ne marche pas sur ouvaton !

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 interdite

alors 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=sommaire

Il 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 interdite

alors 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=sommaire

Il 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