API - Comment l'authentification va fonctionner

[leosw]

Salut à tous,

Un peu de discussion sur comment les authentifications vers l'API vont fonctionner.

Les fonction demandant des droits spécifiques (écriture par exemple), seront de la forme :

Code : Tout sélectionner

/api?toto=tata&apikey=MaCléDAPI&hash=e32be09528d9b6cd3c68d84f6675e6e332021161c1fd78772a5d097ef5d8452a

L'utilisateur dispose ici d'un identifiant : MaCléDAPI
Mais aussi d'un mot de passe : refugesinfo

Le hash est le hash SHA256 de la concaténation de la requête et du mot de passe :

Code : Tout sélectionner

api?toto=tata&apikey=MaCléDAPIrefugesinfo

Côté serveur on vérifie si cela correspond.
Il nous est alors possible de voire les accès en écriture d'un utilisateur, et de bannir ou regénérer des clés si le besoin est.

Pour ce qui est des points négatifs :
* Le mot de passe ne devant pas être diffusé, l'appel à l'API en écriture ne peut se faire via javascript (ou alors il faut passer par un proxy et l'utilisateur de l'API sera responsable des méfaits)
* Il faut mettre en place des sauvegardes chez WRI si on autorise un tel usage.
* HTTPS serait une très bonne idée

Je ne suis pas un expert du tout (je recopie ce que je lis) et je reste ouvert aux critiques

Léo

[sly]

revenons aux bases, que voudrions/voulons-nous permettre avec une API qui authentifie ?

[leosw]

Ce qu'il manque pour le moment, c'est rien, car ça n'existe pas.

Je suis le plus mal placé pour décider ce que l'API devrait faire (aucune idée de ce le projet doit incarner dans ce domaine là).

Je pose donc les questions suivantes :

1. Les commentaires ne doivent être écrit que depuis ce site, afin d'attirer des internautes vers ici ? Ou est-ce que ça peut apporter d'offrir l'édition ailleurs ?

2. Est-ce que l'API doit intégrer la modification des polygones (par exemple), car elle a rapatrié tout ce qui est export (y compris de polygones)

À la première question, je répondrais qu'afin de lutter contre un éparpillement des informations, il peut être à notre avantage de proposer un hébergement de commentaires écrit sur d'autres sites, afin de nous enrichir et de leur proposer une infrastructure mais aussi un regroupement plus simple.
Exemple, on pourrait proposer imaginer que pyrénées refuges soit juste un portail de la section pyrénées de notre base, ou alors que lorsqu'un sportif randonne et croise une cabane, il puisse commenter sur l'abri depuis le même outil que celui d'où il partage ses traces.

Ceci étant je suis le nouveau

Léo

[sly]

1. Les commentaires ne doivent être écrit que depuis ce site, afin d'attirer des internautes vers ici ? Ou est-ce que ça peut apporter d'offrir l'édition ailleurs ?

