Utiliser des tokens avec REST Factory

[tanrhiel]

Bonjour à tous,

Je voudrais savoir s’il est possible d’utiliser les tokens avec REST Factory et si oui comment est-ce que je dois m’y prendre ?

[b_b]

Salut, j’ai eu à le faire dernièrement et j’ai procédé ainsi pour mon plugin qui porte le préfixe resa :

1. déclaration d’un critère obligatoire key dans la déclaration d’une collection depuis le pipeline resa_liste_ezcollection :

	$flux['categories'] = array_merge($options, array(
		'ressource' => 'id_mot',
		'filtres' => array(
			array(
				'critere' => 'key',
				'est_obligatoire' => true,
				'vide_interdit' => true,
			),
			array(
				'critere' => 'id_groupe',
				'est_obligatoire' => false,
			)
		)
	));

2. déclaration d’une fonction de vérification du pseudo filtre key dans le fichier erzrest/resap.php :

/**
 * Détermine si la valeur d'un critère de filtre d'une collection est valide.
 *
 * Gestion de l'acccès aux données de l'API à l'aide de clés définies dans _RESA_API_KEYS
 *
 * @param mixed  $valeur Valeur du filtre key.
 * @param &array $erreur Tableau initialisé avec les index identifiant l'erreur.
 *
 * @return bool `true` si la valeur est valide, `false` sinon.
 */
function resa_verifier_filtre_key($valeur, &$erreur) {

	// Initialise le retour à true par défaut.
	$est_valide = true;

	if (!defined('_RESA_API_KEYS')) {
		define('_RESA_API_KEYS', array());
	}

	if (!in_array($valeur, _RESA_API_KEYS)) {
		$est_valide = false;
		$erreur['type'] = 'critere_key_nok';
		$erreur['message'] = 'Clé API invalide';
	}

	return $est_valide;
}

Ainsi, chaque appel à l’API vérifie que la clé passée dans le paramètre key est bien présente dans _RESA_API_KEYS, et hop

[tanrhiel]

Merci beaucoup pour ton aide

[b_b]

De rien, ça serait l’occasion d’en faire une mini doc, mais je pense que le mieux serait d’ajouter ça de manière « générique » dans le plugin ezrest/http. On avait échangé à ce sujet avec @eric_tonton

[eric_tonton (Eric Lupinacci)]

Hello,

Je vais faire ça.
L’idée c’est bien d’intégrer le token dans la déclaration de l’API sans passer par un filtre explicitement ?
Dans ce cas, je proposerais de préciser le nom du paramètre et une regexp facultative qui permet de mieux vérifier la clé. Si pas de regexp on ne vérifie rien d’autre que la présence du token avec une valeur non vide.
ok ?

[b_b]

Yop,

@eric_tonton

L’idée c’est bien d’intégrer le token dans la déclaration de l’API sans passer par un filtre explicitement ?

Oui exactement, histoire de ne pas « détourner » l’usage d’un filtre pour ça.

@eric_tonton

Dans ce cas, je proposerais de préciser le nom du paramètre et une regexp facultative qui permet de mieux vérifier la clé. Si pas de regexp on ne vérifie rien d’autre que la présence du token avec une valeur non vide.

Oui, amha il faut permettre de spécifier si on souhaite utiliser key/password/token ou autre. Par contre je ne suis pas certain de comprendre ce que tu entends par regexp. Pour moi il suffit de déclarer une fonction de vérification de la validité de la clé/token dans laquelle on peut tout faire (vérifier une regex, la présence de la clé dans une variable ou autre).

[eric_tonton (Eric Lupinacci)]

Bon c’est bien ce que j’ai fait dans l’esprit.
Dans la pratique c’est une déclaration simplifiée qui rappelle les filtres car j’utilise ensuite le processus de vérification sur les filtres pour limiter les modifications.

A l’occasion j’ai rajouté deux nouvelles features:

• un attribut ‹ sans_condition › dans la configuration d’un filtre donné ce qui permet d’éviter la création d’une fonction qui retourne vide
• un attribut ‹ format › dans la configuration d’un filtre qui permet de préciser une regex pour le format de la valeur attendue. Cela repousse encore le besoin de créer une fonction de vérification. Cette attribut est repris aussi pour la clé si besoin.

