Doryphore: Bazar API

[seballot]

toutes les url commençant par ?api renvoient une 401. https://gogowiki.teritorio.xyz/?api/fiche/1

Et depuis le dashboard bazar, le lien vers l'api JSON est incorrect, il renvoie vers ?api/fiche/FORM_ID au lieu de ?api/form/FORM_ID

[seballot]

@srosset81 une idée pour le 401? j'ai pareil en local

[acheype]

Hello, Par défaut l'API est fermé. Il faut la passer en public ou définir un token privé. Cf https://github.com/YesWiki/yeswiki/blob/doryphore/docs/api.md. ?api/fiche/X fonctionne bien, cela concerne les fiches, quand à ?api/form/X ce sont les données du formulaire. Cf ?api qui te donne la liste des actions possibles quand tu as activer l'API.

[seballot]

Trop cool, merci Adrien !!

[seballot]

En fait, en y repensant je pense qu'on devrait activer les APIs par défaut en mode public, car c'est ce qui était le cas à présent. Sinon ça risque de faire péter ds trucs un peu partout. Là genre j'ai une carte gogocarto qui importe dynamiquement depuis un wiki, et là va falloir expliquer à la personne qui gère le wiki qu'elle doit aller bidouiller le wakka config (sachant qu'elle sait probablement pas ce que c'est, car c'est pas elle qui l'a installé)

T'en penses quoi @acheype ?

[acheype]

Je crois que l'API a été désactivée par défaut car elle revoit toutes les fiches avec tous les champs sans prendre en compte les droits. Je serais pour ouvrir directement l'API mais mieux vaut avant regarder pourquoi les droits ne sont pas pris en compte. Ainsi on pourrait rendre par défaut que les fiches avec * en lecture et pareil pour ses champs. Et si l'utilisateur veut requêter la totalité des données, il utiliser la clé "Private API".

[J9rem]

@seballot c'est prévu d'ouvrir une partie de l'API, mais nous devons nous concerter entre dev pour en définir les specs. @mrflos confirmes-tu ?

[mrflos]

oui, peut-être voir avec les annotations et rajouter public_acces true|false ?

[J9rem]

Je serais plus partisan de rendre les méthodes GET sans Bearer par défaut mais les méthodes PUT, PATCH et DELETE uniquement avec Bearer

ET de faire un audit de toutes les routes api pour s'assurer qu'il y a un checkACL avant d'envoyer les données sensibles. Qu'en pensez-vous ? je peux faire une PR simple dans ce sens.

[mrflos]

C'est sans doute plus simple a coder de différencier par méthode http, mais pour moi ya des exemple de POST qui pourraient etre ouverts, et des GET fermés (surtout si derriere on mets des checkacl), l'un des usages serait de pouvoir ajouter des fiches ou des triples en ajax.
Ya un risque de faciliter le spam, mais en théorie c'est le comportement bazar par défaut (ajouter des fiches est ouvert). Ca serait sympa pour faire des ajouts de listes fiches depuis une fiche, ou pour jouer avec des webhooks.

Une autre approche serait d'avoir des acls pour les routes d'api, comme pour les handlers, actions, et pages.

[J9rem]

J'aime bien l'idée des routes liées à une définition par acl dans les triples. Nous pourrions ainsi ajouter des triples par défaut pour les routes qui doivent restée sûres.

[mrflos]

On y repensant je pense que de définir des droits par défaut dans les annotations est pas mal, ca marche "out of the box" avec des droits qui peuvent être compliqués. Cela n'empeche en rien de faire des triples pour personaliser ces droits plus tard.

[J9rem]

@seballot #710 vient d'être acceptée, nous allons pouvoir ouvrir quelques routes en public. Est-ce que tu pourrais lister exactement les routes api dont tu aurais besoin en mode public ? Merci

[seballot]

Yop ! Les routes pour récupérer les fiches (entries)

[J9rem]

Pour être sûr d'avoir compris, tu souhaites faire des requêtes GET sur les routes suivantes en ayant défini les cookies avec name:"NomWiki" d'un admin et password:"pwd en md5" uniquement avec les identifiants d'un admin. du site.

Est-ce bien ceci ? ou est-ce que tu veux accéder aux fiches sans cookies de connexion (et dans ce cas, tu n'as pas accès aux e-mails, ni aux fiches non affichables).

@Route("/api/forms/{formId}/entries/{output}/{selectedEntries}", methods={"GET"}) @Route("/api/entries/{output}/{selectedEntries}", methods={"GET"})

[seballot]

peu importe qu'il y ait des cookies de connexion ou non, c'est la meme url non? Mais pour répondre mon cas d'utilisation c'est plutot d'y accéder sans être admin

[mrflos]

oui, je pense qu'on peut laisser la plupart des requêtes GET ouvertes, mais en effets les droits s'appliquent : seules les infos non protégées arrivent si t'as pas les bons droits (tu pourrais envoyer un code http 206 au lieu de 200, pour dire Partial Content )

edit: ah non, ce code sert a découper en plusieures requetes.. c'est pas bon.. cf. https://developer.mozilla.org/fr/docs/Web/HTTP/Status/206 je ne sais pas comment on signifie que les données n'affichent pas tout.. ca serait a creuser du coup, peut etre une reponse genre

{
  "infos": [
    {
      "warning": "Some contents are hidden due of lack permissions"
    }
  ],
  "data": [
    {
      "fiche1": {},
      "fiche2": {},
      "fiche3": {}
    }
  ]
}

[J9rem]

Du coup, s'il faut ouvrir les routes cités en GET en public, il est absolument nécessaire de les réécrire pour faire le tri dans les données quelles renvoient en fonction de si on est connecté en admin ou non. En l'état, je serais plutôt partisan du moindre effort, et de forcer la connexion admin (pas besoin de réécrire les fonctions et suffisamment sécurisé)

[J9rem]

peu importe qu'il y ait des cookies de connexion ou non, c'est la meme url non? Mais pour répondre mon cas d'utilisation c'est plutot d'y accéder sans être admin

C'est la même url effectivement, juste le contenu qui sera différent dans la réponse. As-tu besoin des adresses e-mails et de pouvoir accéder à TOUTES les fiches ?

[seballot]

Moi j'ai besoin de rien hein, je dis juste qu'avec le blocage par défaut des apis y'a des liens entre des yeswiki et des gogocarto qui ont été cassé. Après chaque yeswiki utilise ses apis différemment j'imagine

[J9rem]

Ah OK, je vois tu parles des boutons dans le formulaire bazar et des liens entre YesWiki et Gogocarto. En l'état, nous ne pouvons pas encore réouvrir les routes GET sans améliorer le code pour bien utiliser le guard et vérifier les acl avant de renvoyer les données (sinon fuite de données perso sur le net)

[J9rem]

C'est corrigé avec la dernière release Doryphore. Peux-tu vérifier @seballot que tout fonctionne en suivant le lien visible dans la page BazaR ? Si ok pour toi, je te laisse clore cette issue.

[seballot]

Super ça fonctionne, merci !