Pb de validation de date avec la dernière version de saisies

Florence_HENRY · Février 12, 2019, 10:07

Bonjour

Depuis la mise a jour du plugin saisie en 3.12.7, mes champs de type date sont systématiquement refusés avec le message "Entered value cannot be accepted." et dans les logs : "Tentative de poste de valeur innaceptable pour datemovie de type date. Valeur postée : 18/04/2014"

Je constate le même problème avec la version 3.13.0. Le formulaire marchait très bien avant.

Mon champ date est déclaré comme ça :

         'datemovie' => array(
             'saisie' => 'date',
             'options' => array(
                 'nom' => 'datemovie',
                 'label' => 'Date',
                 'normaliser' => true,
                 'defaut' => '01/01/1997'
             ),
         ),

Après quelques essais, je me rends compte que toute date qui est différente de la date par défaut est refusée.

Si je supprime la ligne qui donne la valeur par défaut, le formulaire fonctionne.

En jetant un oeil sur le code saisies/date.php, la fonction date_valeurs_acceptables($valeur, $description) renvoie en effet false dès que la date entrée est différente de la date par défaut :

    if (array_diff_assoc($defaut, $valeur)) {
       return false;
   }

Merci de votre aide

--
Florence HENRY
LESIA - CNRS / Observatoire de Paris

maieul · Février 12, 2019, 11:04

Le 12/02/2019 à 11:07, Florence HENRY a écrit :

Bonjour

Depuis la mise a jour du plugin saisie en 3.12.7, mes champs de type date sont systématiquement refusés avec le message "Entered value cannot be accepted." et dans les logs : "Tentative de poste de valeur innaceptable pour datemovie de type date. Valeur postée : 18/04/2014"

Je constate le même problème avec la version 3.13.0. Le formulaire marchait très bien avant.

Mon champ date est déclaré comme ça :
     &#39;datemovie&#39; =&gt; array$
         &#39;saisie&#39; =&gt; &#39;date&#39;,
         &#39;options&#39; =&gt; array\(
             &#39;nom&#39; =&gt; &#39;datemovie&#39;,
             &#39;label&#39; =&gt; &#39;Date&#39;,
             &#39;normaliser&#39; =&gt; true,
             &#39;defaut&#39; =&gt; &#39;01/01/1997&#39;
         $,
     \),
Après quelques essais, je me rends compte que toute date qui est différente de la date par défaut est refusée.

Si je supprime la ligne qui donne la valeur par défaut, le formulaire fonctionne.

En jetant un oeil sur le code saisies/date.php, la fonction date_valeurs_acceptables($valeur, $description) renvoie en effet false dès que la date entrée est différente de la date par défaut :
if $array\_diff\_assoc\($defaut, $valeur$\) \{
   return false;
}

Merci de votre aide

C'est une sécurité qu'on a introduit pour éviter que des gens envoie des valeurs qui ne sont pas prévues. Cela étant, pour date cela en devrait pas faire ca. Je regarde et corrige dans la foulée.

Maïeul

maieul · Février 12, 2019, 11:13

Le 12/02/2019 à 12:04, Maïeul a écrit :

Le 12/02/2019 à 11:07, Florence HENRY a écrit :
Bonjour

Depuis la mise a jour du plugin saisie en 3.12.7, mes champs de type date sont systématiquement refusés avec le message "Entered value cannot be accepted." et dans les logs : "Tentative de poste de valeur innaceptable pour datemovie de type date. Valeur postée : 18/04/2014"

Je constate le même problème avec la version 3.13.0. Le formulaire marchait très bien avant.

Mon champ date est déclaré comme ça :
     &#39;datemovie&#39; =&gt; array$
         &#39;saisie&#39; =&gt; &#39;date&#39;,
         &#39;options&#39; =&gt; array\(
             &#39;nom&#39; =&gt; &#39;datemovie&#39;,
             &#39;label&#39; =&gt; &#39;Date&#39;,
             &#39;normaliser&#39; =&gt; true,
             &#39;defaut&#39; =&gt; &#39;01/01/1997&#39;
         $,
     \),
Après quelques essais, je me rends compte que toute date qui est différente de la date par défaut est refusée.

Si je supprime la ligne qui donne la valeur par défaut, le formulaire fonctionne.

En jetant un oeil sur le code saisies/date.php, la fonction date_valeurs_acceptables($valeur, $description) renvoie en effet false dès que la date entrée est différente de la date par défaut :
if $array\_diff\_assoc\($defaut, $valeur$\) \{
   return false;
}

Merci de votre aide
C'est une sécurité qu'on a introduit pour éviter que des gens envoie des valeurs qui ne sont pas prévues. Cela étant, pour date cela en devrait pas faire ca. Je regarde et corrige dans la foulée.

Maïeul

Je n'arrive pas à reproduire.

Peux tu m'envoyer l'ensemble de ton formulaire?

Merci
Maïeul

Florence_HENRY · Février 12, 2019, 11:19

