Utiliser une API perso avec / à côté de yunohost

La page 404 que nous voyons là est celle générée par Slim, pas par Nginx. Donc Nginx transmet une route, on ne sait pas laquelle, à Slim, qui te retourne Route Not Found. C’est là où je voudrais bien que le cadriciel (j’adore de mot) soit plus verbeux !

L’autre souci, c’est qu’en passant directement par la méthode du port, on contourne complètement Nginx, donc là ce n’est que la faute de Slim.

Quant à Composer, c’est une erreur tout con que j’ai faite aussi. Il faut l’appeler avec php7.4 composer.phar ... et pas php composer.phar tout court.

Je comprend ce que tu veux dire mais c’est la seule route transmise correctement parce que si je fais :

Alors que en local :

Donc ma conclusion c’est que en faisant …/pvapp/api/v1/tockens nginx va chercher le fichier dans www/public/api/v1/tockens. C’est d’ailleurs ce que le message suivant nous montre si j’ai bien compris

2020/07/23 19:03:28 [error] 10208#10208: *3161 open() "/var/www/my_webapp/www/public/api/v1/tokens" failed (2: No such file or directory), client: 88.120.120.131, server: labaudesrv.duckdns.org, request: "POST /pvapp/api/v1/tokens HTTP/1.1", host: "labaudesrv.duckdns.org" 

Effectivement ça fonctionne mieux !

Je savais même pas que ce mot existait, je croyais qu’il n’y avait pas d’équivalent à framework.

Ah, on a pas la même erreur. Moi, systématiquement j’ai une page du même genre que la seconde, jamais la première.

Comme souvent, les québécois sont les garants d’un français qui suit la technologie sans devenir ringard. ^^

J’ai un peu modifié mon précédent message

Ok bon si on a pas les mêmes erreurs, on est mal barrés… Mais si toi t’as toujours une page comme la 405 method not allowed (celles générés par slim) c’est déjà beaucoup mieux ! C’est même sûrement que tout marche bien !

Je vais tout réinstaller alors !

Y’a une procédure particulière à suivre pour désinstaller correctement la custom web app et supprimer tous les fichiers ? Ou une désinstallation par la webadmin ça suffie ?

hahahaha je vois ça !

Moi c’est toujours une erreur 404 fournie par Slim.

Celle-ci suffit ! Si tout ce que tu as modifié est dans les limites de l’app, ça sera bon.

quand je fais ça il me dit

chown: invalid user: ‘myweb_app:my_webapp’

C’est parce que je ne sais pas retaper une commande ^^, le premier _ est au mauvais endroit.

chown my_webapp:my_webapp .composer

J’aurai pu trouvé ça tout seul … :man_facepalming:

Bon j’ai refais toute l’installation sans la partie CORS parce que pour l’instant pas de problème avec.

A noter que la web app c’est installé avec php7.0 donc j’ai du redéplacer le dossier dans le dossier 7.4/fpm/pool.d (il me semble d’ailleurs que l’ancien y etait toujours).

Bon la conclusion sinon c’est que j’ai toujours la route / qui me renvoie la 404 de slim.
Par contre toutes les autres routes m’envoie directement vers la page de connexion des utilisateurs de yunohost. Et si je me connecte il me disent “Erreur de redirection : domaine non géré”…

Bref je sais pas si on est vraiment avancé … Mais j’ai vraiment l’impression que toutes les routes en dehors de domaine/pvapp/ sont non géré. Comme si nginx va chercher la route comme l’url (enfin comme avant quoi). Donc la seule différence avec avant c’est qu’au lieu d’avoir un 404 de nginx je suis redirigé sur domaine/yunohost/sso

Bon cette nuit j’ai réalisé qu’il fallait aussi mettre à jour la version de php fpm dans
/etc/nginx/conf.d/$Domaine.d/my_webapp.conf

Et également dans

/etc/php/7.4/fpm/pool.d/my_webapp.conf

Bon mais ça ne change rien.

Je tente donc la methode du port mais :

me renvoie

usage: yunohost firewall allow {TCP,UDP,Both} port
                               [-h] [-4] [-6] [--no-upnp] [--no-reload]
yunohost firewall allow: error: argument protocol: invalid choice: '8085' (choose from 'TCP', 'UDP', 'Both')

En attendant je vais chercher comment nginx fait la ré écriture d’URL parce que c’est necessaire pour cette architecture d’API et le problème viens peut-être de là …

Edit : en lisant la doc je me rends compte qu’on peut implémenter un middleware qui redirige le trafique http en https. Peut-être que ça joue un peu.
Je vois aussi qu’on peut implémenter un handler d’erreur pour 404 php http, je vais voir si je peux implenter ça. Mais pas sur que ça nous aide parce que là SILM est complètement contourné

Je ne peux pas trop t’aider aujourd’hui, mais je peux au moins corriger ça:

yunohost firewall allow TCP 8085