Modification .toml : identification impossible

[ci-ana]

Bonjour,
Nous avons un souci pour passer de Geonature 2.11.2 d'un intranet à un https public : on a modifié le fichier .toml et suivi la procédure de la documentation, ça recompile tout correctement et sans messages d’erreur mais maintenant impossible de se connecter via le formulaire de connexion quelque soit l'identifiant. je rentre les identifiants, appuie sur se connecter, (aucun message d'erreur) et le formulaire se remet à zéro.
Le frontend reçoit la réponse du serveur (200/OK sur la dernière requête modules qui présentait un 401 / Auth Needed avant authentification sur la ressource login) mais n'y réagit pas et ne continue pas l'algorithme.
Et si on essaie de se connecter à Usershub et Taxhub, la réponse est "Identifiant ou mot de passe incorrect" alors qu'aucun identifiant et mot de passe n'a été modifié.
Auriez-vous des pistes?
Merci d'avance !

[gildeluermoz]

Bonjour,
Avez vous restart les services ?

sudo systemctl restart geonature.service
sudo systemctl restart geonature-worker.service
sudo systemctl restart taxhub.service
sudo systemctl restart usershub.service

[mvergez]

Bonjour,
Peut-être aussi vider le cache et essayer de rafraichir la page.
La réponse de la requête sur la route /modules renvoie 200 et renvoie bien une liste de modules ?

[camillemonchicourt]

C'est un sujet courant, car on modifie l'URL de GeoNature, il faut aussi modifier celle de TaxHub et UsersHub, bien modifier les paramètres de ces 3 applications et bien les redémarrer pour que les modifications soient prises en compte.
Il faut aussi souvent modifier les configurations Apache de ces 3 outils pour répercuter ces changements des URL renseignés par défaut lors de l'installation initiale.

Voir par exemple : #2442

[ci-ana]

Merci pour vos réponses rapides. Effectivement nous n'avions pas redémarrer les services mais il y avait un autre problème, un niveau de sécurité du reverse proxy, je vous mets ici les mots de la personne qui l'a installé :
"GeoNature accède directement à l'objet Document.cookie au sein de son front-end Javascript pour effectuer les requêtes à l'API du backend (notamment pour faire suivre la session).
Cependant les requêtes au backend doivent être effectuées via l'API XmlHttpRequest (AJAX) qui reprend automatiquement les cookies de sessions lors de l'appel XHR asynchrone. De fait, l'application RIA ne doit jamais accéder à Document.cookie et les préconisations de sécurité sont d'appliquer la directive HttpOnly sur les en-têtes Set-Cookie pour garantir ce comportement.
Afin de rétablir le fonctionnement, j'ai dû abaisser le niveau de sécurité du Reverse Proxy en modifiant la directive :
Header edit Set-Cookie ^(.)$ $1;HttpOnly;Secure
pour la passer à
Header edit Set-Cookie ^(.)$ $1;Secure"
Le produit est donc fonctionnel mais cela introduit un risque d'attaque XSS.
Je rappelle que cette configuration est considérée de manière constante comme une vulnérabilité Medium à High."

[camillemonchicourt]

OK merci pour ce retour.
Oui cela fait écho avec un sujet identifié mais non planifié de faire évoluer le mode d'authentification de GeoNature.

[camillemonchicourt]

Le système d'authentification a été revu dans la version 2.14 (à venir) pour le renforcer et supprimer les risques identifiés.