Le 12/02/2019 à 12:13, Maïeul a écrit :

Je n'arrive pas à reproduire.

Peux tu m'envoyer l'ensemble de ton formulaire?

voilà les fichiers html et php

Le formulaire est appelé avec

#FORMULAIRE_MOVIES_FORM{#ENV{dayofyear}}

où dayofyear est un paramètre de l'url avec le format YYYYMMDD : 20150120

--
Florence HENRY
LESIA - CNRS / Observatoire de Paris

movies_form.html (549 Bytes)

movies_form.php (4.55 KB)

maieul · Février 12, 2019, 11:34

Le mardi 12 février 2019 à 12:19 +0100, Florence HENRY a écrit :

Le 12/02/2019 à 12:13, Maïeul a écrit :

> Je n'arrive pas à reproduire.
>
> Peux tu m'envoyer l'ensemble de ton formulaire?

voilà les fichiers html et php

Le formulaire est appelé avec

#FORMULAIRE_MOVIES_FORM{#ENV{dayofyear}}

où dayofyear est un paramètre de l'url avec le format YYYYMMDD :
20150120

ah
mais datemovie a une option "readonly". Cela veut dire que l'utilisateur
n'a pas le droit de modifier la date. Et c'est justement contre une
éventuellement modification de la date (par tricherie) que saisie se
prémuni maintenant, et indique le message "Valeur non acceptable". Donc
je ne vois pas où est le problème.

Soit tu considère que la date est gelée, avec l'option readonly, et dans
ce cas il ne faut pas qu'on puisse poster d'autre valeurs que celle
définie par défaut, soit tu considère qu'elle n'est pas gelée, et dans
ce cas toutes les valeurs sont permises.

Maïeul
ps
Rien à voir, mais tu devrais utiliser _request() plutot que $_REQUEST.
SPIp fait notamment des vérifications de sécurité dans _request.

Florence_HENRY · Février 12, 2019, 1:00

Le 12/02/2019 à 12:34, Maïeul Rouquette a écrit :

Le mardi 12 février 2019 à 12:19 +0100, Florence HENRY a écrit :

Le 12/02/2019 à 12:13, Maïeul a écrit :

Je n'arrive pas à reproduire.

Peux tu m'envoyer l'ensemble de ton formulaire?

voilà les fichiers html et php

Le formulaire est appelé avec

#FORMULAIRE_MOVIES_FORM{#ENV{dayofyear}}

où dayofyear est un paramètre de l'url avec le format YYYYMMDD :
20150120

ah
mais datemovie a une option "readonly". Cela veut dire que l'utilisateur
n'a pas le droit de modifier la date. Et c'est justement contre une
éventuellement modification de la date (par tricherie) que saisie se
prémuni maintenant, et indique le message "Valeur non acceptable". Donc
je ne vois pas où est le problème.

>

Soit tu considère que la date est gelée, avec l'option readonly, et dans
ce cas il ne faut pas qu'on puisse poster d'autre valeurs que celle
définie par défaut, soit tu considère qu'elle n'est pas gelée, et dans
ce cas toutes les valeurs sont permises.

Je viens de comprendre mon erreur : dans ma fonction _verifier(), je charge les saisies sans passer le paramètre dayofyear

$saisies = saisies_movies_form();
au lieu de
$saisies = saisies_movies_form($dayofyear);

ce qui fait qu'au moment de la vérification, la valeur par défaut était 19970101 et non celle du paramètre passé dans l'URL

en rectifiant le code, cela fonctionne.

Par contre, je reste sceptique sur le fait de considérer que readonly + valeur par défaut implique que seule la valeur par défaut est acceptée. Mais bon, mon problème est résolu.

Merci du coup de main.

Rien à voir, mais tu devrais utiliser _request() plutot que $_REQUEST.
SPIp fait notamment des vérifications de sécurité dans _request.

Ok. merci, je corrige.

--
Florence HENRY
LESIA - CNRS / Observatoire de Paris

maieul · Février 12, 2019, 1:07

en rectifiant le code, cela fonctionne.

Par contre, je reste sceptique sur le fait de considérer que readonly
+
valeur par défaut implique que seule la valeur par défaut est
acceptée.
Mais bon, mon problème est résolu.

J'explique un peu le pourquoi de cela.

Readonly cela veut dire qu'on ne peut pas modifier (lecture seule...).
Donc si quelqu'un envoie une valeur autre que celle par défaut ca veut
dire qu'il essaie de te duper.

Un exemple concret: tu as un formulaire qui détermine un prix avec des
afficher_si. Un input renvoie le prix en fonction du afficher_si.

Donc on met ce input en readonly. Une personne malveillante pourrait
trifatouiller le html pour envoie une autre valeur. Mais ce serait
contre ce qui est prévu...

Merci du coup de main.

> Rien à voir, mais tu devrais utiliser _request() plutot que
> $_REQUEST.
> SPIp fait notamment des vérifications de sécurité dans _request.
>

Ok. merci, je corrige.