[RÉSOLU] Input avec Saisies

Général
1

Je suis en train de développer un plugin pour interfacer un SPIP avec Umami (concurrent de Matomo) qui fonctionne sur la même base que Matomo (URL + un id de site). Je rencontre un problème avec le formulaire de configuration :

l’id de website avec Umami est sous cette forme : 2676f2e9-fb38-4c13-beea-d3f6abe7adc3

function formulaires_configurer_umami_saisies(): array {
    $saisies = [
		[
			'saisie' => 'input',
			'options' => [
				'nom' => 'url_instance',
				'label' => '<:umami:cfg_instance:>',
			],
		],
		[	'saisie' => 'input',
			'options' => [
				'nom' => 'id_website',
				'label' => '<:umami:cfg_id:>',
			],
		],
	];
	return $saisies;
}

Toutefois quand je saisis l’ID de site web dans le formulaire, il ne le garde pas et le ramène à 0 ou ne garde que les quatre premiers chiffres.

Je ne comprends pas ce qu’il se passe, parce que je peux saisir la même chaine de caractères dans l’input de l’URL sans problèmes.

2

très étrange, il n’y aucune raison que cela produise ca.

Est-ce que avec l’inspecteur web, tu peux vérifier que tout est bien envoyé depuis le navigateur (onglet reseau) ?

3

Bonjour,

Dans la base tu a mis quel type de champ ?

4

Je n’ai pas compris ce que tu veux dire par :

Voici ce que ça donne du côté de l’inspecteur web

capture_spip_
capture_spip_942×688 139 KB

Il ne semble pas y avoir de problèmes.

5

Je ne comprends pas ta question, de quelle base parles-tu ?

6

Tu enregistre le formulaire comment ensuite ?

7

Avec id_site, l’écran de sécurité applique un (int) et donc 2676f2e9-fb38-4c13-beea-d3f6abe7adc3 devient 2676.

Il faut un nom qui ne commence pas par id_.

1 « J'aime »
8

Je n’ai pas encore tout compris de comment ça fonctionne avec Umami et son script JS mais dans l’idée de plagier Matomo, les deux valeurs sont utilisées comme #CONFIG dans le fichier js.

J’ai l’impression de répondre à côté de la plaque …

9

Ah oui ça va beaucoup mieux maintenant, merci.

10

donc une meta :wink:

je trouve pas de domaine sur umami encore, matomo est déjà bien complet

2 « J'aime »
11

Voilà le resultat :

12

Et pour info, quel est l’intérêt de umami par rapport à matomo (qui a déjà son ou ses plugins spip) ?

13

A la base je le trouvais moins « usine à gaz » que Matomo, surtout quand tu cherches juste des statistiques de fréquentation d’un site web. Même si dans son évolution il tend vers ces gros machins « tracking full comportement et monetisation »

Je penses pas qu’il y est d’avantage spécialement, je l’utilise parce que ça été un chantier monstrueux pour l’installer sur mon serveur YnH et que maintenant il y est ^^

Pas d’avis technique particulier…

14

Notons que cette limitation des champs id_ ne sera plus présente en SPIP 5.

1 « J'aime »
15

Je ne vois pas ça comme une limitation mais comme une fonctionnalité puisque ça protége facilement et à faible coût les valeurs des principaux d’arguments d’url. Pourquoi s’en priver ?

16

Après le commentaire de @JLuc ce matin, et en fouillant dans mes connaissances de SPIP, je me suis dis que c’était une bétise de nommer ce champs id_website.

Depuis ce midi : Plus jamais je ne ferais de formulaire avec un champ id_

1 « J'aime »
17

Ah ben je découvre aussi…
Ça a été annoncé ?
Et qu’est ce qui motive cette décision ?
C’est peut être une mauvaise pratique pour toi de se croire protégé par cette convention (id_*), je l’entends, mais ça risque d’ouvrir des portes dans plein de plugins ça…

18

Ce serait une décision prise dans la continuité de Nettoyer l’écran de sécurité (#5055) · Issues · spip / spip · GitLab ?

19

Il y avait eu des discussions orales certainement je pense notamment autour de ces points, et peut être sur les tickets de l’écran sécu, mais

cast id_* en int pose des problèmes :

  • ça provoquait des problèmes en prepend sur des serveurs sur d’autres logiciels (il y avait des exceptions déjà dans notre code l’ailleurs), donc certains rares id_xxx n’étaient pas castés, ce qui déjà n’était pas clair
  • c’était pour une époque lointaine où sql_quote ou intval ou (int) n’était pas appliqué partout sur les requêtes SQL
  • ça empêche des identifiants non numériques, alors que des demandes existaient, et cela créée beaucoup de confusion donc ; pour preuve encore cette discussion donc

Bloquer les `id_rubrique=spip.php?id_rubrique=%3Cmarquee+onstart%3D%27alert%28%22XSS%22%29%27%3EText%3C%2Fmarquee%3E&page=majoliepage` (#10) · Issues · spip-contrib-outils / securite · GitLab aussi

1 « J'aime »
20

ça provoquait des problèmes en prepend sur des serveurs sur d’autres logiciels (il y avait des exceptions déjà dans notre code l’ailleurs), donc certains rares id_xxx n’étaient pas castés, ce qui déjà n’était pas clair

Ça c’est une utilisation pas vraiment standard, quelqu’un qui fait ça devrait savoir comment s’en accommoder.

Sinon, j’ai cherché dans docs/fr/5.0/guides/migration · main · spip / docs · GitLab et je n’ai pas vu.
Ça mériterait d’être précisé.