Erreur 403 avec custom web app

Mon serveur YunoHost

Matériel: Yuno sur une VM
Version de YunoHost: 4.0.8.3
J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran | …
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Hello,

Je tente ces derniers temps d’installer une API perso sur Yunohost. Je cherche donc à passer par la custom webapp mais j’ai pour l’instant une belle erreur 403 Forbidden de Nginx.

Voici ma démarche :
J’ai installé la custom web app
Ensuite je vais dans mon dossier /var/www/my_webapp et je clone mon repo dans le dossier www
Ensuite j’installe composer puis je le lance pour installer les dépendances de l’API
Ensuite je fais un sudo chown my_webapp:my_webapp .de mon dossier www pour donner les bonnes permissions
Enfin j’édite ma config nginx dans /etc/nginx/conf.d/$Domaine.d/my_webapp.conf
en changeant à la ligne 5 par : alias /var/www/my_webapp/www/public/; parce que mon index.php n’est pas dans le dossier www mais dans un sous dossier public

Je reload nginx et après tout ça j’ai mon erreur 403.

Donc je voudrais votre aide parce que je ne comprend pas pourquoi nginx me bloque.

Merci d’avance !

Perso je regarderais le log /var/log/nginx/tondomaine.tld-error.log pour voir si il y a plus d’infos sur l’origine du 403 …

Merci @Aleks

Bon en dehors de la première ligne qui me dit que le répertoire est interdit j’ai du mal a en tirer une info qui m’aide ahah

2020/12/28 17:34:12 [error] 964#964: *22 directory index of "/var/www/my_webapp/www/public" is forbidden, client: 192.168.0.22, server: pvapptestpackage.local, request: "GET /custompvapp/ HTTP/2.0", host: "pvapptestpackage.local", referrer: "https://192.168.0.20/yunohost/admin/"
2020/12/28 17:34:12 [error] 964#964: *22 open() "/var/www/pvapptest/public/ynh_portal.js" failed (2: No such file or directory), client: 192.168.0.22, server: pvapptestpackage.local, request: "GET /ynh_portal.js HTTP/2.0", host: "pvapptestpackage.local", referrer: "https://pvapptestpackage.local/custompvapp/"
2020/12/28 17:34:12 [error] 964#964: *22 open() "/var/www/pvapptest/public/ynh_overlay.css" failed (2: No such file or directory), client: 192.168.0.22, server: pvapptestpackage.local, request: "GET /ynh_overlay.css HTTP/2.0", host: "pvapptestpackage.local", referrer: "https://pvapptestpackage.local/custompvapp/"
2020/12/28 17:34:12 [error] 964#964: *22 open() "/var/www/pvapptest/public/ynhtheme/custom_portal.js" failed (2: No such file or directory), client: 192.168.0.22, server: pvapptestpackage.local, request: "GET /ynhtheme/custom_portal.js HTTP/2.0", host: "pvapptestpackage.local", referrer: "https://pvapptestpackage.local/custompvapp/"
2020/12/28 17:34:12 [error] 964#964: *22 open() "/var/www/pvapptest/public/ynhtheme/custom_overlay.css" failed (2: No such file or directory), client: 192.168.0.22, server: pvapptestpackage.local, request: "GET /ynhtheme/custom_overlay.css HTTP/2.0", host: "pvapptestpackage.local", referrer: "https://pvapptestpackage.local/custompvapp/"

À mon avis j’interprète ça comme :

  • il ne trouve pas le index qu’il voudrait
  • et donc il essaye de faire un “directory index” (le machin ou le navigateur t’affiche tous les fichiers présent dans le dossier automatiquement) mais ce n’est pas permis par la conf nginx en l’état

À mon avis tu devrais tester en accédant à tondomaine.tld/chemindelapp/index.php

Si ça ça marche, alors ça veut dire que le soucis est au niveau des instructions index-bidule dans la conf nginx…

Re Aleks

En fait le problème ne vient peut-être pas de là. Parce que je viens de découvrir que si j’essaie d’accéder à Yuno par le nom de domaine (j’utilise mon fichier host puisque je suis en local dans un VM) j’ai la même erreur 403. Donc il y a déjà un problème ici. Et pour le coup je n’ai aucune idée de où peut venir le problème …

EDIT :

En effet le problème ne venait pas de la custom web app mais d’un problème de configuration globale de Ngnix. Parce que j’ai créer une autre VM et je n’ai plus ce soucis.

