Webservice OpenApi

Sofiane Otmani · le 26/07/17 à 12:08

Bonjour,

 

J'utilise un client REST afin d'accèder aux données JCMS. Cependant, lorsque j'essaye de supprimer une donnée (<url de l'appli>/rest/data/<id_data>) de type task (module de gestion des taches), j'obtiens une erreur 404 alors que la méthode GET fonctionne pour cette même donnée. De plus, la suppression d'autres types de données fonctionne très bien.

Cela est-il possible de supprimer ce type de donnée via l'OpenAPI ? Si oui, y a t'il un paramétrage à faire ?

 

Merci d'avance,

Cordialement.

13 pts
Ronan Kerdudou · le 26/07/17 à 17:47

Vous dites recevoir une erreur 404 ?

Normalement ce code d'erreur correspond au cas où l'identifiant transmis ne correspond à aucune donnée existante, sinon vous auriez potentiellement des erreurs 403 pour "non-autorisé" ou 400 pour certaines erreurs.

Comment se déroule la supression de ce contenu par les IHM ?

Vérifiez bien aussi que l'utilisateur connecté pour vos requètes REST est le même que celui avec lequel vous testez sur la plateforme.

 

#1

Vérifiez aussi la présence de messages d'erreur dans les logs de JPlatform, de Tomcat, et même éventuellement côté Apache (le cas échéant)

Ronan Kerdudou · le 26/07/17 à 17:50
0 pt
Ronan Kerdudou · le 27/07/17 à 16:05

Si vous recevez une erreur 403 alors que votre utilisateur est bien authentifié et dispose du droit de le faire, il peut s'agir du test anti-CSRF qui fait opposition. Dans ce cas une ligne dans les logs vous l'indique. En effet, pour désactiver cette protection il faut que la requête soit reconnue comme une requete REST et que l'entête "X-Jcms-CSRF-Header" soit présent.

Ainsi, 

Si vous utilisez une version 9SP4, vos requetes REST doivent utiliser un "User-Agent" commençant par "JaliosJCMS-RestClient/" (par exemple "JaliosJCMS-RestClient/1.0 (monAppliTierce)" et positionner l'entête "X-Jcms-CSRF-Header".

Dans les versions précédentes, vous devez positionner l'entête "Expect" avec la valeur "no-redirect=no-redirect" ainsi que l'entête "X-Jcms-CSRF-Header". 

Notez que l'entête "Expect" pose soucis pour les versions récentes de Tomcat (> 7.0.55) (voir JCMS-5480), c'est pourquoi nous utilisons désormais le User-Agent.

Lorsque vous utilisez l'API Jalios Rest Client (Java ou .Net) vous n'avez pas à vous soucier de ces contraintes qui y sont intégrées.

La documentation de OpenAPI doit être mise à jour prochainement pour clarifier et compléter le résumé que je viens de vous faire et ajouter les nouveautés qu'apportera la V10.

 

2 pts
Sofiane Otmani · le 27/07/17 à 17:53

Bonjour,

 

Merci pour votre réponse. Je n'ai aucun log dans jcms ainsi que dans le tomcat et bel et bien une erreur 404.

Je vais essayer de précise la situation. J'arrive bien à récuperer les tâches avec la méthode GET : <url de l'appli>/rest/data/com.jalios.jcmsplugin.tasks.Task. Grâce à cette requête, j'accède à toutes les tâches crées. Je peux ainsi requêter la tâche directement avec la même méthode et avec son id (du type int_Task). Ces étapes sont réalisées sans erreurs et les résultats sont ceux attendus.

Mais, j'obtiens l'erreur 404 lorsque que je veux supprimer la tâche via la méthode POST et avec ces champs là :

X-HTTP-Method-Override: DELETE
X-Jcms-CSRF-Header: Hello World

J'arrive par contre à supprimer d'autres types de contenu avec la même requête. De plus, si une tâche avait été crée sur un contenu et que je supprime ce contenu via la méthode POST cela va supprimer le contenu avec la tâche qui lui était associée.

L'utilisateur est également le même dans toutes les situations.

Merci d'avance,

Cordialement.

#1

Je comprend mieux le 404 du coup :-) (la requête interne qui retourne 404 est sur "/null?id=...&opDelete=true")

la classe com.jalios.jcmsplugin.tasks.Task hérite directement de Data, alors que la méthode Delete en REST s'appuie sur les formulaires d'édition qui n'existent pas de manière générique à ce niveau. Il n'est donc possible d'effectuer cette suppression en REST que pour les cas implémentés qui correspondent aux classes héritant de Publication, Workspace, Group, Member, Category et AccessControlList.

Ronan Kerdudou · le 28/07/17 à 10:16
1 pt
Thomas LEGAT · le 10/10/17 à 16:18

Je permets de rebondir sur ce sujet ayant le même problème. Mon besoin est de créer un contenu à partir de l'appel d'un webservice.

J'essaye dans un 1er temps de faire fonctionner l'exemple indiqué dans la doc portant sur le type Article.

Mon site est en mode public. Mon appel est:

http://127.0.0.1:8080/context/rest/data/Article?authKey=djI7al8yOzE1MzkxODAwNTY2NDI7UE9TVDs7MzM7JDJhJDA0JFl1MEcxaXFhcEU0aXZrRi9xdnc4UXV3U3hUMmxFWEI4b0I1LkJxNE9CWnZuWmlIR2M4ay55

Je lui passe ces informations dans le content:

author=j_2&title=titre&summary=textfieldvalue&content=textareafieldvalue&ws=j_4

Dans le header, je lui passe ces valeurs:

User-Agent: JaliosJCMS-RestClient/test

X-Jcms-CSRF-Header: Hello

J'ai dans les logs passées en mode TRACE sur le package Rest:

16:08:37,829 DEBUG [Com'In] [RestManager] - checkIP: ip: '127.0.0.1' (auth. IPs: 127.0.0.1|0:0:0:0:0:0:0:1|192.168.*)
16:08:37,830 TRACE [Com'In] [RestManager] - checkIP: authorized
16:08:37,847 WARN [Com'In] [JcmsJspContext] - [13ebdca24629639434408] Possible attack attempt on rest/data/Article. Request does not validate CSRF prevention checks. Requested URL : 'http://127.0.0.1:8080/context/rest/data/Article?authKey=djI7al8yOzE1MzkxODAwNTY2NDI7UE9TVDs7MzM7JDJhJDA0JFl1MEcxaXFhcEU0aXZrRi9xdnc4UXV3U3hUMmxFWEI4b0I1LkJxNE9CWnZuWmlIR2M4ay55&content=textareafieldvalue&summary=textfieldvalue&opCreate=true&author=j_2&title=titre&ws=j_4'

L'authentification se fait correctement et je me fais bouler par le controle CSRF

j'ai pourtant tenté de désactiver les contrôles CSRF en passant à false cette propriété channel.security.csrf.trust-openapi-requests

#1

A priori, j'aurais tendance à penser qu'il faut passer la propriété à true pour que le contrôle soit by-passé.

Benoît Dissert · le 10/10/17 à 16:23
#2

Effectivement le paramètre doit rester à true Merci! :-)

Thomas LEGAT · le 10/10/17 à 16:32
0 pt