API JSON - Accès au contenu abonné des articles

[AnaelMobilia]

Hello,

Je suis le mainteneur d'une application Android pour consulter les news de Next.

Lorsque j'interroge l'API JSON du site, le contenu des articles abonnés est tronqué malgré l'authentification de l'utilisateur.

Exemple :

• API : POST https://beta.next.ink/wp-json/auth/v1/authenticate avec le payload adéquat => L'appel fonctionne, on reçoit bien le cookie wordpress_logged_in_7...0 avec valeur A...%7C169...%7Cr...3

  {
  "status": "success",
  "user_ID": 5...
  }

• API : GET https://beta.next.ink/wp-json/wp/v2/posts/117673 => Le cookie est bien retransmis, pourtant l'article dans content -> rendered reste tronqué

Je ne sais pas si c'est un problème de prise en compte de l'authentification, une taille maximale du champ retourné, ou si un autre champ devrait être retourné dans /posts/ avec le contenu (intégral|complémentaire) ? Avez-vous des billes là dessus ?

Bonne journée, Anael

[francois-dorin]

Comme c'est du REST, il y a de forte chance qu'il soit nécessaire de passer le token d'authentification dans le header Autorization, et non en tant que Cookie. C'est ainsi que fonctionne énormément d'API REST, et c'est ainsi que semble fonctionner aussi Wordpress.

[francois-dorin]

J'ai peut être parlé trop vite. J'ai trouvé ailleurs que l'authentification par Cookie était supportée.

Par contre, pour qu'elle soit valide, il faudrait apparemment passer un nonce... Sinon, la requête est considérée comme étant anonyme.

For developers making manual Ajax requests, the nonce will need to be passed with each request. The API uses nonces with the action set to wp_rest. These can then be passed to the API via the _wpnonce data parameter (either POST data or in the query for GET requests), or via the X-WP-Nonce header. If no nonce is provided the API will set the current user to 0, turning the request into an unauthenticated request, even if you’re logged into WordPress.

[AnaelMobilia]

Hello @francois-dorin ,

Merci pour les idées !

J'ai essayé les choses suivantes :

• header "Cookie" + valeur du cookie
• header "Authorization" + base64(user:password)
• header "Authorization" + "Bearer" et les différents morceaux du cookie

Le tout sans trouver la bonne formule pour avoir le contenu intégral de l'article abonné.

Ma difficulté est de savoir si :

• l'API /posts gère la notion d'abonné authentifié ? (également, quelle route est utilisée en interne pour la génération des pages du site)
• Si oui, quelle valeur est attendue pour l'authentification ?

Je ne suis pas sûr que l'API de WP gère nativement cette notion de contenu différent selon une authentification (elle gère par contre l'authentification sur un article qui serait protégé par mot de passe).

Pour les nonce, j'étais déjà tombé dessus. Par contre, ça n'a du sens que pour des actions effectuées en deux temps : il faut générer et transmettre le nonce à l'utilisateur avant qu'il ne fasse sa prochaine requête (c'est du CSRF). Je n'ai pas trouvé d'endpoint me permettant d'en générer/récupérer un...

[francois-dorin]

Je ne suis pas sûr que l'API de WP gère nativement cette notion de contenu différent selon une authentification (elle gère par contre l'authentification sur un article qui serait protégé par mot de passe).

Wordpress gère 2 choses effectivement :

• l'accès par mot de passe à un article
• une fonctionnalité Read More au niveau des articles

Mais ces deux fonctionnalités sont indépendantes, et pour les besoins de Next, il fallait un mixte des 2. A noter aussi au passage que je fais l'hypothèse qu'ils sont partis sur des fonctionnalités existantes de Wordpress pour réaliser leur développement personnalisé, ce qui n'est pas nécessairement le cas.

Pour les nonce, j'étais déjà tombé dessus. Par contre, ça n'a du sens que pour des actions effectuées en deux temps : il faut générer et transmettre le nonce à l'utilisateur avant qu'il ne fasse sa prochaine requête (c'est du CSRF). Je n'ai pas trouvé d'endpoint me permettant d'en générer/récupérer un...

Sachant aussi que le nonce de Wordpress n'a de nonce que le nom. C'est plutôt un token dont la durée de vie dépend de la session de l'utilisateur. Facile à récupérer lorsqu'on fait un plugin/thème (car directement injectable via du PHP), c'est beaucoup plus délicat pour les applications tierces. Et j'avoue ne pas avoir vu non plus comment en récupérer un.

[dragonis41]

Le souci actuel est que l'implémentation du paywall n'est pas incluse dans le contenu de l'article, c'est une meta key qui contient le contenu premium qui est rajoutée ou non à l'article si l'utilisateur possède un abonnement ou non. Il faudrait donc qu'on réécrive une partie de l'API de WP pour qu'elle prenne en compte ce détail et ajoute le contenu premium dans le JSON

[francois-dorin]

@dragonis41 Si ce n'est que ça, ça va ;)

Dans un plugin par exemple, il suffit de rajouter un hook, et ce sera bon :

• register_reft_field

exemple :

register_rest_field( 'post', 'article_complet', array(
'get_callback' => function ( $data ) {
    return get_post_meta( $data['id'], 'nom_du_meta_full_article', true );
}, ));

• article_complet : sera normalement le nom de l'attribut qui sera rajouté dans le JSON
• nom_du_meta_full_article: c'est le nom du meta dans lequel les infos sont enregistrées

Enjoy ;)

[francois-dorin]

Voir aussi (cet article)[https://developer.wordpress.org/rest-api/extending-the-rest-api/modifying-responses/#using-register_rest_field-vs-register_meta], qui parle de la fonction register_meta.

Mais je pense que la première approche est plus adaptée, dans le sens où vous pourrez contrôler la présence ou non de la valeur en fonction de l'utilisateur connecté. Je ne suis pas certains que cela soit possible avec register_meta.

[MosieurClement]

On va commencer à bosser un peu sur l'api à partir de la semaine pro, je vous tiendrai au courant des évolutions ;)

[AnaelMobilia]

Avec les dernières évolutions de l'API, tout est OK.

Merci pour les changements ! :-)