mixed content (invocation d'une API en http depuis une page https)

[vprunet]

Version
2.13.4

Description du bug
après avoir ajouté le support https (certbot) à mon nouveau serveur geonature, fraîchement installé, il devient impossible de se connecter, la page d'accueil affiche le message "cannot log config from API". La console du navigateur affiche le message d'erreur :
Blocked loading mixed active content “http://xxxxx/geonature/api/gn_commons/config”

le message est explicite, mais j'ai néammoins vérifié que l'API fonctionne (en https, et aussi en http, dans ce cas le serveur apache redirige vers https).

Comportement attendu
Utilisation de https pour invoquer l'api gn_commons/config

Voir le fichier frontend/src/app/services/config.service.ts

Comment reproduire
Installation de la suite geonature avec le script install_all sur un debian 12 tout neuf.
Configuration https du serveur apache avec certbot.
ouvrir l'url de geonature ou de usershub avec firefox ou chrome (versions à jour).

Logs
L'erreur apparaît sur le navigateur, qui bloque l'appel à l'API geonature
firefox
Blocked loading mixed active content “http://xxxx/geonature/api/gn_commons/config”
chrome
Mixed Content: The page at 'https://xxxx/geonature/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://xxxx/geonature/api/gn_commons/config'. This request has been blocked; the content must be served over HTTPS.
Re @ polyfills.25e6f5a201d9f0da.js:1

[camillemonchicourt]

Une fois passé en HTTPS, il faut mettre à jour la configuration de GeoNature pour que l'API soit interrogée en HTTPS, voir la doc sur le sujet : https://docs.geonature.fr/installation.html#https

[vprunet]

Merci Camille.
Au premier essai, je reconnais que je n'avais pas mis à jour la configuration. C'est une autre question, mais il me semble que le code sur le navigateur devrait détecter automatiquement le scheme (http ou https) de la page chargée et l'appliquer aux requêtes d'API, sachant que les mélanges sont désormais interdits.
Je propose la demande d'évolution suivante : faire en sorte que cela marche quel que soit le scheme sans qu'on touche à la configuration.

Après avoir vu le fameux fichier de config mentionné dans la doc, j'ai modifié la config. L'appel api/gn_commons/config retourne un document json avec API_ENDPOINT en https comme on le souhaite.

J'ai suivi également la doc pour reconstruire le frontend (pas clair que ce soit encore nécessaire, en tout cas je l'ai fait).

J'ai toujours la même erreur avec geonature ;
Mixed Content: The page at 'https://geonature.mercantour.eu/geonature/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://geonature.mercantour.eu/geonature/api/gn_commons/config'. This request has been blocked; the content must be served over HTTPS.

Aussi une erreur avec usershub:
Mixed Content: The page at 'https://geonature.mercantour.eu/usershub/login' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://geonature.mercantour.eu/usershub/pypn/auth/login'. This request has been blocked; the content must be served over HTTPS.

J'ai essayé de comprendre ce que fait le code frontend/src/app/services/config.service.ts
Il fait un premier appel https://geonature.mercantour.eu/geonature/assets/config.json pour récupérer l'API endpoint

{
    "API_ENDPOINT" : "http://geonature.mercantour.eu/geonature/api"
}

puis il utilise cet endpoint pour la suite.

Dans mon cas, assets/config.json n'a pas été correctement mis à jour et l'endpoint connu du client en'est pas le bon.. Fausse manip de ma part ou problème de build? Où est ce que je dois chercher ce fichier ou le code qui répond à cette API ?

merci d'avance

[vprunet]

Je vois le fichier config.json dans frontend/src/assets/config.json (et frontend/dist/assets/) .
Est-ce que je suis sensé mettre à jour moi-même ce fichier? Je n'ai pas vu cela mentionné dans la doc, et on pourrait penser que c'est fait automatiquement.

[vprunet]

La release note de la 2.12.0 dit :

Configuration dynamique du frontend : le frontend récupère dynamiquement sa configuration depuis le backend. Pour cela, il nécessite uniquement l’adresse de l’API_ENDPOINT qui doit être renseignée dans le fichier frontend/src/assets/config.json. En conséquence, il n’est plus nécessaire de rebuilder le frontend lors d’une modification de la configuration de GeoNature ou de ses modules (#2205).

Je n'ai pas vu cette précision dans la doc d'installation , et surtout je n'ai pas édité à la première installation le fameux fichier frontend/assets/config.json qui a été créé automatiquement à partir du template et de la valeur donnée dans le fichier de config général (c'est très bien ainsi).

J'ai l'impression que la modification après coup de API_ENDPOINT n'est pas bien prise en compte et que la mise à jour du fichier frontend/src/assets/config.json a été oubliée.

[camillemonchicourt]

On n'est pas censé modifier à la main le fichier frontend/src/assets/config.json, mais on n'a pas documenté comment répercuter cette mise à jour.