Cependant tout n’est pas fini mais ça avance très bien ! En effet dès que je fais une requête par URL qui n’est pas juste la racine je suis redirigé vers SSO et ça bloque donc la requête.
C’est peut-être pas très clair donc je donne un exemple :
https://pvapptestpackage.local/pvapp/ fonctionne correctement
https://pvapptestpackage.local/pvapp/api/v1/bidule ne fonctionne pas et je suis redirigé vers SSO

Quelle pourrait être la solution ?

Edit 2:

J’ai désactivé SSO (provisoirement) pour voir ce que ça donne et j’ai des erreurs 404 sur toutes les routes où j’étais redirigé vers SSO. C’est donc peut-être pas SSO le problème (on est peut-être juste redirigé en cas de 404) et ce serait donc la config qui ne redirige pas correctement.

Voici ce que me disent les logs :

2021/01/04 22:52:13 [error] 24318#24318: *152 open() “/usr/share/nginx/htmlindex.php” failed (2: No such file or directory), client: 192.168.0.16, server: pvapptestpackage.local, request: “GET /pvapp/api/v1/ HTTP/2.0”, host: “pvapptestpackage.local”

PS : J’ai remarqué qu’il n’y a plus de page État du serveur dans les Outils, c’est normal ?

On ne va pas pouvoir t’aider sans partager les modifs que tu as fait à la conf nginx ni les fichiers qui se trouvent dans le dossier /var/www/mywebapp/…

Oui, depuis la 3.8

Ok j’avais pas encore remarqué …

La conf nginx je l’ai presque pas modifié, j’ai ajouté juste public à la fin de l’alias pour le path :
Edit : en écrivant ça hier soir je me suis souvenu d’un bug de conf nginx sur le chemin et j’ai donc ajouter /pvapp/ à la ligne `try_files.

Et du coup tout fonctionne “presque” bien !!

 rewrite ^/pvapp$ /pvapp/ permanent;
location /pvapp/ {

    # Path to source
    alias /var/www/my_webapp/www/public/;

    # Force usage of https
    if ($scheme = http) {
        rewrite ^ https://$server_name$request_uri? permanent;
     }

    # Default indexes and catch-all
    index index.html index.php;
    try_files $uri $uri/ /pvapp//pvapp/index.php?$args;

    # Prevent useless logs
    location = /pvapp/favicon.ico {
        log_not_found off;
        access_log off;
    }
    location = /pvapp/robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # Deny access to hidden files and directories
    location ~ ^/pvapp/(.+/|)\.(?!well-known\/) {
        deny all;
    }

    # Execute and serve PHP files
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        fastcgi_pass unix:/var/run/php/php7.3-fpm-my_webapp.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param SCRIPT_FILENAME $request_filename;
    }

    # Include SSOWAT user panel.
    include conf.d/yunohost_panel.conf.inc;
}

Alors parmis les trucs étranges si je tape juste mon nom de domaine dans mon navigateur je tombe sur la page “Welcome to nginx” ce qui n’est pas normal.

Ensuite autre chose étrange : je ne peux pas accéder à mon API via Postman, et aucune idée de pourquoi.

Ensuite j’ai bien une réponse de l’API dans mon navigateur mais en fait c’est un 422 No Reason Phrase qui m’est retourné. (j’ai pas fait la config de ma bdd encore je ne sais pas si ça peut jouer mais c’est possible)

Enfin je ne peux pas utiliser l’API avec mon client local (une app VueJs) parce que j’ai des erreurs CORS :

CORS Missing Allow Origin

Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://pvapptestpackage.local/pvapp/api/v1/tokens. Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.

Et voià le lien du repo de l’API : https://github.com/LaBaude32/PvApp_Core_V2

Ok les choses avancent bien !!

Déjà l’erreur 422 c’était à cause de l’API et pas du Yuno
Ensuite pour CORS j’ai découvert que si je fais passer mes requêtes OPTION dans ma vérification de token ça me renvoie une erreur. Mais si je les vérifies pas, plus d’erreurs CORS.

Donc j’ai paramétré ma BDD correctement tout semble rouler ! L’API est donc utilisable ! Il me reste plus qu’a la déployer sur un serveur en prod (mon RPI) et pas juste dans une VM.

J’ai toujours deux bugs étrange :

ce qui n’est pas ouf en terme de sécurité :laughing: et puis très étrange parce que tu coup on ne peux pas accéder à SSO comme on doit le faire normalement.
J’ai l’impression que c’est lié à cette petite modif :

et autre bug :

Ce qui est assez chiant pour debugger lors de phases de dev…

Sinon ça à l’air de plutôt bien fonctionner !

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.