[spip-dev] petitions : pourquoi si complique ?

Dev
1

Fil wrote:
>
> pourquoi passe-t-o nun URL si long pour confirmer les signatures de pétition
> ?

Autre question : est-ce un problème ? Il suffit de cliquer dans le mail reçu...

> http://xxxxxxxxxxxx/article.php3?id_article=21&recalcul=oui&val_confirm=Rp%2FwfiBy#sp21
>
> '&recalcul=oui' est inutile : il suffit de reclaculer de force si c'est un
> URL de confirmation

Ca veut dire qu'on traite des cas particuliers au moment de décider du
recalcul, pas très propre...

Enfin, ca depend aussi de la longueur du nom de domaine (20 caractères,
c'est beaucoup ;p).

2

pourquoi passe-t-o nun URL si long pour confirmer les signatures de
pétition ?

Autre question : est-ce un problème ? Il suffit de cliquer dans le
mail reçu...

Dans certains clients mail, les adresses trop longues voient leur fin
tronquée et passée à la ligne, ce qui fait qu'on ne peut pas,
justement, cliquer ...

-Nicolas

3

@ Antoine Pitrou <antoine@rezo.net> :

Autre question : est-ce un problème ? Il suffit de cliquer dans le mail
reçu...

La laideur d'un URL est toujours un problème

Ca veut dire qu'on traite des cas particuliers au moment de décider du
recalcul, pas très propre...

Euh ? De toutes façons le cookie est nouveau => pas de cache => recalcul
obligatoire

Enfin, ca depend aussi de la longueur du nom de domaine (20 caractères,
c'est beaucoup ;p).

Certes

-- Fil

4

Le problème avec l'URL de validation, c'est pas tant l'URL qu'est moche, c'est surtout les butineurs qui font deux requêtes à chaque fois (j'ai encore pas bien pigé quoi-comment, m'enfin le même problème qu'avec les formulaires qui crééent deux entrées).

Du coup, quand la page s'affiche, ces utilisateurs se cognent un message "Pas de signature correspondant à ce code". Provoqué en fait parce que l'enregistrement s'est déroulé dans un premier temps, et que la page qui s'affiche vient après, et effectivement là y'a plus rien pour eux... D'où toujours pas mal de message "Ca ne veut pas m'enregistrer", alors que la signature vient justement d'être validée.

ARNO*

5

@ Arno* <arno@scarabee.com> :

Le problème avec l'URL de validation, c'est pas tant l'URL qu'est
moche, c'est surtout les butineurs qui font deux requêtes à chaque
fois

Un principe du http est qu'un "GET" ne DOIT PAS être actif, tandis qu'un
"POST" PEUT l'être. Dans SPIP, pour l'instant, on s'en contrefout, d'où les
problèmes de création par millions d'items dans la table spip_forums (à
chaque passage de moteur de recherche sur les liens "poster un article"), la
création multiple de rubriques, etc.

Je propose donc solennellement qu'on se fixe une règle : pas de manipulation
de la base sur des "GET" (sauf pour statistiques et flicage des connectés
évidemment).

En l'occurence, il faudrait

* ne créer d'objet (rubrique, article, forum, etc.) qu'au moment où le
  formulaire est rempli

* Pour la validation des pétitions, que la page de validation propose un
  joli message "appuyer sur ce bouton pour valider" et "appuyez sur ce
  bouton pour annuler".

On peut nettoyer ce qui existe, mais à la condition qu'Arno arrête d'ajouter
des trucs pas conformes. :wink:

                                 * * *

Par ailleurs, il serait temps qu'on se décide sur la question suivante : oui
ou non PEUT-ON faire un "POST" sur l'URI ecrire/articles.php3?id_article=52 ?

Si oui (et je crois que oui), il faut à mon avis le faire dans SPIP, ce
serait plus clean à bien des égards.

("DOIT", "PEUT" etc sont utilisés ici à la manière des RFC.)

-- Fil

6

Hello,

Par ailleurs, il serait temps qu'on se décide sur la question
suivante : oui ou non PEUT-ON faire un "POST" sur l'URI
ecrire/articles.php3?id_article=52 ?

Pour moi, on PEUT, mais on ne DOIT pas.

En gros, ça marche, mais je ne suis pas sûr qu'il soit spécifié que ça
doit marcher, et ça ne me semble pas correct, puisqu'on mélange un
POST et un GET.

-Nicolas

7

Pour moi, on PEUT, mais on ne DOIT pas.

Met alors "DOIT" en minuscules. Au sens des RFC, si on PEUT, on peut.