Je n'y vois pas d'inconvénients sur le principe. (tant que c'est fait en bonne intelligence : gestion spam, modération possible, possibilité de contacter, etc.)
Mais ça me donne l'impression de mettre la charrue avant les boeufs, personne n'a jamais fait cette demande, est-ce bien utile de coder des fonctionnalités qu'il faudra maintenir pour des trucs qui ne servent pas ?

Exemple, on pourrait proposer imaginer que pyrénées refuges soit juste un portail de la section pyrénées de notre base

On peut l'imaginer, mais j'ai peur qu'il y ait quelques réticences et que ça ne soit pas pour tout de suite :
http://www.pyrenees-team.com/forumpteam ... =6&t=10563

[leosw]

Je suis en effet assez triste de lire ça

[Dominique]

Bj

Mes remarques:
- on ne discute pas de stratégie de sécurité sur un forum pubic
- je ne vois pas pourquoi tu n'utilises pas la session phbb (comme j'ai fait sur massif quand tu me l'as fait justement remarquer).
- https pourquoi pas à condition que l'ami SLY posséde un certificat de sécurité et qu'il veuille bien nous en faire proffiter sinon ça coûte bonbon ou bonjour les baniéres d'avertissement toutes rouges.

[leosw]

Salut,

Tous les protocoles de sécurité sont ouverts, afin qu'on puisse bien en discuter.

- je ne vois pas pourquoi tu n'utilises pas la session phbb (comme j'ai fait sur massif quand tu me l'as fait justement remarquer).

Le principe d'une API REST est, comme expliqué ici, d'être sans état :

chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête,

Et donc on ne peut se baser sur les actions précédentes, ce qui simplifie pas mal l'histoire. Il n'y a donc pas d'authentification et chaque requête s'identifie.

Léo

[sly]

Bj
- on ne discute pas de stratégie de sécurité sur un forum pubic

Broha M'enfin, le code sera public sur github de t'façon.

- https pourquoi pas à condition que l'ami SLY posséde un certificat de sécurité et qu'il veuille bien nous en faire proffiter sinon ça coûte bonbon ou bonjour les baniéres d'avertissement toutes rouges.

Marrant que t'en parle, je viens en effet faire certifier un le mois dernier pour le site de ma société.
Mais c'est pas possible de le ré-utiliser vu qu'un certificat SSL c'est par nom de domaine.

Toutefois, il faut noter qu'on en trouve des basiques entre 40 et 50 euros par an et j'ai entendu dire qu'on pouvait même en trouver des gratuits. (M'enfin je fini par avoir des doutes sur ce que ça certifie vraiment, la compatibilité tout navigateur sur le long terme, et combien il faudra de temps avant qu'ils nous réclames des thunes en disant "sinon on le coupe")

Mais si vous pensez que ça peut servir, je peux faire l'effort de chercher, au pire, on repassera en http tout court si on nous casse les c........

[leosw]

Non, l'https y en a pas vraiment besoin, la question c'est est-ce qu'on autorise l'extérieur à éditer ?

[sly]

Le principe d'une API REST est

Rien ne nous empêche de développer une API non-RESET ou hybride (REST pour tout ce qui est lecture seule) et par session si on veut écrire.
Après, c'est pas moi qui fais l'éditeur de polygones donc je vous laisse décider si passer une clé + hache + scie est préférable.


Note : autre option bête : /api?login=moi&pass=123&id_polygne_a_modifier=5
Ou : http:/ /moi:123@ www.refuges.info/api/?id_polygne_a_modifier=5

[sly]

Non, l'https y en a pas vraiment besoin, la question c'est est-ce qu'on autorise l'extérieur à éditer ?

Je n'en vois pas l'intérêt pour l'instant.

Sauf si "extérieur" sous entend l'éditeur de polygones

[Dominique]

(M'enfin je fini par avoir des doutes sur ce que ça certifie vraiment, la compatibilité tout navigateur sur le long terme, et combien il faudra de temps avant qu'ils nous réclames des thunes en disant "sinon on le coupe")

Si tu n'as pas un certificat remontant à une autorité connue de ton explorateur, celui ci va hurler dans tous les sens (Sur FF: une barre rose en haut, sur Chrome: Une grande page toute rouge, ...).
Maintenant, sur un flux API, je ne sais pas. Probable que la bécane le signale aussi.

Rien ne nous empêche de développer une API non-RESET ou hybride (REST pour tout ce qui est lecture seule) et par session si on veut écrire.
Après, c'est pas moi qui fais l'éditeur de polygones donc je vous laisse décider si passer une clé + hache + scie est préférable.

Par session phpbb, c'est tout simple:

Code : Tout sélectionner

require_once ("autoconnexion.php");
if ($_SESSION['niveau_moderation'] >= 1)
...

Si tu est connecté et que tu es modo, ça modifie, sinon, ça ne fait rien (ça marche même sur un flux API).

[sly]

Par session phpbb, c'est tout simple:

Code : Tout sélectionner

require_once ("autoconnexion.php");
if ($_SESSION['niveau_moderation'] >= 1)
...

Si tu est connecté et que tu es modo, ça modifie, sinon, ça ne fait rien :) (ça marche même sur un flux API).

Oui mais ça, tu l'as dis c'est "par session phpbb". C'est à dire que pour un usage en api externe, ça ne marche pas. Cette méthode suppose que l'utilisateur final dispose d'un compte sur le forum et se soit authentifié.
Je pense que léo a une approche "hyper générique" du problème*. Là ou, pour l'instant, le seul accès écriture qu'on a ce sont les polygones, et la seule appli qu'on a pour le faire, c'est une sous notre contrôle.


* c'est pas qu'un mal, bien sûr que je me prend moi aussi à rêver à des autres sites qui intégreraient notre api à leur site pour mettre à jour directement les refuges dans notre base, mais on en en est très loin à mon avis. Et on peut donc sereinement évoluer sans y penser, en 2024, qu'on en sera à php 10, là on re-codera une partie, on se dira qu'on aurait pû économiser 1 journée de travail mais que c'est pas si grave ;-)

[leosw]

Effectivement c'est un peu du rêve.

Je pense après recul, que la lecture seule est déjà énorme. Et ça va permettre de nettoyer le dossier /exportations, /vue/exportations, /vue/point.json et avoir un routage.php bien plus propre qui ne traine pas les cas par cas des extensions.

C'est déjà bien pour moi

[sly]

et avoir un routage.php bien plus propre qui ne traine pas les cas par cas des extensions.

Mmmm ? routage.php ne contient rien concernant l'exportation vue que l'exportation n'avais pas encore été migré vers le système de routage