Le plus propre est certainement de relancer le script d'installation du frontend qui se charge notamment de renseigner ce fichier : https://github.com/PnX-SI/GeoNature/blob/master/install/05_install_frontend.sh#L67-L70

[vprunet]

Ben non justement.
Pour que cela marche, il faudrait que le script que tu mentionnes écrase systématiquement le fichier config avec le template.(ligne 64). Parce que sinon (lorsque le fichier config.json a déjà été créé) la commande sed ne va rien trouver à remplacer.
Tel que c'est écrit, ça marche la première fois, seulement.

[jacquesfize]

Erreur de ma part, je pensais que le script remplacer la valeur de API_ENDPOINT dans le fichier config.json... En fait, il remplace une chaîne de caractère bien précise ... "API_ENDPOINT" que l'on peut voir dans le config.json.sample.

Du coup, plusieurs solutions:

• 1ère solution : renommer le fichier frontend/src/assets/config.json par frontend/src/assets/config.json_backup. Relancer, le script install/05_install_frontend.sh.
• 2ème solution : récupérer l'adresse de l'api avec la commande geonature get-config API_ENDPOINT et l'indiquer à la main dans le fichier config.json existant.

[camillemonchicourt]

Dans tous les cas, on n'est pas censé modifier manuellement le fichier frontend/src/assets/config.json, donc toute contribution à améliorer le script et/ou la documentation est bienvenue.

[TheoLechemia]

Si, actuellement, si on change d'URL ou qu'on passe en HTTPS, il est nécessaire de modifier ce fichier.
Avant la configuration du frontend était synchronisée via une commande backend et comme on a souhaité réduire au maximum l'adhérence en le backend et le frontend, elle est désormais servie par une API.
La seule chose dont le frontend a besoin de savoir, c'est l'URL de base de cette API, ça me parait normal de devoir modifier ce paramètre côté frontend. Le problème est qu’actuellement, ce paramètre est à deux endroits donc ça fait de la confusion. A étudier, mais je ne suis pas sur que le backend ai besoin de connaître sa propre adresse

[hypsug0]

Je viens de faire un rapide test avec l'URL sans spécifier le protocole dans le fichier config.json et ça fonctionne. Ne serait-ce pas une solution plus générique ?
{"API_ENDPOINT": "//geonature.demo.dbwildlife.info/api"}

[jacquesfize]

@vprunet, le problème est résolu ?

@hypsug0, ça peut être une solution en effet ! A voir quel protocole il utilise par défaut.

[camillemonchicourt]

A voir si on fait évoluer le script 05_install_frontend.sh pour qu'il puisse être relancé et mettre à jour ce fichier, ou alors si on indique dans la doc de modifier ce fichier manuellement si on modifie l'URL.

[TheoLechemia]

ça me parait un peu lourd de relancer toute l'installation du frontend juste pour modifier un paramètre de conf. Pour moi il faut indiquer dans le doc que si on modifie l'URL de son API, il faut le spécifier dans ce fichier de conf frontend

[vprunet]

ça me parait un peu lourd de relancer toute l'installation du frontend juste pour modifier un paramètre de conf. Pour moi il faut indiquer dans le doc que si on modifie l'URL de son API, il faut le spécifier dans ce fichier de conf frontend

Oui, mais c'est dommage de demander à l'administrateur de saisir un paramètre de configuration que l'on sait inférer de la configuration du backend (paramètre qu'on n'a d'ailleurs pas demandé lors de l'installation initiale).

[jacquesfize]

Depuis la version 2.11, une séparation du frontend et du backend s'est effectuée dans la cadre de la dockerisation de GeoNature (#2088). Par conséquent, il n'est pas possible de (ré) inclure une commande (ou autres solutions) depuis le backend.

Pour moi, une solution serait d'intégrer un item dans la FAQ sur le changement d'URL d’accès à GeoNature.

[vprunet]

J'ai essayé la proposition de @hypsug0 de configurer le frontend avec une url sans scheme (dans le fichier frontend/dist/assets/config.json). Cela fonctionne.
Cela marche même avec une url relative comme ci-dessous:

{
    "API_ENDPOINT" : "/geonature/api"
}

ce qui permet en principe de passer de http à https, de changer le nom de domaine ou même d'accepter plusieurs noms de domaine sans avoir à toucher à la configuration du frontend.
Par contre impossible de configurer le backend avec une url de ce type à cause de la validation marshmallow, qui par défaut exige une url complète. https://marshmallow.readthedocs.io/en/latest/marshmallow.fields.html#marshmallow.fields.Url

Vous semble-t-il envisageable d'autoriser les url relatives dans la configuration, d'en profiter pour définir des url par défaut (/geonature /geonature/api /usershub, ...) et de revoir les scripts d'installation pour qu'ils acceptent ces url ?

[camillemonchicourt]

Le script "install/05_install_frontend.sh" se charge désormais de mettre à jour l'URL si on le relance et la doc a été complétée sur le sujet.