En gros, ça marche, mais je ne suis pas sûr qu'il soit spécifié que ça
doit marcher

"On PEUT" signifierait qu'il est spécifié que ça DOIT marcher (ie que le
serveur DOIT accepter la requête).

et ça ne me semble pas correct, puisqu'on mélange un POST et un GET.

Au sens de http, c'est un POST (il n'y a pas de GET). Au sens de php c'est
l'ordre "gpc" qui compte (gpc = Get/Post/Cookie), mais comme la variable
id_article est passée de manière identique dans l'URI (donc dans le "Get")
et dans les variables POSTées, il n'y a aucun risque de "mélange".

-- Fil

8

En l'occurence, il faudrait

* ne créer d'objet (rubrique, article, forum, etc.) qu'au moment où le
formulaire est rempli

* Pour la validation des pétitions, que la page de validation propose
un
joli message "appuyer sur ce bouton pour valider" et "appuyez sur ce
bouton pour annuler".

Entièrement d'accord :wink:
On peut faire une exception pour les objets avec statut créés depuis
l'espace privé, puisqu'on peut indiquer les créations parasites
avec un statut spécial ("poubelle"). Cependant ce n'est pas très joli.
A l'époque, j'avais buté sur un truc qui m'empêchait de basculer
la création de l'article lors de la validation du formulaire, mais
je ne me souviens plus du tout quoi :wink:

Par ailleurs, il serait temps qu'on se décide sur la question suivante
: oui ou non PEUT-ON faire un "POST" sur l'URI
ecrire/articles.php3?id_article=52 ?

Faudrait voir la RFC CGI. Ca ne me semble pas sûr puisque si id_article
est présente dans l'URL et dans le POST, et n'a pas la même valeur, la
requête est ambigue...
Tiens, heu, d'ailleurs, j'ai fait un tour sur la liste de dev apache
(oui, oui, bon ;-)) et il semblerait que les dernières versions soient
beaucoup plus restrictives sur les URLs. Par exemple, le serveur
refuse qu'on passe un caractère espace dans l'URL. Ce qui est normal
mais toléré par IE par exemple, et utilisé par beaucoup de scripts
mal programmés (qui oublient de faire un urlencode()).
Il n'est donc pas à exclure qu'un jour les requêtes contenant à la fois
des variables GET et POST soient refusées par certains serveurs.

Si oui (et je crois que oui), il faut à mon avis le faire dans SPIP, ce
serait plus clean à bien des égards.

Heu, pourquoi ?
S'il s'agit des rechargements de page, le vrai truc serait de
faire un redirect vers un GET à chaque POST. Ca peut même être
relativement clean (avec une variable spéciale $post_redirect
qui serait passée dans le formulaire et serait testée, heu, dans
une fonction comme debut_page() :
  if ($HTTP_POST_VARS['post_redirect'])
    @Header("Location: ".$HTTP_POST_VARS['post_redirect']);

C'est ce qu'on fait dans les forums publics, par exemple.

9

@ Antoine Pitrou <antoine@rezo.net> :

A l'époque, j'avais buté sur un truc qui m'empêchait de basculer
la création de l'article lors de la validation du formulaire, mais
je ne me souviens plus du tout quoi :wink:

ajouter le premier auteur ?

Faudrait voir la RFC CGI. Ca ne me semble pas sûr puisque si id_article
est présente dans l'URL et dans le POST, et n'a pas la même valeur, la
requête est ambigue...

Elle aura la même valeur.

Tiens, heu, d'ailleurs, j'ai fait un tour sur la liste de dev apache
(oui, oui, bon ;-)) et il semblerait que les dernières versions soient
beaucoup plus restrictives sur les URLs. Par exemple, le serveur
refuse qu'on passe un caractère espace dans l'URL. Ce qui est normal
mais toléré par IE par exemple, et utilisé par beaucoup de scripts
mal programmés (qui oublient de faire un urlencode()).
Il n'est donc pas à exclure qu'un jour les requêtes contenant à la fois
des variables GET et POST soient refusées par certains serveurs.

Le "donc" ici ne m'apparaît pas évident. La Loi c'est la RFC...

S'il s'agit des rechargements de page, le vrai truc serait de

oui, via "history".