Je teste et je publie tout ça.

[eric_tonton (Eric Lupinacci)]

Voilà, il existe une nouvelle version 1.1.0 de REST Factory qui prend tout ça en compte et bien plus. Je viens de mettre à jour le plugin Nomenclatures et j’ai viré 5 services spécifiques devenus inutiles avec la nouvelle configuration des collections.
Faut que je mette la doc à jour par contre.

[b_b]

Super, j’ai vu ça passer et j’ai commencé à adapter mon plugin qui utilisait ça. Juste une question, je n’ai pas trouvé l’info dans https://git.spip.net/spip-contrib-extensions/ezREST/commit/7d686f229f0bcf3df3f0fb362b058ebea7e1f29b : comment doit-on déclarer la fonction d’autorisation de la clé ? Comme un filtre classique ?

[eric_tonton (Eric Lupinacci)]

Tu as un exemple dans le fichier template des pipelines inclus dans le plugin à la racine.
C’est beaucoup plus simple justement qu’un filtre justement.
La fonction qui vérifie si la clé est autorisée est xxxx_verifier_cle() ou xxxx est soit la collection si c’est particulier à la collection, soit le plugin si c’est la même pour toutes les collections du plugin.

Nomenclatures met en oeuvre les nouvelles fonctions aussi. Tu peux regarder le code et surtout le delta des derniers commits qui vont te montrer comment tu peux alléger ton code.

[b_b]

Super, je teste ça plus en détail et je te fais un retour

[tanrhiel]

super je teste aussi
merci beaucoup

[b_b]

@eric_tonton

Tu as un exemple dans le fichier template des pipelines inclus dans le plugin à la racine.

Tu es certain ? Je ne trouve aucune occurrence de « verifier » dans spip-contrib-extensions/ezREST - prefixe_pipelines.php.template at master - ezREST - SPIP on GIT

@eric_tonton

Nomenclatures met en oeuvre les nouvelles fonctions aussi. Tu peux regarder le code et surtout le delta des derniers commits qui vont te montrer comment tu peux alléger ton code.

Idem de ce côté, le dernier commit en date https://git.spip.net/spip-contrib-extensions/nomenclatures/commit/e4500f430dbf6f9de7c081ee71ed451647f6a177 ne me permet pas de trouver de piste. Tu as bien tout pushé en ligne ?

[eric_tonton (Eric Lupinacci)]

En fait je parlais de la déclaration de la clé uniquement. Tu as un exemple dans le template de pipeline. Mais c’est exact que pour la fonction vérifier je l’avais sur un plugin de tests uniquement.

Pour la déclaration (le format est facultatif):

		'cle' => array(
			'critere' => 'token',
			'format' => '/\d{6}/'
		),

Pour mettre en oeuvre la vérification de la clé c’est simple: tu crées une fonction xxxx_verifier_cle() avec soit xxx au nom de la collection (si c’est spécifique) soit au nom du plugin si tu veux qu’elle soit applicable à toutes les collections. Par exemple:

function isocode_verifier_cle($cle, &$erreur) {
	$est_valide = true;
	if ($cle !== '123456') {
		$est_valide = false;
	}
	return $est_valide;
}

Pour les nouvelles fonctions tu as le format d’un filtre qui permet de tester sa syntaxe par une regex si besoin.
Toujours pour un filtre tu as l’indicateur sans_condition qui dit que le filtre ne doit pas générer de condition SQL. Donc il n’est plus utile de créer une fonction xxxx_conditionner_yyyy() pour renvoyer une chaine vide pour la condition.

Voilà déjà ce que je peux dire. Dis-moi si ça te va, la doc is coming soon.

[b_b]

Hihi, j’allais testé le bouzin et là je me rends compte que le site sur lequel j’utilise ça est encore en SPIP 3.2, on verra ça plus tard, désolé

[b_b]

J’ai pris le temps de passer le site en question en SPIP 4 à l’arrache, et je confirme, ça fonctionne au top, un succès (y)