camillemonchicourt
commented
1 month ago Dans les logs que tu as partagé, c'est toi qui a remplacé par "mondomaine.fr" ?
Open MoulinZ opened 1 month ago
camillemonchicourt
commented
1 month ago Dans les logs que tu as partagé, c'est toi qui a remplacé par "mondomaine.fr" ?
MoulinZ
commented
1 month ago oui oui, on sait jamais ^^
MoulinZ
commented
1 month ago J'ai testé sur un Google Pixel Android 14 et j'ai le même problème...
DonovanMaillard
commented
1 month ago Bonjour,
Même souci de mon coté, je prévoyais d'ouvrir un ticket ce jour. Je vais creuser un peu mais je me demande si c'est pas un probleme avec les sous-domaines, j'ai l'impression que sur l'instance de démo avec un /taxhub ca fonctionnait sans souci. Je vérifie et fais un retour, mais effectivement je suis bloqué pour le déploiement de la 2.7 sur 2 de mes instances, faute de tests des RC en amont sur mes instances (je plaide coupable !)
MoulinZ
commented
1 month ago Est-ce qu'on peut télécharger une dernière version sans avoir fait les changements dans la table t_mobile_app pour la tester ? Parce que là du coup j'ai tenté de revenir en arrière mais ça ne downgrade pas l'app sur mobile.
sgrimault
commented
1 month ago Bonjour, A priori, l'URL ne semble pas accessible, comme par exemple https://geonature.mondomaine.fr/api/nomenclatures/nomenclatures/taxonomy. Deuxième point, bien vérifier si geonature.mondomaine.fr utilise un certificat SSL en bonne et due forme.
DonovanMaillard
commented
1 month ago @sgrimault de mon coté j'ai l'impression que mes API sont bonnes, mais je ne sais pas sur quelle API il bloque.
La dernière route interrogée avant le fail 15:48:26.506 INFO: [fr.geonature.datasync.api.ClientKt] --> GET https://taxhub.mondomaine.fr/api/taxref?orderby=cd_nom&limit=10000&page=1
Est bien accessible dans mon cas.
@MoulinZ : la table t_mobile_appsne sert qu'a déclencher la mise à jour manuellement, elle ne gere pas les downgrade. Et il vaut mieux tester sur un mobile et s'assurer que tout est OK en prod avant de déclencher les mises à jour sur tous les terminaux en modifiant cette table
MoulinZ
commented
1 month ago je précise que la route en question https://taxhub.mondomaine.fr/api/taxref?orderby=cd_nom&limit=10000&page=1 est bien accessible dans mon cas également, elle ne fail que sur le mobile (et sur les différents terminaux c'est bien cette route là qui fail).
Pour ce qui est du certificat, il est généré avec certbot et n'a jamais posé de problème. Je l'ai regénéré pour être sûr, mais ça ne change rien.
sgrimault
commented
1 month ago Sans doute pas accessible en dehors de votre infrastructure, car de mon coté je ne peux pas y accéder :
camillemonchicourt
commented
1 month ago Donnez les bonnes URL car sinon on ne peut rien tester.
Mais d'après les différents retours de tests, je pense que ces instances sont OK et qu'il y a bien un truc qui coince au niveau de la 2.7. Car si j'ai bien compris ces instances fonctionnaient bien avec la 2.6 et sont bien accessibles de l'extérieur.
MoulinZ
commented
1 month ago Oui c'est plus simple, voici la bonne URL qui fonctionne : https://taxhub-saisie.reserves-naturelles.org/api/taxref?orderby=cd_nom&limit=10000&page=1
sgrimault
commented
1 month ago L'erreur remontée est très clair :
15:48:26.506 INFO: [fr.geonature.datasync.api.ClientKt] --> GET https://taxhub.mondomaine.fr/api/taxref?orderby=cd_nom&limit=10000&page=1
15:48:26.613 INFO: [fr.geonature.datasync.api.ClientKt] <-- HTTP FAILED: java.net.UnknownServiceException: CLEARTEXT communication to taxhub.mondomaine.fr not permitted by network security policyJe pense qu'il doit y avoir une redirection HTTPS vers HTTP quelque part et en version "release", l'application refuse toute communication HTTP non chiffrée.
Je n'avais pas tilté que vous avez caché la vraie URL... 😅
sgrimault
commented
1 month ago Test rapide via cURL :
curl -k -v https://taxhub-saisie.reserves-naturelles.org/api/taxref?orderby=cd_nom&limit=10000&page=1
Trying 51.159.198.138:443...
Connected to taxhub-saisie.reserves-naturelles.org (51.159.198.138) port 443
ALPN: curl offers http/1.1
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
TLSv1.3 (IN), TLS handshake, Certificate (11):
TLSv1.3 (IN), TLS handshake, CERT verify (15):
TLSv1.3 (IN), TLS handshake, Finished (20):
TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.3 (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
ALPN: server accepted http/1.1
Server certificate:
subject: CN=tax...
start date: Jul ...
expire date: Oct...
issuer: C=US; O=...; CN=R10
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
using HTTP/1.1
GET /api/taxref?orderby=cd_nom HTTP/1.1
Host: taxhub-saisie.reserves-naturelles.org
User-Agent: curl/8.4.0
Accept: */*
>
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
old SSL session ID is stale, removing
< HTTP/1.1 308 PERMANENT REDIRECT
< Date: Wed, 17 Jul 2024 09:35:44 GMT
< Server: gunicorn
< Content-Type: text/html; charset=utf-8
< Content-Length: 329
< Location: http://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom
< Vary: Cookie
<
<!doctype html>
<html lang=en>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to the target URL: <a href="http://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom">http://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom</a>. If not, click the link.
...C'est donc bien un problème de redirection.
MoulinZ
commented
1 month ago Ok merci pour ces infos. Mais dans ce cas d'où vient le problème ? et pourquoi ça ne posait pas de problème avec la version 2.6 ? Problème qui semble similaire chez @DonovanMaillard si j'ai bien compris. Un problème dans TaxHub ? Avec certbot ? avec apache ? avec gunicorn comme le suggère le message ?
Voici mon fichier taxhub.conf :
<VirtualHost *:80>
ServerName taxhub-saisie.reserves-naturelles.org
<Location />
ProxyPass http://127.0.0.1:5000/
ProxyPassReverse http://127.0.0.1:5000/
</Location>
RewriteEngine on
RewriteCond %{SERVER_NAME} =taxhub-saisie.reserves-naturelles.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>Et le fichier généré par certbot pour le https :
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName taxhub-saisie.reserves-naturelles.org
<Location />
ProxyPass http://127.0.0.1:5000/
ProxyPassReverse http://127.0.0.1:5000/
</Location>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/taxhub-saisie.reserves-naturelles.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/taxhub-saisie.reserves-naturelles.org/privkey.pem
</VirtualHost>
</IfModule>Je confirme que j'ai bien ce souci également sur 2 instances, avec la conf suivante
# Configuration TaxHub sur sous-domaine
<VirtualHost *:80>
ServerName taxons.flavia-ape.fr
<Location />
ProxyPass http://127.0.0.1:5000/
ProxyPassReverse http://127.0.0.1:5000/
</Location>
RewriteEngine on
RewriteCond %{SERVER_NAME} =taxons.flavia-ape.fr
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
# Fin de configuration de TaxHubet le ssl :
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName taxons.flavia-ape.fr
<Location />
ProxyPass http://127.0.0.1:5000/
ProxyPassReverse http://127.0.0.1:5000/
</Location>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/geonature.flavia-ape.fr/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/geonature.flavia-ape.fr/privkey.pem
</VirtualHost>
</IfModule>
Il faut sans doute aller voir du coté de taxhub :/
DonovanMaillard
commented
1 month ago @MoulinZ Le souci ne se posait pas dans la 2.6 , j'imagine que c'est parce que les taxons étaient récupérés différemment et en appelant d'autres routes pour une partie du process.
MoulinZ
commented
1 month ago d'ailleurs autre étrangeté, c'est que cette erreur n'intervient pas sur une route de l'api précédente :
curl -k -v https://taxhub-saisie.reserves-naturelles.org/api/taxref/regnewithgroupe2
* Trying 51.159.198.138:443...
* Connected to taxhub-saisie.reserves-naturelles.org (51.159.198.138) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=taxhub-saisie.reserves-naturelles.org
* start date: Jul 17 05:59:39 2024 GMT
* expire date: Oct 15 05:59:38 2024 GMT
* issuer: C=US; O=Let's Encrypt; CN=R10
* SSL certificate verify ok.
> GET /api/taxref/regnewithgroupe2 HTTP/1.1
> Host: taxhub-saisie.reserves-naturelles.org
> User-Agent: curl/7.74.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Wed, 17 Jul 2024 09:49:21 GMT
< Server: gunicorn
< Content-Type: application/json
< Content-Length: 776
< Vary: Cookie,Accept-Encoding
<
* Connection #0 to host taxhub-saisie.reserves-naturelles.org left intact
{"": [""], "Animalia": ["", "Acanthoc\u00e9phales", "Amphibiens", "Ann\u00e9lides", "Arachnides", "Ascidies", "Autres", "Bivalves", "C\u00e9phalopodes", "Crustac\u00e9s", "Entognathes", "Gast\u00e9ropodes", "Hydrozoaires", "Insectes", "Mammif\u00e8res", "Myriapodes", "N\u00e9matodes", "N\u00e9mertes", "Octocoralliaires", "Oiseaux", "Plathelminthes", "Poissons", "Pycnogonides", "Reptiles", "Scl\u00e9ractiniaires"], "Archaea": ["", "Autres"], "Bacteria": ["", "Autres"], "Chromista": ["", "Autres", "Diatom\u00e9es", "Ochrophytes"], "Fungi": ["", "Autres", "Lichens"], "Plantae": ["", "Angiospermes", "Autres", "Chlorophytes et Charophytes", "Gymnospermes", "H\u00e9patiques et Anthoc\u00e9rotes", "Mousses", "Pt\u00e9ridophytes", "Rhodophytes"], "Protozoa": ["", "Autres"]}
gildeluermoz
commented
1 month ago C'est étrange. Dans un navigateur, si je colle l'url en http : https://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom
je suis redirigé en https vers https://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom et il y a bien une réponse json correcte.
Ce qui est étrange c'est que dans le test CURL de @sgrimault le certificat ne semble pas reconnu : SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
Dans mon navigateur le certificat letsencrypt est bien identifié comme valide
MoulinZ
commented
1 month ago En testant sur la commande curl sur l'instance de @DonovanMaillard, on a pas d'erreur de certificat pour le coup, mais quand même une redirection permanente :
curl -k -v https://taxons.flavia-ape.fr/api/taxref?orderby=cd_nom&limit=10000&page=1
Trying 164.132.105.227:443...
* Connected to taxons.flavia-ape.fr (164.132.105.227) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=comptasso.flavia-ape.fr
* start date: Jun 3 05:55:44 2024 GMT
* expire date: Sep 1 05:55:43 2024 GMT
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
> GET /api/taxref?orderby=cd_nom HTTP/1.1
> Host: taxons.flavia-ape.fr
> User-Agent: curl/7.74.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 PERMANENT REDIRECT
< Date: Wed, 17 Jul 2024 10:16:59 GMT
< Server: gunicorn
< Content-Type: text/html; charset=utf-8
< Content-Length: 295
< Location: http://taxons.flavia-ape.fr/api/taxref/?orderby=cd_nom
< Vary: Cookie
<
<!doctype html>
<html lang=en>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to the target URL: <a href="http://taxons.flavia-ape.fr/api/taxref/?orderby=cd_nom">http://taxons.flavia-ape.fr/api/taxref/?orderby=cd_nom</a>. If not, click the link.
* Connection #0 to host taxons.flavia-ape.fr left intact@gildeluermoz @MoulinZ J'ai pu trouver une explication possible et une solution avec l'aide de mon ami ChatGPT...
Il semble qu'avec la configuration par défaut de TaxHub et Apache, les règles "Location" Proxy et ProxyReverse traitent une partie des requêtes en http avant que les redirections https soient faites.
J'ai donc supprimé les règles "Location" de taxhub.conf sur le port 80, pour ne laisser la règle que sur le port 443 (taxhub-le-ssl.conf). En complément, j'ai ajouté les règles suivantes pour s'assurer que la redirection https soit faite avant de passer par le proxy :
<Location />
ProxyPass http://127.0.0.1:5000/
ProxyPassReverse http://127.0.0.1:5000/
# Ajoutez les en-têtes nécessaires pour HTTPS
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Ssl on
</Location>En faisant ça, j'ai bien une réponse valide sans Location http avec la commande curl -k -v https://taxons.flavia-ape.fr/api/taxref et j'ai bien une synchronisation correcte de mes taxons avec une version 2.7 du mobile 👍
DonovanMaillard
commented
3 weeks ago On vient de regarder avec Théo et Camille, dans les conf par défaut, il y a bien la règle RequestHeader set X-Forwarded-Proto "https" dans la conf geonature-le-ssl, qui fait appel à taxhub.conf dans les conf-available. Les installations par défaut et instance de démo fonctionnent donc sans soucis.
Le souci vient donc des configurations apache "custom" qu'on conserve depuis un certain nombre de versions pour certains, pour gérer nos sous-domaines respectifs. D'ailleurs pour ma part, il manque aussi une autre règle dans mes conf taxhub :
Alias "/taxhub/static" "/home/demo/TaxHub/static"
<Directory "/home/test/TaxHub/static">
AllowOverride None
Require all granted
</Directory>Je repartagerai rapidement des conf à jour pour les sous-domaine en me calquant sur les configurations par défaut de geonature sans sous-domaine, mais je me pose sérieusement la question pour ma part de conserver ces sous-domaines. Je pense repasser sur les conf par défaut pour limiter ce genre de soucis et les recherches de bugs associés :)
cen-cgeier
commented
3 weeks ago Bonjour à tous, même erreur de mon côté que celle obtenue par @sgrimault lors de son test de l'api des réserves. Pourtant ici pas de sous domaine en place.. j'ai tester la commande curl :
curl -k -v https://geonature.cen-isere.fr/taxhub/api/taxref?orderby=cd_nom&limit=10000&page=1Le retour de console évoque :
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=geonature.cen-isere.fr
* start date: Jun 25 01:44:20 2024 GMT
* expire date: Sep 23 01:44:19 2024 GMT
* issuer: C=US; O=Let's Encrypt; CN=R11
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /taxhub/api/taxref?orderby=cd_nom HTTP/1.1
> Host: geonature.cen-isere.fr
> User-Agent: curl/7.81.0
> Accept: */*En revanche tout semble OK sur la commande :
curl -k -v https://geonature.cen-isere.fr/taxhub/api/taxref/regnewithgroupe2Concernant les configurations apache voici ce que j'ai :
sites-available/geonature.conf
ServerName geonature.cen-isere.fr
IncludeOptional /etc/apache2/conf-available/geonature.conf
IncludeOptional /etc/apache2/conf-available/taxhub.conf
IncludeOptional /etc/apache2/conf-available/usershub.conf
ErrorLog "/var/log/apache2/geonature_error.log"
CustomLog "/var/log/apache2/geonature_access.log" combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =geonature.cen-isere.fr
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]sites-available/geonature-le-ssl.conf
ServerName geonature.cen-isere.fr
DocumentRoot /home/geonatureadmin/geonature/frontend/dist
<Directory /home/geonatureadmin/geonature/frontend/dist>
Require all granted
</Directory>
<Location /api>
ProxyPass http://127.0.0.1:8000 timeout=300
ProxyPassReverse http://127.0.0.1:8000
</Location>IncludeOptional /etc/apache2/conf-available/geonature.conf Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/geonature.cen-isere.fr/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/geonature.cen-isere.fr/privkey.pem
- sites-available/taxhub.conf
``` sh
<Location /taxhub>
ProxyPass http://127.0.0.1:5000 retry=0
ProxyPassReverse http://127.0.0.1:5000
</Location>J'ai tenté de modifier le geonature-le-ssl.conf et le taxhub.conf (l'un après l'autre indépendamment) en ajoutant dans les balises <Location> :
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Ssl onMais rien n'y fait ...
DonovanMaillard
commented
3 weeks ago Bonjour,
As-tu essaye de mettre les RequestHeader après les balises Location dans GeoNature-le-ssl ? Et bien relancé apache2 ensuite ?
cen-cgeier
commented
3 weeks ago En effet placer les RequestHeader en dehors des balises Location dans le fichier geonature-le-ssl.conf lorsque Taxhub n'est pas un sous domaine permet de solutionner le problème. *
Merci !
Cela permet lors de l'appel de l'api _https://geonature.cen-isere.fr/taxhub/api/taxref?orderby=cd_nom&limit=10000&page=1_ de rediriger vers _https://geonature.cen-isere.fr/taxhub/api/taxref/?orderby=cd_nom&limit=10000&page=1_ ce qui n'était pas le cas précédemment.
Je trouve tout de même étrange que l'api soit appelé sans / après taxref
DonovanMaillard
commented
3 weeks ago Le problème peut donc se poser également hors contexte de sous-domaines.
Pour le souci c'est qu'une partie des règles à gérer se font dans le fichier de conf ssl, donc après génération du fichier par certbot. Il faudra qu'on complète la doc sur ce point, à plus forte raison si le passage en https et la redirection de toutes les requêtes est indispensable pour le mobile.
En l'état, il y a donc plusieurs choses sur lesquelles il faut être vigilant.D'abord l'ajout des règles RequestHeader après (et en dehors) des balises Locations, pour s'appliquer à toutes les requetes des applis. Ensuite, que les "include" des fichiers conf-available soit dans le ssl et pas dans le geonature.conf, pour ne pas rediriger les requetes vers les proxy depuis le port 80 visiblement. On a donc un petit travail à faire sur la doc, mais le souci ne repose pas sur l'appli occtax-mobile en elle-même.
Je ferme le ticket ici et j'en ouvre un coté taxhub et geonature puisque c'est ces docs là qu'il faudra mettre à jour :)
geobrun
commented
2 weeks ago @DonovanMaillard : merci pour les explications, j'ai rencontré le même souci et cela m'a permis de résoudre le problème !
camillemonchicourt
commented
1 week ago Je ré-ouvre car je ne crois pas que cela a été clarifié/tracé côté TaxHub et/ou GeoNature.
DonovanMaillard
commented
1 week ago Non pas encore, je teste différentes règles et contextes car :
Version de l'application
Version d'Occtax-mobile affectée par le bug : 2.7.0 Version de GeoNature utilisée : 2.14.2
Terminal et Version Android
Marque et modèle du terminal : OnePlus 7T Version d'Android : 12
Description du bug et comportement attendu
Après le passage à OccTax 2.7.0 (depuis 2.6.1), j'ai une erreur dans la synchronisation des données de TaxHub apparemment, d'après les logs. Ce qui m'étonne c'est que l'accès à la route
api/taxref/regnewithgroupe2pour récupérer les rangs ne semble pas poser de problème, alors que la récupération de l'ensemble des taxons, elle, bloque. C'est probablement un blocage mobile vu le message :CLEARTEXT communication not permitted by network security policyMais je ne trouve pas comment corriger tout ça... merci pour votre aide !
Logs