faire un redirect vers un GET à chaque POST. Ca peut même être
relativement clean (avec une variable spéciale $post_redirect
qui serait passée dans le formulaire et serait testée, heu, dans
une fonction comme debut_page() :
  if ($HTTP_POST_VARS['post_redirect'])
    @Header("Location: ".$HTTP_POST_VARS['post_redirect']);

C'est ce qu'on fait dans les forums publics, par exemple.

OK, ça me paraît bien.

PS: http://www.faqs.org/rfcs/rfc2310.html
    "GET and HEAD requests are safe by definition"

-- Fil

10

ARNO*> Le problème avec l'URL de validation, c'est pas tant l'URL
  ARNO*> qu'est moche, c'est surtout les butineurs qui font deux
  ARNO*> requêtes à chaque fois (j'ai encore pas bien pigé
  ARNO*> quoi-comment, m'enfin le même problème qu'avec les
  ARNO*> formulaires qui crééent deux entrées).

Les butineurs supposent que vous êtes conformes aux recommendations
w3c notamment celles concernant HTTP. Si j'ai bien lu leurs bazards,
éparpillés ça et là, ils ne veulent pas qu'une url (éventuellement
insérée dans un courriel) puisse déclencher automatiquement une
action. L'exemple cité dans un thread par l'un des geeks du w3c était
celui d'un utilisateur dont tous les courriels sont analysés par un
programme qui essaie de télécharger tous les liens contenus dans le
courriel pour les stocker sur un pda, histoire de les lire dans son
avion. Un tel utilisateur se verra signer toutes les pétitions sans
même être au courant de quoi que ce soit. De façon général, le w3c
pense que c'est un POST qu'il faut pour ce type de transaction et pas
un GET. On en fait ce qu'on veut, mais je crois que ce serait cool de
le faire `correctement'.

Mes 2 FCFA.

11

Franchement, encore une fois, je ne dis pas mieux que de faire les choses dans les normes, pour peu que les normes soient compatibles avec une interface simple de gestion d'un site. Hum...

-> Pour cette question de validation des pétitions, il faut quand même que le fait de suivre le lien valide le truc. On ne va tout de même pas envoyer un mail de confirmation, dans lequel il faut cliquer sur un lien, ça repasse dans le butineur, et là on leur affiche un beau bouton "Valider ma confirmation parce que oui ce coup-ci c'est bon" histoire qu'il fassent un POST (et tant qu'on y est, un warning javascript "Vous êtes sûr que vous êtes certain?") :-))

-> Pour les formulaires de création d'éléments (mots-clés, rubriques, etc.) dans l'espace privé, je veux bien croire que c'est pas bon, vu qu'on se fait chier à chaque fois. Mais alors, c'est quoi la bonne façon de faire qu'il faut la suivre? [Autant vous prévenir: je ne lis pas la RFC couramment, je ne crois d'ailleurs pas qu'on arrive à créer un site Web ni à apprendre le HTML avec les docs du W3C. Pour vous situer mon niveau: pour me mettre au PHP, j'ai dû acheter un bouquin chez Eyrolles, parce les docs en ligne j'y comprenais que dalle. C'est un peu comme si vous essayiez d'apprendre la musique en lisant une thèse en électro-acoustique ou d'apprendre à parler l'italien en lisant le dictionnaire.]

ARNO*

12

@ Arno* <arno@scarabee.com> :

-> Pour cette question de validation des pétitions, il faut quand
même que le fait de suivre le lien valide le truc. On ne va tout de
même pas envoyer un mail de confirmation, dans lequel il faut cliquer
sur un lien, ça repasse dans le butineur, et là on leur affiche un
beau bouton "Valider ma confirmation parce que oui ce coup-ci c'est
bon" histoire qu'il fassent un POST (et tant qu'on y est, un warning
javascript "Vous êtes sûr que vous êtes certain?") :-))

Non, Ousmane a raison : il faut que le clic t'amène à un bouton. Mais ce
bouton peut très bien être quasiment tout seul sur une page à lui, et
renvoyer vers la page d'article après. Du coup "Valider" prend tout son
sens, et ça permettra même de gérer l'affichage bien propre de la nouvelle
liste des signataires (un "recalcul=oui" dans le bouton).

-> Pour les formulaires de création d'éléments (mots-clés, rubriques,
etc.) dans l'espace privé, je veux bien croire que c'est pas bon, vu
qu'on se fait chier à chaque fois. Mais alors, c'est quoi la bonne
façon de faire qu'il faut la suivre?

Ce que j'ai fait dans ecrire/mots_type.php3 :

// init données
if ($new == 'oui') {
    $titre = 'Nouveau type de mot';
    ../..
} else if ($type) {
    $query = "SELECT * FROM spip_type_mots WHERE type = '".addslashes($type)."'";
    ../..
    $titre = $roww['titre'];
}

../.. afficher le formulaire contenant les données

Et le contenu du formulaire est POSTé sur un fichier qui crée
l'enregistrement si besoin est.

-- Fil